On 08/21/2010 07:23 AM, Tom Marble wrote: > On 08/21/2010 12:19 AM, Torsten Werner wrote: >> BTW I do not like your 3rd option at all. It sounds unsupportable in >> the long run and the local admin has to learn a new tool which is only >> used in Debian and only for Tomcat based apps. We should either use >> some existing solution or something generic one or something that is >> fully automatic and easy to support. > > I believe we ought to consider this as just one case of a likely > larger set of use cases of deploying web applications into web > containers. Clearly there more containers than just Tomcat > (and one of reasons few of them are in the archive relate to the > problems Russ has pointed out). It would be nice if we had > a tool that takes a configuration input and generates the > artifacts for Tomcat, Glassfish, or other containers. > > Having Debian unique tools which improve deployment hygiene, > are automated and solve a class of Policy problems seems to > be an advantage, not a disadvantage. For example look at how > the alternatives system solves a problem (and was later emulated > by others). Java administration won't be the same on all > platforms because system administration isn't the same > on all platforms. Windows Java users don't share our values > and simply don't care about hygiene. > > It sounds to me like a fully automatic, easy to support, > Debian specific tool -- a Java web application configuration > processor -- that simplifies configuration and deployment for many > potential containers would be a nice solution.
I'm not disagreeing per se, but would like to bring up a few points. Having best-in-class tools that are unique to Debian (or originate in Debian and gain wider acceptance) is definitely a plus. In this specific case I find myself thinking about someone operating servlet containers in a production environment, where much of their time must be spent focusing on business needs and they might not have a lot of time to come up to speed on newer toolsets. (Or, even if they do, they are (a), risk-adverse because it's a production environment, or (b) prevented from adopting new tools/procedures by colleagues who have different ideas.) All that is to say, I support something that is easy and intuitive for the sysadmin who is the user of this system. So the idea that come to mind is as follows. JARs, WARs, and EARs are familiar, (mostly) well-understood, and trusted by those who administer these sorts of systems, and most (all?) containers are designed to use them. Many containers also have developed sophisticated tools to manage and distribute them. (And often these are the tools familiar to the users.) Therefore, if we had a system that allowed the end-user to update the templated portions of the system and then built a JAR/WAR/EAR for them to consume, that would be idea. So webapp packages would be akin to the suite of packages that depend on module-assistant (IMO a great example of how to solve a sticky problem), where the user would retrieve the webapp-(appname)-source package, make changes as desired, and then assemble it. The default source package should work "out of the box" to produce a completely uncustomized version of the webapp. Here is where I'm not so certain about the best path forward, but providing a generic way to link local customizations to a VCS or something like that would be a big win. The issue is that is that we don't know a priori what sort of customizations each webapp will need. But in summary, I'm suggesting we consider a system that supports customization for those who want to invest the time, but retains the artifacts familiar to folks who work daily in the J2EE/servlet container space. Cheers, tony
signature.asc
Description: OpenPGP digital signature
