geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: More port conflicts
Date Wed, 12 Oct 2005 10:48:52 GMT

Dave Colasurdo wrote:
> David Jencks wrote:
>> On Oct 11, 2005, at 4:37 PM, Dave Colasurdo wrote:
>>> David Jencks wrote:
>>>> On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
>>>>> Quite frankly, I'm not sure I see the value of having multiple web 
>>>>> containers simultaneously active within geronimo.  Has anyone heard 
>>>>> of a  use case or user that is asking for this support?
>>>> I don't think there is any practical use for it outside of 
>>>> experimenting with both web containers at once.  It also makes 
>>>> running the tck much easier.
>>>>>   IMHO, I suspect the vast majority of users will choose a single 
>>>>> web container (at build or install time) and stick with it.  If 
>>>>> future requirements dictate a switch to a different container, then 
>>>>> laying down a new installation doesn't seem unreasonable.  In fact, 
>>>>> Geronimo doesn't currently even support incremental maintenance.  I 
>>>>> would think the use case for non-destructive upgrade would be much 
>>>>> more prevalent than changing internal components on the fly.
>>>>> While simultaneous active web containers would be a technical feat, 
>>>>> I'm really not sure the overhead and added confusion to users are 
>>>>> worth the payoff..  My $.02
>>>> I prefer to keep this as standard at this point to ensure that our 
>>>> architecture remains clean enough to support it.  I look forward to 
>>>> the installer being sophisticated enough to be able to include the 
>>>> correct components for only one web container.  At the moment, it 
>>>> includes all components and only starts selected ones.
>>> If there is no immediate practical use for it outside of TCK testing, 
>>> wouldn't it be beneficial to the users (who are hopefully flocking to 
>>> the newly certified J2EE server :>) ) if the default behavior was 
>>> more inline with their expectations rather than confuse them with 
>>> behavior that is somewhat confusing and that they will likely not be 
>>> leveraging?
>>> The changes to the installer seem like a reasonable plan.  How about 
>>> users that download the binary zip/tar images?  Shouldn't they also 
>>> have a simple default way to utilize only one web container.  It 
>>> seems this is what most users would want.  It appears that the 
>>> current M5 default behavior is starting both web containers..
>> Well, what do you suggest?  At the moment the way to switch to a 
>> single web container is to copy 2 text files over 2 other text 
>> files.   Instructions are in the M5 release notes.  The alternative to 
>> starting both web containers by default is to start neither: we can't 
>> play favorites.  We don't yet have a maintainable way of building 2 
>> entirely separate distributions.  I hope we can get there by 1.0, but 
>> it's going to take a substantial revision of our assembly process to 
>> use the packaging plugin and the assembly plugin: even with sharing 
>> the configurations between distributions it will mean a very 
>> substantial increase in maintenance to ship 2 versions, and I am not 
>> at all sure it is worth the trouble if we can provide a 
>> single-container choice using the installer.
> Concerning the non-installer images..
> Hmmm.. I guess one of the problems is that many folks will not view the 
> release notes and just try to use the the application server ( I am 
> guilty of this).  Some initial thoughts that come to mind to address this:
> Binary Distributions (assuming now that G is certified there will be 
> more frequent binary images available) - I suspect the audience for 
> these binaries will primarily be users and not G developers..
> 1) Default to no webcontainer and spell out in BIG BOLD COLORED LETTERS 
> ON THE DOWNLOAD SITE that you need to choose a webcontainer via the 
> config files. If the server is started w/o a webcontainer, spit out yet 
> another reminder message..
> 2) Have a separate binary image for both the Jetty and Tomcat 
> webcontainers.  I'm not suggesting biting off the whole task of revising 
> the assembly process but rather just merely having two binaries each 
> with a separate set of config files (config.xml, config.list).  This 
> could even be a post-build step done on the common image. This isn't 
> very technically interesting but clearly communicates to users that 
> there are two separate environments and they select the download that 
> they want.  Of course, this goes away if/when the assembly revision is 
> complete.
> 3) Have no default config in the binaries.  Have the jetty and tomcat 
> config files available as a separate download (right on the same page as 
> the binary images).  Clearly document that one of the containers needs 
> to be chosen.  (I don't like this option)..
> 4) Default the binary distribution to one of the web containers.  You 
> can use MagicGball to decide which one :>) Clearly indicate on the web 
> download site that this can easily be changed by updating the config 
> files..
> While none of these options are too technically exciting, they do 
> address the problem of users inadvertently starting G with multiple web 
> containers and getting confused. We don't want users to have a bad first 
> impression..
> Source Tree distributions
> Can't there be a simple argument or property that is specified at build 
> time to denote which webcontainer (or both) will be used.  The build 
> will then seed the resulting image with the correct copy of config.list 
> and config.xml..  Again this doesn't address the major revision of the 
> assembly process but provides a simple way to create an image that has 
> the webcontainer(s) config that you want.  Hmmm.. perhaps this is 
> overkill as developers should already know about config.list and 
> config.xml..
> Hope I haven't beat this issue to death, just want to try to keep it as 
> simple as possible for users...
> Thanks

As I mentioned in my original note, I too think that we need to provide 
some means to ensure just one container is active in the initial 
download and provide an easy way for the user to select which one. 
However, I don't think that any of the 4 options listed above completely 
address the concern because they all seem to keep the configurations for 
the non-selected container deployed.  #2 is close if we make it a little 
  bit more sophisticated.  In addition to providing two assemblies with 
the appropriate config files the post-build processing could also ensure 
that the only pre-deployed applications are the ones for the selected 

WRT the source tree distribution, we could just make the post-assembly 
processing available to as well.  The user could choose to keep both 
containers (and all configurations) or perform this additional step to 
narrow it down to just one container.


>> thanks
>> david jencks

Joe Bohn

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

View raw message