geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Splitting up the server into a few more chunks
Date Wed, 08 Aug 2007 07:27:27 GMT
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
> On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
>> we should consider the more drastic changes, like moving the base  
>> Admin Console support (via Pluto 1.2) out to /plugins
> I really like that idea for a couple of reasons -
> -  it allows us to keep the admin console that's currently at  
> server/trunk/applications/console in place until the new extensible  
> admin console is ready and can scale up from minimal to full JEE5  
> functionality plus debug views, etc.
> -  I like the idea of streamlining server/trunk for JEE5 stuff and  
> moving the optional stuff  elsewhere
> My only reservation (and its no biggie) is that using the location / 
> plugins for optional stuff is misleading since there will be stuff  
> in server/trunk that's required for JEE5 (i.e. not optional) but  
> implemented as plugins like tomcat, jetty, amq, openejb, etc.     
> Calling something a plugin is a statement about its packaging and  
> deployment mechanism, and not whether it is required or optional.
> So maybe "/opt" or some such would be a better place to put the  
> extensible admin console, tuscany (eventually), directory server,  
> samples, roller, etc...

Personally, I don't consider the bits in /plugins as _optional_...  
simply a home for the plug-able components and features that can be  
dropped into the base server to make Geronimo do something useful.

After thinking about this more, I think that probably _most_ of the  
stuff under server/trunk can get converted into a plugin and moved to  
its own plugins/<component>/trunk, released and managed independently  
of the core server framework.  If we need to update the plugin bits  
to make this work for more stuff, then we should do that, though I'm  
not sure that is needed atm.

Then we'd end up with relatively smaller projects per feature/ 
component, a medium-sized project for the core server, and then a  
project for the assemblies which we deliver (ie, the javaee bits,  
which aggregate the javaee components, the server framework and the  
configuration required to make it all work out of the box).

The only thing we have to be careful of is to not end up with a  
massive set of versions to manage, so perhaps components need to have  
some detail that indicates which version of the server they are  
compatible with or something like that.  I dunno... anyways, its  
going to take some more discussion and planning before we can get to  
making this a reality, but I really trully do believe that we *must*  
do this to scale the management and development of Geronimo.

>> and start moving the Portlets into the actual modules/configs that  
>> they administer....
> I like this idea from a conceptual point of view since it keeps  
> things neat and well organized.  But I am not sure how to implement  
> it since the main geronimo components are typically packaged in  
> JARs, and the admin portlets for a component have to be packaged in  
> a WAR (that's just the way that pluto works).  i.e. a JAR can't  
> contain a WAR.
> Some options I can think of:
> -  use EAR as the packaging format for all geronimo components and  
> package the admin WARs inside them
> -  maintain geronimo components and their admin WARs separately.  
> bind them at deployment time via the plugin installer's dependency  
> resolution or by some enhancement to the maven car plugin
> -  package the geronimo components as WARs so the admin portlets  
> can be merged with them.  (seems like the tail wagging the dog)
> -  follow some organizational structure like in your previous email  
> where each geronimo component has a module, config, and (now) WAR  
> subdirectory
> Just brainstorming here...

Um, I dunno... maybe some of the new magical console stuff that is  
going on can help.  But my guess is we might have to implement a  
dynamic portlet, which can be given an artifact from the repository,  
and then load the real impl from that artifact and display it.  Then  
the portlet bits per component can be bundled into a jar and tossed  
into the repo, and then the console can be configured with a list of  
artifacts to load into portlets.  Seems like that might work out  
well, if the dynamic portlet impl simply handles the bridge to the  
portlet impl in the artifact and once loaded, basically proxies  
everything over to it.

'm just brainstorming too... and having *never* written a portlet in  
my life... maybe it will work, maybe it won't...

Though, this is one area where I think a full portal impl like  
jetspeed2 might be of help since its already got all the juice to do  
this kinda dynamic portlet muck... or at least I'm hoping it does.  
I'm just generalizing my experience with php portals like phpnuke and  
postnuke which have this kinda plugabiliity built in.

I really do think though that this is really positive direction... as  
right now the console is a horrible coupling point with all of the  
bits inside of the server... and if we are going to start pulling  
things apart into smaller more manageable chunks, this is certainly  
one key component that will need to be re-factored to allow it to  



View raw message