geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Date Sun, 11 Feb 2007 17:06:21 GMT
I would love to have a way where people can download the uber tar  
ball which includes all the bits we have at the time and let the user  
choose their server type and personality.  I believe that a majority  
of our users are looking more for a server assembly that is a Java EE  
5 server with the bits they need to develop Java EE applications (and  
or deploy them).   What seems manageable to me is that we choose a  
finite set of Java EE 5 assemblies (no more than two based on Jetty  
and Tomcat given our history, that are certified.  Dain made a  
comment and I've heard similar things that to be certified all modes  
of operation must be exercised and I think that someone might  
reasonably apply it to all the pieces of the uber server.

Based on feedback I've gotten from users I know that I often hear  
Tomcat and OpenJPA as a combo they are interested in.  As far as the  
web services piece I haven't really heard a strong preference one way  
or another.  however, since that's not my strong suit that's not a  
good indication of anything.  Do others have feedback in this area?

For purposes of this discussion I'll throw out the following combos  
for discussion:

Tomcat, CXF and OpenJPA
Jetty, Axis 2 and Cayenne

The benefits are that it pretty much does cover all the major  
technologies in terms of fitting them together.  Using DayTrader, we  
should be able to deploy DT unchanged (app or DDs) on both  
assemblies.  The desire would be that we have a common abstraction  
point so that if someone wants to use Jetty, CXF and OpenJPA that it  
should be a simple matter of selecting the appropriate plugins.  That  
said, I'd prefer to not try and provide the universal adapter that  
can configure everything in the world and lose site of delivering a  
Java EE 5 container for users to look at in time for Java One (my  
personal desire I'll admit).

I'll defer to the guys actually working on TCK to tell us what they  
are planning on certifying as they are doing the bulk of the work.   
What makes sense to me is to have at least one that is certified  
(more is nice) and that we keep the train moving and offer additional  
certifications over time as interest and TCKing deliver.  To make the  
proposal concrete our download page would have:

*Java EE 5 Certified*
Tomcat, CXF, OpenJPA
Jetty, Axis2, Cayenne

Windows and *nix versions.  An uber (you can create your own  
personality would be awesome.

On Feb 11, 2007, at 12:40 AM, Jason Dillon wrote:

> On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote:
>> I agree that this approach would avoid network dependency but I'm not
>> as convinced that network access presents a problem.  Most of the
>> installers I've used lately depend on network access in one way or
>> another.  I also suspect that users will customize their server right
>> after downloading it.
> Many installers I've seen allow for light version which rely on the  
> network to fetch components, and have a complete version which  
> includes all of the components.
> From an automation perspective it would be best not to add more  
> network dependency, so that once we have a distro zip, we can  
> assume that personality configuration will function with-out  
> unexpected failures due to network issues.
>> Besides a smaller download size, the plugin approach has the  
>> advantage
>> that the CLI and admin console are already available for driving the
>> server customization process.  Should we invest  additional effort in
>> providing the user with another way to achieve effectively the same
>> results?  If so then will it be clear to users when to use the plugin
>> installer vs. when to use this alternative mechanism?
> IMO, the personality bits are simply collections of plugins  
> (perhaps a few non-plugin cars) to be applied to a base  
> installation.  I think the concept is complementary with what we  
> have now.
>> One other factor to consider is that the "one big assembly" approach
>> would only deactivate components when they are replaced and not
>> actually uninstall them (at least if I understand your proposal
>> correctly).  If the deactivated components were later reactivated  
>> from
>> the admin console or from an environmental dependency then the server
>> could enter an unusable state.
> Sure, that is a danger... though that danger exists today.  I was  
> not suggesting any specific implementation, but one solution would  
> be to ship all of the extra components for personalities in a  
> different repository dir, then the personality application tool  
> would install from one repo to another.
> But, really, we probably need to create some mechanism to classify  
> types of plugins, and then warn the user if they are attempting to  
> enable/install a plugin which collides with another plugin already  
> installed.  For example, if there a Jetty plugin already installed,  
> trying to install Tomcat would warn strongly that a duplicate  
> "webcontainer" plugin was already installed (and let them install  
> it if they know better than we do).
> RPMs do something similar with its 'provides' tag in spec files...  
> so for example, the apache httpd RPM package might provide  
> 'webserver', fnord (another light http server) might also provide  
> 'webserver' and when apache httpd is already installed, attempts to  
> install fnord will barf with a conflict (which can be forced to  
> override).
> --jason

View raw message