I'm afraid I have to object to the decision to move all the server
deployment information to become the responsibility of individual modules. I think it will be a bug not a feature if the web deployment information
and format is different depending on whether you're using Tomcat or Jetty,
and likewise what you'd use for EJBs, JMS, J2CA, etc. It would be
impossible to write a book or manual if the DD format was different for
every combination of plugins. I think we need to standardize on one set
of deployment information for every module. Perhaps the advanced user could pass in a few extra EJB CMP properties somehow, but I think our full functionality needs to be available via the same DD formats, regardless of what you have plugged in.
Aaron
That's the thing - 'full functionality' is defined by which plugins you are using in the configuration.
If we restrict what the plugins can do, then the 'full functionality' is the lowest common denominator of all of them. By allowing the plugins to expose what they do, each combination can have it's true full functionality.
We get the standardization through the use of common sub-schemas. So Jetty and Tomcat can both say "hey this does everything we want" and not offer any extensions. Resin on the other hand can go "that's nice but here is all the other stuff that people expect from Resin"
In the end the user gets to choose. If they do not use plugin extensions then they can build a deployment that works with any compatible plugin (one that uses the Geronimo sub-schemas); if they want to use the full capabilities of a server then they can.
This is perhaps less of an issue for webapps as there is generally little information in the vendor DD; this is a big issue for other module types where there is a lot of information in the vendor DD.
Putting it another way, we are introducing a standard mechanism for supplying those "extra EJB CMP properties" rather than having each plugin do it its own way.
-- Jeremy
