aspose file tools*
The moose likes Websphere and the fly likes implementing common jars Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "implementing common jars " Watch "implementing common jars " New topic
Author

implementing common jars

jeff rusty
Ranch Hand

Joined: Nov 07, 2006
Posts: 109
Hi ,
I am using Websphere Community edition.I am trying to seperate jars like Struts.jar,Beanutils.jar etc which is commonly used across many projects so that the code is shared among those projetcs during runtime.I tried putting the commonly used jars in the lib folder of WebSphere it didn't work i also tried to put the jars inside var/lib folder even then my war didint get deployed its is throwing ClassnotFoundException rg.apache.struts.action.ActionServlet. can any one help me
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Welcome to the world of the WebSphere classloaders.

Personally, I've pined for the day when there's one classloader that loads everything. Of course, I want a single class with one method called go() that does everything as well, so maybe I'm antiquated.

The \lib folder is great for classes that are called, but never make callbacks into an application. That is good for stuff like db2 drivers, but bad for your own, reusable components.

The short answer? I like packaging common components in each ear file. Is there duplication across ears? Yes, of course. But what happens when the hr application upgrades to the latest set of common jar files, but the accounting app hasn't been tested yet? If the files are in a common location, that can't happen. If the files are packaged independently in each ear, apps can be tested and upgraded independently.

Of course, there are plenty of opinions on this whole thing. I've smugly convinced myselt that I am right, and everyone else is wrong, but then again, I have been wrong before.

For more information on demystifying the WebSphere classloaders, check out this article I wrote:

Let's Get Loaded: Packaging J2EE Components with the WebSphere Classloaders

Happy WebSphere!

-Cameron McKenzie
jeff rusty
Ranch Hand

Joined: Nov 07, 2006
Posts: 109
Cameron ,
i wanted to avoid duplication of jars and thats why i wanted to go for common jars which i have implemented in tomcat by putting them in the common/lib folder.you have mentioned that ear is independent for each project so again duplication is there which i dont want.Isn't there any straightforward way by which i can put all my common jars in a folder which Websphere provides. i am totally confused
[ December 27, 2006: Message edited by: prem kamal ]
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

There are indeed a variety of WebSphere classloaders you can use, each of which will present it's own set of problems.

You might try the WebSphere external JAR classloader, ExtJarClassLoader, in lib\app, which is the only classloader I know of that has a default configuration of PARENT_LAST. Everything else is PARENT_FIRST.

You can also create your own classloader. You do have time off over Christmas, right?

As a developer, I understand your desire to not duplicate jars, but I do think WebSphere and J2EE pushes you into the idea of duplicating things such as the Struts.jar file into each EAR.

Again, what are the odds that EVERY application in your environment is going to be Struts 1.0? What if you want to upgrade one app to 2.0? Will every app be ready to upgrade at the same time? What if one application absolutely needs a new feature of Struts to work, but the others run fine without a problem? Are you going to needlessly upgrade all of the other apps to the latest version?

Fight the temptation, and package utility classes in each ear. It's duplication, I know, but it makes for more maintainable software in the longrun, not to mention getting rid of these annoying classloader issues.

-Cameron McKenzie
jeff rusty
Ranch Hand

Joined: Nov 07, 2006
Posts: 109
cameron,
Thanks for your reply.I got it working.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Now I'm curious?

What was he magical configuration you uses? Any location on the WebSphere classpath in particular?

It's great when things start working.

-Cameron McKenzie
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: implementing common jars