Weblogic’s many jar files...

Heres some problems I encountered trying to run some applications using Weblogic.

1/

java.lang.NoClassDefFoundError: weblogic/kernel/KernelStatus

I was banging my head against a wall with a

Exception in thread "Main Thread" java.lang.NoClassDefFoundError: weblogic/kernel/KernelStatus

While trying to write a simple standalone program to connect to a Weblogic instance via JNDI, and manipulate some JMX values. The solution was provided via this posting

http://blogs.oracle.com/jamesbayer/2008/08/workshop_for_weblogic_103_jee.html

To actually run the Main method class in Workshop, I right click on the class in the Project Explorer and select Run As->Open Run Dialog. In the classpath tab, be sure to add the wlclient.jar file located here \wlserver_10.3\server\lib to the User Entries section and remove the WebLogic System Libraries from the Bootstrap Entries section. If you forget to remove the WebLogic System Libraries, you will get a stack like this: Exception in thread "Main Thread" java.lang.NoClassDefFoundError: weblogic/kernel/KernelStatus

There is also a wlFullCLient.jar file that may be useful in other scenarios

2/

Just when you thought it was safe however, you get the following

ClassCastException: weblogic.jdbc.common.internal.ConnectionEnv

Here http://forums.oracle.com/forums/thread.jspa?threadID=1048084&tstart=118

the advice is as follows

I would suggest you to remove the wlClient.jar from the classpath.
Also make sure that there are no other jar files related to weblogic in the classpath.
Add weblogic.jar in the classpath and make sure that this weblogic.jar is the same jar that is in the weblogic server classpath.

This happens because of the difference in the jar used by the Client JVM and server JVM.

In fairness this does fix the problem.

Depending on what your client does, it may be necessary to include the Weblogic.jar (if its doing some funky stuff), to ensure it has all the correct classes. Be careful from oracle workshop (eclipse) however of attached bootstrap class loaders.

3/ Missing servlet jars/ JEE standard jars.

You may run into problems with missing J2EE standard jars. I for example was getting errors about HttpServletRequest etc from the Servlet Api. In previous versions of weblogic, the weblogic.jar file would contian all of these, but since 10.3.x they have stopped including it.

When looking up missing jars, try the following, check the following...

$WL_HOME/server/lib/api.jar

In there the MANIFEST.MF contains a list of jars that include the usual J2EE jars etc. These have been removed from Weblogic.jar so may be needed.

Finally... I've mentioned this before but it is important when working with Ears and Wars on weblogic.

If you start seeing exceptions such as

java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory cannot be cast to javax.xml.parsers.SAXParserFactory

deep in the Weblogic code, you have more than likely run into a dreaded classpath incompatibility.

To avoid this use the following in your weblogic.xml

<wls:container-descriptor>

<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>

</wls:container-descriptor>

This will then result in a lot of ClassNotFoudn exceptions which may mean a hunt through your libs to add missing files

For instance heres the issues I ran into

java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory cannot be cast to javax.xml.parsers.SAXParserFactory

This means that we need a newer version of the SAXParserFactory than provided by Weblogic (we are using Bea jdk 1.6, so thast is picking up the lastest version of javax.xml.parsers.SAXParserFactory, but then weblogic.xml.jaxp.RegistrySAXParserFactory is been instantiated and this refers to an older version of SAXParserFactory)

The problem in my case was un-resolvable. The incompatible jar was needed to perform translation of a binary Xml format, but unfortunately it also included a newer version of xmlparser. This newer version then started causing problems with taglibs in Jsps. Our fix was to move of deployment from 10.3.1 to 10.3.3

4/ java.lang.NoClassDefFoundError: weblogic/utils/NestedException

After trawling the web there are a lot of references to wlFullClient.jar

This refers to rolling your own version of all wl client jars.

What might be simpler is to simply add the required jars.

This is the list of client jars.

webserviceclient+ssl.jar

webserviceclient.jar

wl-j2ee-client.jar

wlclient.jar

wljmsclient.jar

wljmxclient.jar

wlnmclient.jar

wlsafclient.jar

wlstestclient.ear

wseeclient.jar

For NestedException the required jar is wljmsclient.jar

Tomcat deploy arbitrary dir

To deploy a webapp from a directory not in the appBase (the webapps directory by default) of Tomcat /Catalina, then its simple.

At its most simple you simply create a file in the $CATALINA_BASE/conf/[enginename]/[hostname] directory.

The name of the file is the webapp Context name you want.

The contents must include the docBase attribute. This points the location of the webapp.

This is very useful for development, so every change can be immediately realised on the webapp without restarting, or undeploying/ deploying (which is necessary if you deploy it using Tomcats manager, since it copies the apps into the webapp directory.)

e.g. save SpringSchedule.xml in the $CATALINA_BASE/conf/[enginename]/[hostname]




<Context docBase="F:/eclipse_workspace/SpringSchedule/www">

</Context>

Note: If you add properties files, or update the web.xml you will need to reload the webapp from the tomcat manager console.

Ref

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

Eclipse java command line

1/ You can generate the java command used by eclipse to run/ or debug an application, with all included classpaths etc. This can be useful if you want to later script the execution of the application.

It is visible by debugging the application (debug as application). From the debug perspective, right click on the debug view, to get the context menu. Select properties. The command line is visible and can be copied.

2/Also, its possible to run eclipse itself from the command line in headless mode.

eclipsec.exe -noSplash -data "D:\Source\MyProject\workspace" -application org.eclipse.jdt.apt.core.aptBuild

It uses the jdt apt plugin to build your workspace automatically. This is also known as a 'Headless Build'. If you're not using a win32 exe, try this:

java -cp startup.jar -noSplash -data "D:\Source\MyProject\workspace" -application org.eclipse.jdt.apt.core.aptBuild