portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Michael Lipp" <Michael.L...@danet.de>
Subject Re: a diet...
Date Thu, 17 Nov 2005 13:16:56 GMT
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 <david@bluesunrise.com> 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: jetspeed-dev-unsubscribe@portals.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message