Hi!
danch wrote:
> > 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.
> In addition to Rickard's response to this point, remember that Bean
> Provider and Application Assembler are two distinct J2EE roles: just
> because a one provider gives me a Customer bean and another an Order
> bean doesn't mean I don't assemble them into one jar.
An extremely important point. However, as pointed out by Marc, and which
is critical, the really good way to do this is to use EAR files. That is
the holy grail IMO.
> > 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.
> Generally a developer (Bean Provider) would go through modify-test-debug
> cycles in a test environment where they'd deploy the one bean they're
> working on. From there it would move to an integration test environment
> where it would be packaged into the full application jar (actually it
> really ought to be an ejbjar in a .war file). The roll into integration
> test is probably an automated weekly build.
I don't think its a good idea to put an ejb-jar file *into* a .war file.
However, deploying a .war file along with the client-jar aspect of EJB's
would be a good idea.
Tricky stuff :-) Good we're having this discussion BTW.
> Organizations that have been building large systems with large teams for
> any length of time will have automated the build
(Ant, Ant, Ant.. love it.. 8-)
> and roll into
> integratioin test long ago: EJB just adds a few wrinkles (well, a lot of
> wrinkles, since some vendors haven't implemented command line deployment
> tools, which makes a scripted deploy a wee bit difficult)
Indeed. We have it though (the /client/deploy.jar tool)
/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]
