File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Websphere and the fly likes Common Code sharing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "Common Code sharing" Watch "Common Code sharing" New topic

Common Code sharing

JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Hi all,
Two questions here.

1) Let's say I have an EJB (CommonJAR) which perform operations all my application will have to do (say.... a specific mathematic computation with DB updates).
If I do not want to deploy my EJB in each applications, in order to have only 1 version to maintain in production, how can I do that with WAS ?
Can I deploy my EJB in a CommonEAR application and have refs to this EJB in each applications ?
EAR1 --> CommonEAR (contains CommonJAR)
EAR2 --> CommonEAR (contains CommonJAR)
Is there a specific visibility to set up for that ? I tried with server visibility and I obtained JNDI lookup errors
2) Personnaly,my feeling is that an EAR file should be self-contained. Each EAR has its own version of the EJB. (that's my workaround for question 1 )
What about you ?
[ December 11, 2002: Message edited by: Bill Bailey ]

/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Marcel Heijmans

Joined: Nov 26, 2002
Posts: 9
I agree that EAR's should be self contained. However, there are situations where generic code could be shared among applications. Database drivers, JMS providers or logging frameworks are examples.
Server visibility is 1 one to solve this. However these module visibility schemes are highly volatile in WAS.
My opinion is to drop the JAR in the WebSphere/AppServer/lib/ext directory. This way the WebSphere classloader can find the shared components.
Kyle Brown
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
BAAD idea. Dropping it on the WAS classpath means that it's shared by all of EAR's -- what if you wanted to deploy another EAR that used a different version of one the classes in that JAR file?
Also, Server visibility can cause a multitude of bugs. We don't recommend it.
Go with the workaround. Multiply deploy the EJB.

Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at for other WebSphere information.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Thanks for the answer guys.
As far as I am concerned, I'm not really confident with the WebSphere/AppServer/lib/ext solution.
Even the DB driver dropped on that level can be a nightmare depending on you applications.
Moreover, I understand it could be a solution for a java-jar file, but not for an EJB. Am I wrong ?
The Application Visibility I've tried to use is not really a solution either. It sounds like it will not take a long time before IBM removes it from WAS options (after v5 ?)

So the multiple EJB deploy appears as the only way out to common code sharing... it means comon code is not shared... thus common code is not common

BTW Kyle, stay tuned. I'll soon post some feedback about my ClassLoader problem. Remember ??
[ December 12, 2002: Message edited by: Bill Bailey ]
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
just one more question
If, as a test, I really really want to deploy a common EJB, each application pointing to it... how can I do that. I dont understand the JNDI lookup error I described above....
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
ok, my mistake.
The ejb was not started properly
I agree. Here's the link:
subject: Common Code sharing
It's not a secret anymore!