Hi!
Vaughn Vernon wrote:
> That book has taught probably tens of thousands of programmers to divide the
> app up into separate jar files.
Hence providing only a practical view of the jar as a concept, hence
focusing on the "what" and not the "why", which in all learning is key.
Too bad.
> 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.
If they are, they are, if not then not. Either way is not an inherent
attribute of applications.
> > 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?
Yes, or otherwise the app builder is flawed. Do you not need these
interfaces to compile the classes in the new jar? Do you then not have
these interfaces available?
Also, note that what is being referred to here are the classes that
would normally go into what is termed the "client jar", and which is
referenced in the EJB-JAR XML descriptor. So, any component adhering to
this more reusable form of jars (i.e. having two, one if which is for
deployment, and one of which is for clients, both applications and other
EJBs) would be easy to reference in new applications. That is the
intent.
> 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 believe the original query was about two beans that were essentially
forming one application, hence should be placed within the same JAR.
There is no black and white here. Make informed decisions. My view would
be that of the above, but others could be equally valid.
> 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.
Then how did he intend for it to work? Is this stated?
> 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.
Food for thought: does this point to a flawed execution/understanding
from all of the above parties of the intent of the specification, or the
validation that the approach used is right? ...
> So what if Monson-Haefel asked: "How do we get TravelAgent to see Cabin?"
> :-)
If both are part of same application -> package in same jar.
If they are part of two separate applications (each comprising one
bean..?) -> package in two jars with shared interfaces.
Makes sense?
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
