> > 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.
yes, however it's a tools issue.
>
> > 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.
I differ there kid.
It is not a "high level" decision on semantics. It is a tools issue, and
one that should focus on "practical". The fact is that right now the
current implementation of jboss works on a "Application" that is not really
one (in the EAR sense) and so we need the one big mother honking JAR with
every body in it.
A shared CL in the EAR is where we should be, honestly. It is an
implementation problem imho right now, nothing more.
>
> > 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
>
<chuckle-chuckle/> that's pretty smart actually, real rickard stuff ;-) and
fBPKMethod comes from EJBHome, yes works... you still need the interface for
the other business methods (in short you can't do anything with your acc ;-)
but I like the hack (pun).
But again, a correct tool would assemble your application with various jars.
If most app server support the "EAR" format it should be transparent. It is
not in our case (yet). the CL is linked to the app that is really a URL (see
ContainerFactory.java at deploy(URL url)).
Visibility in the CL is a biggy, but implementation related. "Jar semantic"
is not real. One can make the case that a "real" app should be nothing but
xml scripts pointing to remote stored beans (<grin-telkel> ;-) and that the
problem you are pointing out is not a packaging problem, its a CL problem.
regards
marc
> 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
>
>
