In fact, if you look at the current source, we have managed to have separate classloaders for each ear that behave as a single classloader, but only if the needed classes cannot be found locally. That means, if you package your jars traditionally, you won�t even notice ...
 
CGJ
-----Urspr�ngliche Nachricht-----
Von: Lachezar Dobrev [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 7. Juni 2001 16:05
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-user] How to look up one bean in one jar from another bean in another jar cleanly

   :)))
   Seems like I missunderstood you.
   That was what I meant.
   BTW. Per-container means... Ughhh... There could be a couple of containers. Per-container means, that every EJB container has its own classloader. The global meant for all the application server there was one and only class loader.
   That's it.
 
   May the shade of the tree strengthen you.
   Lachezar.
Hell yes!
 
maybe it was ambiguous from my mail: the default for 3.0 will be a _scoped_ deployer that IS CAPABLE of deploying several ears into a common scope. But this
should be influencable at deployment time where global scope (GLOBAL) and local scope (PER_JAR) are just two extremes. Dunno exactly what PER_CONTAINER means but looks like something in between (how specified?).
 
The current cvs contains a first step into that direction by introducing the necessary deployment logic and an example deployer with the GLOBAL option. Do you really think we are so stupid to mandate this?
 
CGJ
 
-----Urspr�ngliche Nachricht-----
Von: Lachezar Dobrev [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 7. Juni 2001 14:33
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-user] How to look up one bean in one jar from another bean in another jar cleanly

   HELL NO!
   This is not so good, as it looks like in first glimpse.
   This means, that you can NOT use different class implementations is different EARs... That is totaly undesirable, although it may make things easier for a project breaking into multiple EARs.
   That is why IAS/BAS has a setting for the classloader. It can be either PER-JAR, either PER-CONTAINER either GLOBAL. Let this be the developer's issue. OK?
 
   Lachezar.
Another opportunity is the org.jboss.deployment.scope.J2eeGlobalScopeDeployer (csv source only, will be default for 3.0) that allows
separate ear�s to share classes.
 
Just to advertise ;-)
CGJ
-----Urspr�ngliche Nachricht-----
Von: Lachezar Dobrev [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 7. Juni 2001 12:04
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-user] How to look up one bean in one jar from another bean in another jar cleanly

   Hello. When packaging jar2 you have to put the home and remote interface of bean1 in it. Other way is to package ALL home and remote interfaces into a jar and put it in lib/ext. I prefer second.
 
   May the shade of the tree strengthen you.
   Lachezar.
Hi,
I have to deploy 2 jar files in JBoss2.1 for my EJb based application - jar1 containing bean1 and jar2 containing bean2
 
In bean 2  I lookup bean1 using ctx.lookup("java:comp/env/bean1").
 
Using the jar tool ejx.jar i edit the xml's of jar2 and map the ejb-reference "bean1"  to bean1's JNDI name
 
I place both jars in the deploy directory and start the jboss server
 
When trying to invoke bean 2 methods from my application client
on the Server side i get the Exception :- 
        java.lang.NoClassDefFoundError:  bean1
 
So i placed jar1 containing bean1  in the lib/ext   directory.
 
This solved my problem and  my application works properly.
 
But the side-effect is  that since i have   jar1 containing bean1 files in lib/ext,
whenever i run the jar tool ejx.jar and whatever jar i open any jar for editing it always opens the xml's of jar1.
(My feeling is the META-INF/ejb-jar.xml  is loaded using ClassLoader.getResourceAsStream and since
lib/ext is the first thing in the CLASSPATH that xml will always be the one which is read).
 
 
So I need to remove the jar1  from  lib/ext when i want to run ejx.jar  but i need to put it back when i want
to run the jboss server.
 
I can try to have another copy of jar1 (minus the xml files) in lib/ext . But it is a big headache with multiple
copies of  jars with just the xml's  missing.
 
I reason there must be a better solution than this and moreover it is a big nightmare explaining installation
instructions to our clients which has to take care of these issues.
 
What is the cleanest way  to look up one bean in one jar from another bean in another jar
and where should the classpath be set?
  
I have looked at the archives and could not find a satisfactory solution.
 
 
Thanks in advance,
Munesh Gupta

Reply via email to