We wound up taking a similar approach as Kaj describes, we used 1 jar per
package. So far it's worked very well from both a development and a deployment
perspective. We only a had a few developers working on the EJBs so there wasn't
a large overlap of programmers in the same package at the same time, but as long
as you use some type of source control mechanism you should be fine.
We used WebLogic and I based a few build scripts on their examples. These
scripts allowed me to just recompile & ejbc the source code that was changed.
The whole process of rebuilding and re-jarring took only a few seconds.
One of our developers preferred 1 jar per EJB during development to ease
debugging, but using the build scripts I found no problems with the 1 jar per
package approach.
The biggest advantage I found over using just 1 big jar file was that it was
easier to replace the old package jar with a new one, leaving the other jar
files untouched when moving from the development environment to the test
environment. Having multiple programmers all modifying the same single jar would
seem to be unworkable to me. Obviously this doesn't apply if you're a one man
shop.
Lou Bona
Chief Software Architect
AgentGo.com
Kaj Bjurman wrote:
> Hi,
>
> I can give you my few cents on this...
> At first we (our project) tried to put all EJBs in one single jar, and that
> was a big mistake.
> Why?
> Well, we are several developers in the project, and we are still designing
> and developing beans, and it got pretty burdensome to recompile and jar all
> beans when we made one change to a bean. (That could however be solved by
> using Ant to build things.) After we had built the jar-file we needed to run
> weblogics tool for generation of stubs and skeletons, and this took more
> than 10 minutes (because of the size of the jar, and that the tool/compiler
> is pretty slow).
>
> After that we have changed our approach, and now we put all logically
> related beans in separated jars. With logically related I mean EJBs that
> they are in the same package. That is, we have accounting EJBs in one
> package, Service EJBs in another package, and so on.
>
> We decided to use this approach since we thought it would be too fine
> grained to put all EJBs in separate jars. And I also think that you pretty
> soon will get into problems if you have dependent EJBs in separate jars.
>
> /Kaj
>
> > -----Ursprungligt meddelande-----
> > Fr�n: Shiv Kumar [mailto:[EMAIL PROTECTED]]
> > Skickat: Wednesday, August 30, 2000 8:38 AM
> > Till: [EMAIL PROTECTED]
> > �mne: Multiple EJBs in single jar
> >
> >
> > Hi all
> >
> > I posted this question two days back. I did not get any
> > useful response.
> > Forwarding it again..
> >
> > I have a stateless session bean calling different entity
> > beans. I would like to
> > hear on how to jar all these EJBs.
> >
> > Basically, I have two choices :-
> >
> > * Have one separate Jar for each EJB (one session and
> > other entites)
> > * Have a single Jar for all EJBs (session and entities)
> >
> > What is the recommended approach? What is the advantage/disadvantage?
> >
> > TIA.
> > --
> > shiv
> > [EMAIL PROTECTED]
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
