Thanks for this information. I wasn't aware of this feature of a j2ee application server. Perhaps Geronimo can be used in this way since it is now a 1.4 certified application server. Although I prefer the Tomcat only deployment, having subprojects for installing on different servers would attract more users.
Philip On 11/17/05, Dr. Michael Lipp <[EMAIL PROTECTED]> wrote: > You'll never really solve this in the context of a servlet only > container, because it wasn't made for this. > > I'm packaging Jetspeed as an EAR for some time now (and will hopefully > still be able to do this after the upcoming changes ;-)). It's not > always the use of EJBs that makes you move to a more complete J2EE > environment. > > The problem with a servlet only container is that you have no common > repository for the modules of your application. You just have each > modules' repository ([WAR]/WEB-INF/lib) and your servlet containers > repository (tomcat: shared/lib) that does not know of application > boundaries, i.e. it holds everything that any two servlets consider > "must share". Of course, this setup is bound to produce classpath problems. > > EAR (application) packing knows about web-modules as well as java > modules (well, and ejb modules, but Jetspeed2 doesn't need them > currently). Everything that must be shared among web-modules is put in > the EAR as a library (often in [EAR]/lib, though contrary to WAR > packing, this has no functional significance) and declared as java > module (if only used from EJBs, you can use manifest references instead > of explicit loading as java modules). The application gets its own > classloader and the web-module's classloaders are children of the > application's classloader, thus finding (and sharing!) the libraries, > i.e. java modules. > > Of course, there are many people that happily use tomcat, but think > using JBoss is evil, although it does nothing but put tomcat in a more > powerful environment, see above. > > I therefore think that the Jetspeed2 project should not try to solve a > problem that has already been solved. It will propably be possible to > find some working balance between putting lots of libraries in > shared/lib (until classpath problems occur) and leaving them in the WARs > (until disk is full). But IMHO there is no need to invest in optimizing > this, as the mechanism to optimize this is already here. > > Regards, > > Michael > > José Antônio Rosa dos Santos Jr wrote: > > Why not just move all the jars to a shared directory and reference > > them in the manifest of each application? > > > > On 11/17/05, David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > >>Chris Schaefer wrote: > >> > >>>Hi folks: > >>> I've been working on getting antinstaller to install jetspeed, > >>>working with derby, inside tomcat, to a users computer. it's going > >>>well. but the finished product which is basically the jetspeed-2 > >>>source allBuild inside tomcat w/ derby is now pushing 200 MB. This > >>>is ludicrous!!! > >>> > >>> Why? well, we have over 200 jar files almost all of which are > >>>duplicated in the install. Some, like log4j, have roughly 10 copies. > >>>Many have 8 copies of a particular jar ( BTW, we have different > >>>versions of some of the jars as well ). > >>> > >>> Perhaps a diet is in order? I don't have a plan for this, but I > >>>figured I'd launch the discussion. > >>> > >>> The root of the problem is that we package each of our sub- projects > >>>(applications/pam for example), as though they must stand alone. Yet > >>>pam clearly cannot work outside of the context of jetspeed itself. > >> > >> > >>We can't move the common jars into jetspeed.war because of the > >>classloader, the portlet apps won't see them there. > >> > >>However, I think we could *try* refactoring common stuff into shared/lib > >>I know in the past, this created classloader bugs, so we should be careful > >> > >>A proposed quick diet solution: > >> > >>* combine security, pam, palm into one jetspeed-admin webapp > >>* combine 2 JSF webapps into one, move the combined project to Bridges > >>* combine 2 Struts webapps into one, move combined project into Bridges > >>* combine RSS, demo into demo portlet (stays in Jetspeed) > >>* move Perl, PHP apps into Bridges, do not load them as default part of > >>Jetspeed deployment > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Philip Donaghy donaghy.blogspot.com del.icio.us/donaghy connection.oreilly.com/users/profile.public.php?user_id=4371 www.linkedin.com/profile?viewProfile=&key=1811119 www.capferret.org Skype: philipmarkdonaghy Office: +33 5 56 60 88 02 Mobile: +33 6 20 83 22 62 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
