Hi!
marc fleury wrote:
> 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.
No, one could reference external jars through the Class-Path manifest.
> A shared CL in the EAR is where we should be, honestly. It is an
> implementation problem imho right now, nothing more.
Absolutely correct. App CL for an EAR is the right way to go.
> <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).
On the contrary. You *can* extend this to method invocations. I have
made a plugin for EJX that lets you hookup with ANY home interface and
dynamically call finders. The results are introspected and added to the
GUI, which you then can work with (i.e. call methods) dynamically. :-)
> 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)).
Correct. This should be fixed.
> 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.
It's both :-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
