Hi,
I'm just starting to dig in EJB so my points might not be valid
but anyway:
Imagine a company that developes and sells various EJB beans,
say "customer" bean and "car" bean. One of their customers might
buy the "custmer" bean and an other one would by the "car" bean,
maybe someone would buy them both. So I guess that it would
make sense to put those beans in separate jars.
Also same thing for internal business: If you maintain
a system with many different beans, woudn't it be a little
bit hard to re-build a huge jar every time you update your code ?
However, building several jars is not good if parts (ie. remote interfaces)
must be deployed by putting multiple copies of them in different
jars.
Ari S.
----- Original Message -----
From: "danch" <[EMAIL PROTECTED]>
To: "jBoss" <[EMAIL PROTECTED]>
Sent: 21. hein�kuuta 2000 7:14
Subject: Re: [jBoss-User] Using jboss.xml to add to the classpath
> Is the 'One bean per jar' habit from the book perhaps a result of EJB
> 1.0 legacy?
>
> Vaughn Vernon wrote:
> >
> > Hi,
> >
> > Rickard �berg wrote:
> > > I think you need to move your understanding of a jar from the
practical
> > > towards the intention of a jar.
> > > ...
> > > So, the first question is: why have you put two interrelated
components
> > > in two jars instead of one?
> >
> > I think the answer is in Ken Jenk's post:
> > >> I'm still trying to get the examples from Monson-Haefel's "Enterprise
> > >> JavaBeans" (2nd Edition) to run in jBoss.
> >
> > That book has taught probably tens of thousands of programmers to divide
the
> > app up into separate jar files. Just a brief glance through some of the
> > chapters shows this; the build script shows no less than six jars. In
> > principle I agree that an app should house all classes it needs in a
single
> > jar, if only things were that simple.
> >
> > > 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...
> > > by placing the interfaces of one bean in anothers jar
> >
> > In reality I believe that will be impossible. For instance, what if a
new
> > ejb app is supposed to use another ejb app or set of components (in
effect
> > becoming a client to the older app)? Can the app builder be expected to
> > extract interfaces from the older jar to place in their new jar? Or can
the
> > app builder be expected to place their new classes in the older jar?
Pardon
> > me if I am off base here, but aren't we talking about the same thing as
Ken
> > first discussed -- making TravelAgent see Cabin?
> >
> > I think Ken will be able to get his app to work the way you stated, but
it
> > is not the way the book author intended for it to work. There are not
only a
> > bunch of books out there, but the author has the app working on several
> > servers, including j2ee ri, with little or no changes.
> >
> > So what if Monson-Haefel asked: "How do we get TravelAgent to see
Cabin?"
> > :-)
> >
> > Vaughn
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
