On Jan 9, 2006, at 4:55 AM, Dr. Michael Lipp wrote:
I have been using Jetspeed2 with JBoss for quite some while now,
deploying it as an EAR.
Basically, I agree with David. I use the tomcat-special artifact
jetspeed.war as a start, split it in its components, reorganize them,
pack a WAR for Jetspeed and WARs for the portlet applications and
finally pack all of this in an EAR. All libraries that have to be
"shared" (i.e. go into the tomcat shared directory) are excluded from
the WARs, but added to the EAR and loaded as Java modules in the
application deployment descriptor (application.xml). So, of course,
I'd
also rather start with a proper set of libraries, layout directories
etc. and some assembling instructions. IMHO, this is what would
constitute a "proper" Jetspeed2 binary distribution.
I like this description.
What I dislike about David's approach is that it is too Geronimo
specific. IMHO there is a "Servlet"-packing and an "EAR"- or
"ApplicationServer"-Packing of Jetspeed2. The vendor specific
deployment
descriptors of all application servers can co-exist, so we need no
vendor specific directories for the application server packing. The
only
issue that may require vendor specific handling is adding the "bridge"
that allows the application server to access the user/password/role
information maintained by Jetspeed2. But from experience, I know that
several such modules can also co-exist in a single EAR that can be
deployed in different application servers. (I'm not sure about David's
approach: if you want to access user/password/roles information
maintained by the application server in Jetspeed, then things are more
difficult. But I don't think this is a good approach anyway. And
thinking about it, it may still be possible...)
So the bottom line is, please do not approach this by focusing on
geronimo, as this will restrict the possible uses of Jetspeed
unnecessarily. Whatever you do, do base it on the J2EE standard and do
it at least for two application servers in parallel. Else you won't
really notice when you are doing something the moves you away from the
standard towards some proprietary specialty of the application server
you use.
I think that is a very good point and I completely agree that biasing
jetspeed toward a particular app server is not a good idea. I do
think that having everything needed to deploy jetspeed in the best
possible way on each app server is a good idea. I was trying to
describe what I got to work in geronimo and explain how i thought it
might be possible to accomodate both geronimo and tomcats needs at
the same time. At this point I don't share your hope that a single
ear can be deployed on several app servers. For instance, geronimo
needs a geronimo-specific jetspeed valve in pipelines.xml. Of course
it may be possible to eliminate this valve by use of JACC directly,
but this remains to be seen: it would certainly require some other
modifications e.g. to the session tracking code.
thanks
david jencks
Regards,
Michael
David Jencks wrote:
On Jan 8, 2006, at 11:48 AM, David Sean Taylor wrote:
David Jencks wrote:
After working on the geronimo integration for a bit I have an
opinion on what the most important reorganization step is :-)
The current jetspeed.war is basically a tomcat-specific artifact.
In order to work in geronimo, I had to build a jetspeed war
without
any classes or lib entries. I think the current war should be
built
in a module inside app-servers rather than as the top level
artifact. I also think there needs to be either separate builds
for including different amounts of lib jars or a way of
customizing
the build to include different jars. (In M2 I think profiles
give
you some control like this).
Just curious, where did you put the jar files if not in WEB-INF/lib?
A geronimo serve is constructed out of configurations, which
consist of
a classloader and some components. The classloader can include
classes
packed in the configuration and some (external) jars (from the
maven-like geronimo repository) and can have multiple parents. For
example, a j2ee application (ear file, war file, etc etc) gets
turned
into a configuration. We can include jars from the repository in
the
ear configuration rather than including them directly in the ear:
this
avoids duplication.
So, I have one (non-j2ee) base configuration that has the jars
that in
tomcat go into shared, and an ear that has jetspeed.war and all the
portlet apps in it. In order for this to work in geronimo, I
have all
the jars that for tomcat are packed into jetspeed.war listed as
external dependencies of the ear. I could not get the
deployment of
local portlet apps to work from inside jetspeed.war, so I hacked
up the
regular jetspeedComponentServlet to accept local wars and determine
that they are local by whether they start with jetspeed-.
I'm more or less amazed at the number of jars included in
jetspeed.war. I strongly suspect that 90% of them are needed
only for
the portlet apps and wonder if there is some way to make that
clearer.
In geronimo we can do that easily but that would not work for
non-geronimo jetspeed setups.
But yes, I agree with you - we need to assemble the distribution as
different configurations. Its always more or less the same jars and
classes, but just a different way of packaging for different app
servers. This sounds very much like Raphael's suggestion to have a
different configurations. Here is my interpretation:
/jetspeed-components
(all the components go here)
/configurations
/tomcat
/configuration-1
/configuration-2
...
/geronimo
/configuration-1
/configuration-2
So if someone wanted to build geronimo with configuratoin-2, they
would build the project under /configuration/geronimo/
configruation-2
I'm also not exactly sure what the meaning of most of the stuff in
jetspeed.war is. My uneducated impression is that there are at
least one skin and a site layout. Assuming this bears some
relationship to the actual contents, I think that having these as
separate modules that are unpacked into the jetspeed war would
make
it much easier for someone to either construct additional
skins or
assemble a portal with exactly the parts they want to use.
the Skins are called decorators, and they are really CSS styles for
pages and portlets
decorators can be re-used by different configurations
they could be stored in a separate project
/decorators
Layouts are descriptions of how pages are aggregated such as two
column, three-column, one-column, nested. Layouts could also be
stored as a project
/layouts
A configuration can define its own decorators and layouts (I dont
really see a use case for that though), or include in a
decorator or
layout in the configuration
The site is made up of pages, folders and subsites
Im thinking that a configuration needs to have a default site with
it, although a big part of customizing your own portal is defining
your own site layout (pages, folders).
A custom portal configuration is really the combination of all
of the
above, including the application server destination
Excellent, thanks for the explanation. I think making this
modularity
clearer would really help newbies understand how to set up their own
portal.
thanks
david jencks
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: jetspeed-dev-
[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
