portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Mark Donaghy <philip.dona...@gmail.com>
Subject Re: a diet...
Date Thu, 17 Nov 2005 13:42:58 GMT
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 <Michael.Lipp@danet.de> 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 <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
>
>


--
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message