Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Common Code sharing

 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Marcel Heijmans
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok, my mistake.
The ejb was not started properly
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic