PowerMockito - Calling Real Method of a Mocked Instance

Hi all,

When writing unit test cases, sometimes we need partial mocking, that means some methods may need to be mocked, while some others not. For this, the line below may be used,

PowerMockito.doCallRealMethod().when(mockedInstance).execute(Mockito.isA(Command.class));

Have a nice day!

Weblogic SSL Hostname Verification Deactivation

Hi,

You can see an explanation about disabling weblogic's SSL hostname verification,

http://docs.oracle.com/cd/E23943_01/apirefs.1111/e13952/taskhelp/security/DisableHostNameVerification.html 

Have a nice day!

Java Calendar&Date Comparison

Hello,

Last week, I struggled with date comparisons in Java.
Normally, as you know, java.util.Date and Calendar have necessary functions for comparing operations. But when we talk about Timezone, the issue gets complicated.

You may know, java.util.Date objects do not carry any Timezone information, so when you compare dates with different timezones, you should be careful. You may say that, you would prefer java.util.Calendar instance for this operation. Bingo! That's true, but not complete.

I explore something. You have two calendar instances and you set their timezones correctly. Everything is looking good. When you compare each other with Calendar's functions, i.e. "after", you may be shocked, it gives wrong result. Because, when you create a Calendar, it is created with default system timezone. And when you change its timezone, this does not change its milliseconds property.. Compare methods use milliseconds, so you get wrong answer. You should add the offset milliseconds to calendar's after setting timezone, what am I taking about is this,

(taken from this URL,
http://stackoverflow.com/questions/230126/how-to-handle-calendar-timezones-using-java)

// My default timezone is GMT+2

Date date = new Date();

// get offset for GMT+2
int offset = TimeZone.getDefault().getOffset(date.getTime());
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT+5"));
System.out.println(cal.getTime());

// get new offset for GMT+5
int newOffset = cal.getTimeZone().getOffset(date.getTime() - offset);
cal.add(Calendar.MILLISECOND, newOffset-offset);
System.out.println(cal.getTime());

Here, as you see, new Calendar object is created with GMT+5 timezone and its milliseconds are set properly. By this, you can use compare methods correctly.

Have a nice day !

Do synchnorized blocks or methods on Java prevent from multi thread access for every thread?

Hi,

As you read the question, I want to answer it quickly :)

Answer is, it depends. If the synchronized method is marked as "static", yes, it will work for every instances of class, because static methods belong to class, not instance.
For synchronized blocks, if they are in a static method, the same things go for them.

Otherwise, if the method is not static, it will work per instance, one's lock will not affect the other instance's synchronized block.

Have a nice day!

Good Reference Sources for Migration of Commons HttpClient 3.x to HttpComponents HttpClient 4.x

Hi,

I had a task for replacing our Commons HttpClient 3.x dependency to HttpComponents HttpClient 4.x
As the latter one contains many changes over predecessor library, there are many things to be corrected at client side.
So, I used the sources below to accomplish my task, they were very useful, I recommend you to look at these if you have a task like mine :)

http://debuguide.blogspot.in/2013/01/quick-guide-for-migration-of-commons.html

http://www.codingpedia.org/ama/how-to-use-the-new-apache-http-client-to-make-a-head-request/

http://stackoverflow.com/questions/6024376/apache-httpcomponents-httpclient-timeout


Have a good day!

Search on a CLOB column on Oracle DB

Hi,

You can user instr function for searching on a CLOB column.

Ex:

select * from TABLE_NAME where instr(COLUMN_NAME,'SEARCH PARAM') > 0 order by process_date desc

Have a nice day!

Getting RollbackException in Transactional Methods

Hi,

Here is the second problem i have to deal with, RollbackException.
As I search on Google, if you get exception in a transactional method, even if you catch it and not throw, the transaction is marked as rollback only and you cannot commit anything in this transaction.
This may be annoying if you get an ignorable exception, for example NoResultException.
For overcome this, you should take some precautions with Transactional annotation, like this,

@Transactional(rollbackFor=MyException.class, noRollbackFor=MyException2.class)

Specifying rollback and no-rollback situations is the best way to handle this.

Have a nice day!

Link: http://stackoverflow.com/questions/19302196/transaction-marked-as-rollback-only-how-do-i-find-the-cause