On Jan 26, 2004, at 2:35 PM, Aaron Mulder wrote:
On Mon, 26 Jan 2004, Dain Sundstrom wrote:But they were willing to be restricted to one monolithic file for the
entire ear? I am surprised. Unless they all plan on doing what the RI
does, which is return null.
If I may be so bold as to paraphrase, "I don't like your stupid spec, so I won't implement it! Phooey on you!"
It appears that is exactly what the RI has done, and this is a fairly common practice with specifications. I've seen things like "we implement JAAS, but you can plug the login modules", which is completely useless.
Imagine the alternative. The user spends 10 minutes configuring
all the deployment information for the 20 modules in the EAR. They hit
"save". The tool then opens 20 dialog boxes, one per module, so they can
save the deployment info for every module into a separate file. It takes
longer to navigate the save dialogs than to perform the actual
configuration. This is better?
I would prefer the tool ask the provider for the desired location for the streams to be stored, which would also allow the provider to have the file name end with .xml, and allow the configurations to be seamlessly portable between tools.
P.S. Jeremy and I talked by phone and worked though our differences on
this as well as the thread about deployment info being the responsibility
of the different Web/EJB/etc. implementation. His summary essay will be
forthcoming, though perhaps not rapidly. :)
I'll chat with Jeremy later. I really want to see this spec work, which means the vendors need to actually try to support this (and not take the easy out), and the end users need to find the tools useable. I'm concerned that the non-vendor supplied tools will be clunky, so people will only use vendor tools. I hope it works out, but I'm currently fairly pessimistic. Anyway, I am confident this will work for us as we are the vendor and can supply our own tools.
-dain
