This is Hilarious! My son is a hardcore Sallu Bhai fan already.

Worst Practices in Coding and Exception Antipatterns

1. Nice checklist for how not to handle exceptions in Java

Exception Handling Antipatterns

2. You know you got it wrong when ...

Java Worst Practices

Accept Untrusted SSL Certificates with Java Code

I ran into this problem while writing a standalone java tool that programatically opens a HttpsUrlConnection to a server running an ISAPI component. The development environment server had an expired ssl certificate due to which my code would throw an InvalidCertificateException exception while making the connection.

The following 2 steps helped me get around the problem.
1. Import the expired certificate to JDK keystore. This great post explains how to achieve this.

I have copied the whole post below just in case the above url is moved

2. Extend the javax.net.ssl.HostNameVerifier class and override the verify() method to always return true.
next force your HttpsUrlConnection to use your verifier by connection.setHostNameVerifier(myverifier)
Sample code:

HttpsURLConnection urlConn = (HttpsURLConnection)url.openConnection();
/** The following is a patch is to bypass ssl authentication
* issues due to expired certificates on the server
* Also ensure u have imported the expired server certificate
* into your keystore using the keytool
*/
urlConn.setHostnameVerifier(new Verifier());
urlConn.setUseCaches(false);
urlConn.setDoInput(true);
urlConn.setAllowUserInteraction(true);
//Read the response
BufferedReader in = new BufferedReader( new InputStreamReader(urlConn.getInputStream()));


And you are ready to go!!

Bypass invalid ssl cert by Dirk Mccormik

For posterity, here's how to ignore/bypass an expired/invalid
certificate without changing your java code.

In order to add a certificate from a website to your JVM do the
following:

1. In Internet Explorer, go to the website. It will give you a Security
Alert dialog and say what the problem with the certificate is. Click
"View Certificate". Click the Details tab. Click copy to file and
follow the Certificate Export Wizard. Save using the format "DER
encoded binary X.509 (.CER)".

2. Repeat the process, and this time after clicking "View Certificate"
click the "Certification Path" tab. If there are any other certificates
in the certification path, export these to file as well.

3. Go to the directory where you saved the certificate, and run keytool
to import it:
C:\tmp>"C:\j2sdk1.4.2_10\bin\keytool.exe" -import -keystore
"C:\j2sdk1.4.2_10\jre\lib\security\cacerts" -storepass changeit -alias
verisignTestCert -file verisignTest.cer
where verisignTest.cer is the name of the certificate file you exported
from IE.

4. Repeat this process for each certificate you exported in IE.

Hope this helps someone in future.

Transaction Demarcation in a J2EE application

Which layer in a J2EE application should have transaction demarcation logic? Should it be done at the DAO level, EJB level, or should your business logic classes (I prefer to keep all my business logic in POJOs) have the knowledge on when to begin, commit or rollback transactions.

Depends on the scope of your application. If the application performs typical single database read write operations, then the best place for transactions would be DAO layer. Simple jdbc connection commits and rollbacks would do the job and avoid further complexity. There is no need to use JTA in such cases.

In case of more complex applications where operations involve writes to multiple databases, JTA can be used to manage transactions programatically at the business workflow layer. Note:
In this case XADatasources should be used for databases

http://www-128.ibm.com/developerworks/java/library/j-dao/

Ofcourse EJB's provide a very convenient mechanism to manage such complex transactions behind the scenes.
PRO: Less complexity, u do not have to worry about transactions as a developer
CON:
1. A developer would like to have control over workflow and transactions
2. All business logic including workflow and trasaction logic can be in a POJOs so that it does not have to rely on a specific technology like ejb. (e.g same POJO can be exposed as a webservice without breaking any workflow or transaction logic)

Again all this may vary with application and environment.

Client Managed Transaction Demarcation: You can also choose to let the client application manage transactions.