Thanks for sharing the details of your approach.
I am tending toward multiple virtual and real machines with an Apache
proxy in front of the whole set.
We currently only have 2 portals in production (on separate real
hardware) with a 3rd in a very slow development process so you are way
ahead of me in having to deal with the practical realities.
Ron
Ron McNulty wrote:
Hi Ron
Yes, there is always tension between sharing and not sharing libraries.
I work in an environment supporting about 15 moderately large portal
apps on the same portal infrastructure. Originally we used a shared
library approach, but changed to a per-application structure. The
problem was that project X (a new product) would decide to use version
bazzillion of say Spring, and 10 older versions had only been tested
with version 1.0 The regression testing was getting onerous.
I note you mention "each portlet". We normally group around 5 to 10
portlets into their own portlet application, so the size of the
resulting war is not a huge consideration.
Best of luck whatever path you go down.
Regards
Ron
----- Original Message ----- From: "Ron Wheeler"
<rwhee...@artifact-software.com>
To: "Jetspeed Users List" <jetspeed-user@portals.apache.org>
Sent: Wednesday, September 09, 2009 2:00 AM
Subject: Re: axis jar files in jetspeed
We have wrestled with this a bit and finally decided that:
1) We were only likely to run one application (Jetspeed Portal) in
our Tomcat. If we need another servlet app with its own libraries, we
will add a real or virtual machine with its own Tomcat (or other
servlet container).
2) We did not want to have different version of libraries in our
different portlets.
3) We did not want lots of huge portlet war files each mostly
consisting of the same libraries.
As a result, we opted for Ron's option 2. With Maven, we mark all of
the shared libraries as "provided".
This has helped a bit in keeping the team on the same set of library
versions and has made the portlets a lot smaller.
If we ever get a spare moment, will create a shared POM fragment that
included all of the "official" shared libraries.
Apparently, this can be referenced by the individual portlet POMs so
that we can be sure that everyone on the development team uses the
"right" version in their testing.
Option 1 is not a bad way to start but pretty soon it gets very bad
as libraries get copied from one portal project to another and you
start to accumulate unused libraries in projects and you get
different versions of libraries in different portlets.
It does not have to be like that but human beings under time pressure
can succumb to the need to "just get it working".
Ron
tony ennis wrote:
Thanks Ron. I opted for your "it's only a POC" approach which
worked fine.
Ron McNulty wrote:
Hi Tony
The are two places you can put it:
1. In the WEB-INF/lib folder of your portlet application. Here it
is personal to your web application, and different apps can use
different versions.
2. In the $JETSPEED_ROOT/lib directory. This adds it to Tomcat's
shared libraries so it becomes available to all apps.
For a POC, choice 1 sounds best. You should only need the axis
run-time war(s).
Regards
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
