Pages

Saturday, February 12, 2011

Running WPF Designer with Java 6

Today I encountered a perplexing error in the portlet factory designer:

(com/ibm/workplace/wcm/api/Workspace) bad major version at offset=6
Cannot instantiate Class Name: com.dsixe.wcm.Content - java.lang.UnsupportedClassVersionError: (com/ibm/workplace/wcm/api/Workspace) bad major version at offset=6

Now I've seen this type of error before, all it requires is a tweak to the project properties, change the runtime to the appropriate version - in this case it seemed to be 6. But the error would not go away.

The source of the problem was a linked java object builder pointing to a class which contained a reference to a class requiring java 6. When a classname is defined in the builder, I assume it must attempt to introspect the class to determine its methods, and I guess it was unable to instantiate it. So the problem seemed to be that the designer (eclipse) needed to execute in java 6 environment.

Switching to JRE 6

Eclipse start parameters can be defined in a configuration file named C:\IBM\Portlet Factory\Eclipse\eclipse.ini. One of those parameters tells it which JDK to use, so I added the following to the top of the file

-vm
C:\Program Files (x86)\Java\jre6\bin

Then I restarted eclipse. Problem gone.

EDIT 02/05/2013:

Using IBM's J9 JRE
Developers using the publish to websphere portal feature in the WEF designer will need to run the J9 version of java. This can be downloaded from http://www.ibm.com/developerworks/java/jdk/eclipse/ , ensure that you pick the 32 bit version and unzip (I put it in C:\IBM where WEF is installed). For some reason the install of WEF on windows uses 32 bit version of eclipse. Edit the eclipse.ini to use this:

-vm
C:\IBM\IBM_DevelopmentPackage_for_Eclipse_Win_X86_32_4.0.0\eclipseDevelopmentPackage\ibm_sdk70\jre\bin\javaw.exe


Wednesday, February 2, 2011

JNDI Datasource Names in WPF Designer

A common problem when working with data sources configured in the application server and the sql call builder is tying the two together. The builder provides a dropdown list of JNDI names that it thinks are
defined, but sometimes the name that you're looking for isn't there.


Ensure that your project is deployed

A typical scenario is starting a new project which contains a service provider model that retrieves data from a data source. You figure you've done this before so you know what you're doing, but somehow the JNDI name just isn't there.

Here's the problem - the designer needs to communicate with the server to retrieve the list of JNDI names, and it does this by issuing an http call to a model on the server from within the eclipse tool. So if the project hasn't been deployed or the server is not running, then the names cannot be retrieved.


Digging deeper

So you're sure that the project has been deployed and the server is running because you successfully executed another model in your project, but still no JNDI name. Here's where we can open up the hood and take a look at what's really going on. Navigate to \WebContent\WEB-INF\models\factory\core\db_utils.model, don't look for it in the \model folder because it's been hidden from view by the designer. Open the model and find a method builder called getDataSourceNames:


The coordinator for the sql call builder attempts to invoke this model at design time to retrieve the JNDI names, so any debugging is easily pinpointed here. It appears that the developers of WPF were kind enough to add some debugging logic in their code, try changing the debug value to true and watch for output in the server's system out log.