Hi!
Aaron Mulder wrote:
> So from the technical perspective, I guess the problem is that
> each JAR has its own classloader?
To call it a "problem" is not correct. It is a logical implementation of
the intent and semantics of jars.
> If you don't put the interfaces for all
> the beans in all the JARs, they can't access each others' classes since
> they're in the wrong classloader?
If X needs Y then X needs Y's interface, but Y does not necessarily need
X's. Also consider that if they are a logical unit it might be better to
have them in the same application/jar.
> I guess I hadn't really thought this
> through. I have always thought more of a big app with lots of
> interrelated beans, but all in separate JARs so they could be managed and
> updated independently.
That is a view based mostly on the practical side of things. However,
managaing them as a unit instead of pieces makes it easier to keep them
consistent.
> But it sounds like there's a serious disadvantage
> to this approach.
Depends on the desired effects. Again, when making the decision do not
focus on the practical side of things, but on the intent of jars and the
semantics of placing beans in different jars. Do you see how I mean?
This is non-trivial.
> However, if a client can dynamically download the interface
> definitions it needs to operate (assuming you enable a security maanger
> and so on), why can't one EJB dynamically download the interfaces it needs
> for another EJB? Why would it have to ship with them?
It doesn't. It depends on how you use them.
Consider this.
The following code will require bundling of interfaces:
Account acc = accountHome.findByPrimaryKey("1234"); // Get account 1234
The following code will not require bundling of interfaces:
EJBObject acc = fBPKMethod.invoke(accountHome, new Object[] { "1234" });
// Get account 1234
The latter loads classes using dynamic classloading to unmarshal the
EJBObject stub. The former cannot use this principle since it needs the
Account interface from within the code. And where should the JVM load
that class? From this.getClass().getClassLoader(), which in the case of
a bean is the EJB-classloader used to load the beans class.
Do you understand?
So, for most common practices a bundling of interfaces is indeed
necessary. If this is not desired then reflective usage must be done.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
