Peter Royal wrote:
My only concern is the added use of System.setProperties().. In what circumstances would that be needed? Can it be safely removed?
Yes, I used that to play with system properties that Jetty looks for (jetty.home). I agree that it can be evil to have a possibility to set system properties in a conf file. If we want to use Jetty's configuration without changes I think jetty.home must be set, but that can be done with only one hard coded property.
Anyway, before applying those patches there are some things to address.
1) The jetty block is now very close to a normal Jetty distribution, it mounts jetty's (minimal) root app under /, has a webapps directory for auto publishing web applications and it includes all jars.
-There are probably licensing issues with all those jars. They couldn't be included in a dist could they?
-Should we try to make the container blocks look like standard dists of the servlet container in question? Would a clean structure with no demo apps be better? Personally I think so, a configuration that mounts a webapps directory with a directory "root" within should do. A really simple index.html in the "root" dir would be all.
2) The sevak demo was moved to /sevak, but only for the jetty block.
-If the demo is wanted in a distribution this update should be done for the catalina and jo blocks too, or undone for jetty. As I said I would only want a clean dist with no demos or anything. Perhaps a build task jetty-demo, jo-demo... would do?
3) There are some tabs in the patches.
For some reason there seems to be some tabs in the patches. These must be removed. I hate tabs and for some reason they show up in my own patches, UGH :(
4) It would be nice to have a real block that publishes webapps to a sevak handled container.
-Now we only have the demos, showing how to create a block that deploys a webapp to sevak. As this is a very common use case (the most important I guess), a block taking web contexts and their local file url in its configuration would be great. It would be easy to make too. Perhaps it could be extended to take a webapps type of directory and deploy all applications in it to sevak.
5) ....
// Johan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
