portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Reorganizing Jetspeed repository
Date Mon, 09 Jan 2006 17:34:49 GMT

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.

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: 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

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

View raw message