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: Reorganizing Jetspeed repository
Date Mon, 09 Jan 2006 12:55:21 GMT
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.

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.

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


Mime
View raw message