geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: More port conflicts
Date Wed, 12 Oct 2005 21:08:54 GMT
To give my 2 cents on this thread:

 - It's true that the startup sequence reports the port of the first
connector it finds no matter what.  We need a way to associate
applications with containers.  I looked to see about registering a
dependency during deployment, but it wasn't obvious how the deployer
knew what container it was deploying to.  If someone can spell that
out for me, I'll make the startup report work.

 - I don't think it's very good to distribute a build with both
containers present and active.  (as far as end users go; TCK testing
with that build is fine.)  I think the easiest path forward is a
post-processing step that starts with the current assembly output,
puts in a proper config.xml, and undeploys the stuff for the server
it's not using.

 - I don't much like the idea of having separate startup scripts for
separate containers.  The problem is, if there are two there, how are
you sure that the user is always going to use the right one?

 - It would also be possible to ship by default with nothing enabled
but a special GBean that would prompt you for which configuration you
want, copy in the right config file accordingly (which would not
include itself), and shut down the server.  So the first time you run
it would start practically nothing, ask whether you want Tomcat or
Jetty, tell you that the server has been configured and you need to
restart it, then shut down.  This would not be necessary if you used
the installer, only the ZIP.

 - It would be nice if the installer could force you to pick Tomcat or
Jetty but not both -- but I don't think IzPack has "radio button"
equivalents for the package selection screen.  But we can probably
hack it to offer port selections for both servers (if both are
selected) and barf if any of them conflict.


On 10/12/05, Matt Hogstrom <> wrote:
> com> <> <>
> In-Reply-To: <>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Content-Transfer-Encoding: 7bit
> X-MMS-Smtp-Program: Macallan-Mail-Solution; Version
> X-MMS-Smtp-Auth: Authenticated As
> X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version
> I like this better.  See my other note as to updating the Welcome Page.
> +1
> David Jencks wrote:
> >
> > On Oct 12, 2005, at 11:48 AM, Dain Sundstrom wrote:
> >
> >>
> >> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
> >>
> >>> 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.
> >>
> >>
> >> +1 this is a reasonable compromise.
> >>
> >
> > OK, one more idea for the list...
> >
> > I'm into testing on making  config.xml serve as both the attribute store
> > and the persistent configuration list.  When this works, I think it
> > would be useful to have a command line parameter that sets the
> > location/name of the config.xml file to use  (maybe a system property).
> >  Then we could choose the configuration on the command line
> >
> > java -jar bin/server.jar -Dgeronimo.configuration=geronimo-jetty.xml
> >
> > Scripts could remove the need to know the  file name :-)
> >
> > ./geronimo-jetty
> >
> > Would this be adequate and remove the need for separate distributions?
> >
> > thanks
> > david jencks
> >
> >
> >
> >

View raw message