Recursive Java Decompiler by Adarsh

" Often we encounter situations where the only solution to a certain Java problem is to decompile the contents of an entire JAR file, edit the resulting the source, rebuild and repackage before using. "

- Adarsh Ramamurthy

I found myself in this situation today & was struggling with CAVAJ and JAD to recursively generate Java classes present in an EAR file. I initially tried my hand at writing my own DOS Script to do this, but soon found that it takes a lot of time, patience & effort to write a script that does what I need. And time, unfortuantely, is in very limited supply today !

I Googled around looking for solutions & landed on this post by Adarsh. The Recursive Decompiler provided by Adarsh works like a charm *& saved a lot of time !

Thanks a lot Adarsh !

DWR Hello World !

" DWR is a Java library that enables Java on the server and JavaScript in a browser to interact and call each other as simply as possible. "

- Direct Web Remoting ( DwR )

I was snooping around for an AJAX library that I can use in one of my projects & narrowed down to DWR, after reading a lot of rave reviews about it. I was looking out for some AJAX library that'll allow me to call the methods in my Java classes with minimum effort.

I decided to take it for a test drive & check out the features. The usual sources were the DWR Documentation and Google.

I don't want to duplicate the good & decent documentation available for DWR at the "Get Started" page.

At a high level, I would like to just summarize the steps involved ( with the mistakes I made highlighted ) :-

• Put dwr.jar in your Project's lib.
• Put the Commons Logging Jar in your Projects's lib. ( Dwr uses Apache Commons Logging )
  
• Add the configuration settings in your web.xml for the DWR Servlet.
• Add the debugging parameters for the DWR Servlet during the development phase.
• Add the dwr.xml under WEB-INF and configure it to expose your Java Classes.
• Add the converters in dwr.xml to ensure the conversion of Java POJOs to JavaScript Objects & vice versa.
• Include the reference to all the JavaScript libraries required in your JSPs.
  

Overall, I am impressed with this & I am going ahead with my implementation using DWR.

WebLogic Server 10 : Deployment : Error 149003

" WebLogic Deployer:149003 Unable to access application source information "

You might bump into this error during deployment. I just noticed that someone was struggling with this error & had reported this on the OTN Forums.

The Stack Trace for the error usually looks like this :-

Error is: 'weblogic.management.DeploymentException:
[Deployer:149003]Unable to access application source information in
'/home/bea/bea/user_projects/domains/myDomain/servers/myServer/stage
app/app.war' for application 'roller'. The specific error is:
[Deployer:149158]No application files exist at
'/home/bea/bea/user_projects/domains/my/servers/myServer/stage
appapp.war'

The error occurs when the WebLogic Server is unable to locate the EAR file. The common causes for the EAR file could be :-

• ANT Deployment : The EAR file was not uploaded to a directory that the server can access.
• Console Deployment: You might need to look at "Source Availablity" [ Copy this application onto every target for me ], if you wish to copy the application to all the managed servers in a Cluster.

The error vanishes once the server can access the EAR file.

Spring LDAP caches user credentials

" Spring-LDAP caches environment properties by default "

Spring-LDAP API Documentation

I was facing this rather peculiar problem of User Credentials getting cached by Spring LDAP. I discovered this accidentally ( absent-minded, to be precise :) ) . I changed the password of a User in my ApacheDS but tried to login with the old password - and guess what ? it worked !

Well, I looked at the first place I would go to in these situations - the Spring-LDAP Community Forums.

I noticed that the problem has already been discussed in one of the threads.

The solution suggested in the thread is use the setCacheEnvironmentProperties() method in the AbstractContectSource class & set it to false. The Java doc for the API seems to explain this more :-

Set whether environment properties should be cached between requsts for anonymous environment. Default is true; setting this property to false causes the environment Hashmap to be rebuilt from the current property settings of this instance between each request for an anonymous environment.

Well, just one of those queer things in the fascinating Spring LDAP API.

JSF Managed Bean in a Servlet Filter

" How do you get a JSF Managed Bean, with session scope, in a Servlet Filter ? "

- Two bewildered comrades

The question posed above can be reworded in a simpler way :-

" Which came first, the Chicken or the Egg ? "

- A timeless paradox

We just hit this problem of accessing a JSF managed bean from a Servlet Filter. The requirement is quite simple - Oracle Single Sign On authenticates a user, passes on useful information about the user in the request headers & this information needs be passed on downstream to a Managed Bean for furthe consumption.

However, try as much as we can, we only hit the simple NullPointerException, which quaintly informs us that we aren't getting the FacesContext to proceed further.

A bit of Googling landed us on a post on the Sun Java Forums, where one of the legends of the Java Universe - Craig McClanahan - has suggested that this might not be possible. He has eloquently described how the Servlet Filters get triggered much before the Servlets & hence, the FacesContext doesn't stand a chance of getting initialized unless the flow hits the FacesServlet.

However, on further Googling, we hit upon this curious post on the Thougths About blog that offers an amazing alternative! We tried the code posted on the blog and.... it just works !

Thanks a million to the Thougths About blog for shaving off a few precious hours off the already-harried schedule of a couple of developers !

You can also find a very good explanation about the differences between a Filter and a PhaseListener on the same Blog.

Now, it's time for a cup of coffee.....