On Mon, 26 Jan 2004, Dain Sundstrom wrote:
> > Now you are being dense. You have to be able to transport it over
> > the network in one stream. Is that so onerous?
>
> I disagree. We write the provider layer and we may send the
> information to the server in several disconnected streams. The tool
> frankly has no idea what we are doing with the stream. We can do
> everything you mention below in the provider layer on the client side,
> which means we don't have to be able to transport it in one stream.
You're right, my language was misleading. I should perhaps have
said, "according to the spec, you must hand the deployment plan from the
tool to the server plugin in one stream. Is that so onerous?"
> So the common developer suffers from some person sitting in a ivory
> tower? What I see as the major flaw is you now have tool locking.
> Once you configure an application with tool X you can not convert to
> tool Y without starting over. Heck you can't even configure an ejb-jar
> standalone (for say isolated testing) and then move that configuration
> into an ear; you get to start over. For production environments, you
> can't build a configuration try it in a staged environment and them
> move the file over the the production environment. No you must be
> on-line. Now all the above is possible with a perfect tool, but then
> you have tool lock-in.
I don't see any tool locking going on. The tool can ask the
server to save deployment information to a file or load it from a file.
The only tool-specific part of this operation is choosing a file name.
Persumably we can rely on all tools to include a file chooser.
As far as configuring an EJB JAR and later incorporating it (with
its deployment information) into the EAR, it's easy:
- user configures JAR deployment info
- user hits "save", picks file name, info saved to file
- user hits "deploy", EJB JAR & deployment info sent to server
- user tests EJB JAR (likely outside scope of tool)
- user hits "open", picks EAR file, new EAR loaded, previous DD gone
- user selects node for EJB JAR in EAR tree
- user select "load", picks file name (file saved above)
- DConfigBeans for EJB JAR are populated from saved file
- user repeats for any other modules with pre-saved deployment info
- user manually populates DConfigBeans for any additional modules
- user hits "deploy", EAR and all deployment info send to server
- (optional: user hits "save", all deployment info saved to 1 file)
> 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!"
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?
Aaron
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. :)
