In that case then I would assume that this isn't a configuration option
then but rather part of the install processing. This way there would
not be a case where the user could accidentally deploy apps before
choosing or changing the web container.
Assuming that the container selection is part of the installation then
it should also address my last concern about "pre-deployed"
applications. I suppose we would just make the deployment of these
applications part of the installation instead of part of the build.
Joe
Matt Hogstrom wrote:
I think its reasonable to choose one before starting to deploy
applications. Dynamically (easily) switching WebContainers would be
nice but I don't think its a must have. I agree with the easy to choose
at initial deployment.
Matt
David Blevins wrote:
I don't know about others, but I was referring to an easy way to
setup jetty or tomcat just once before people deploy apps. As far as
pre-deployed apps, no idea how to work that out.
-David
On Sep 26, 2005, at 6:29 PM, Joe Bohn wrote:
I'm still not sure if I completely understand the approach for "easy
switching from Jetty->Tomcat".
- If applications have already been deployed to say Jetty before the
switch is made, then are they functional in Tomcat?
- If not, can the same application be deployed in Tomcat such that
it doesn't affect the Jetty application if the switch is reversed at
some time in the future?
- Finally, how are applications that must be "pre-deployed" in each
container managed (for example example the web console)?
Joe
David Blevins wrote:
LAST ISSUES
- Easy switching from Jetty -> Tomcat
- Snapshots (Javamail & Axis=>Dims, jUDDI & Scout=>Geir,
ServiceMix=>Hiram, tmpOrb=>Dain)
- Version number of some sort in the schemas?
Is there anything else people think *must* be there to ship?
THE FINAL STUFF
Again, we have to run the TCK on the final binary. It would be
great if we could cut the final release by Wednesday and be
finished TCK testing by Friday. To get there we will have the
standard checklist of stuff to do:
1. clean the jira
2. create release notes
3. update readme files
4. Change the version number in etc/project.properties and the
plugins
5. Create our tag
6. Cut and sign the binary and source distributions
Then it's just test and vote, both take two days and can be done
at the same time.
Any details I've missed?
-David
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
