What I will probably get committed into head by the time you read this
and then plan to port to M5 is:
in assembly, we will deploy the applications (console, welcome, and
juddi-server) onto both jetty and tomcat (6 configurations) (I'm going
to not deploy demo and debug console at all).
There are 3 sets of config.* files in var/config: one like we have now,
that starts both jetty and tomcat on different ports, and two new ones
that start only jetty or only tomcat (with the associated deployed
apps)
Standard behavior for any deployed web app configuration is that it
will start the web container it is deployed onto if the container is
not already started.
To switch web container, you can copy one of
config.[jetty|tomcat|both].xml(list) onto config.xml(list).
Furthermore I've implemented namespace-driven builder selection with
new jetty and tomcat specific plan schema namespaces.
thanks
david jencks
On Sep 27, 2005, at 6:42 AM, Joe Bohn wrote:
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
