(Sorry, I stole this message from the other list)
On Thu, 20 Jul 2000, Rickard [iso-8859-1] �berg wrote:
> I think you need to move your understanding of a jar from the practical
> towards the intention of a jar.
>
> What is an EJB jar?
>
> It is the smallest possible assembly of components. If you have two
> components that are directly dependent on each other in order to
> implement a specific application then they should be in the same jar.
>
> So, the first question is: why have you put two interrelated components
> in two jars instead of one?
>
> The second is: if there are indeed good reasons for having two jars, you
> must make it possible for them to "know the face" of each other.
> Inter-faces. So, by placing the interfaces of one bean in anothers jar,
> that another bean will be able to inter-face with the first one. Do you
> see?
So from the technical perspective, I guess the problem is that
each JAR has its own classloader? 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? 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. But it sounds like there's a serious disadvantage
to this approach.
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?
Thanks,
Aaron
> Let me be explicit:
> Bean A has following classes:
> ABean - the bean
> AHome - the home interface
> ARemote - the remote interface
> Bean B has following classes:
> BBean - the bean
> BHome - the home interface
> BRemote - the remote interface
>
> Bean B wants to access bean B. As always, in order to talk to components
> through an interface, that interface must be available. So, package
> ABean,AHome and ARemote in A.jar and deploy, and package BBean, BHome,
> BRemote, Ahome, and ARemote in B.jar and deploy. Any B instances can now
> access the A component.
>
> Makes sense?
>
> regards,
> Rickard
