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. Aaron On 10/12/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > com> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > In-Reply-To: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > Content-Transfer-Encoding: 7bit > X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 > X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] > X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 > > 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 > > > > > > > > > >
