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]
