On Jan 26, 2004, at 12:32 PM, Aaron Mulder wrote:
On Mon, 26 Jan 2004, Jeremy Boynes wrote:So for 88 to be useful, the vendor must support having all their DD information in one file? But the RI does not that...
Now you are being dense. You have to be able to transport it over the network in one stream.
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.
Is that so onerous? Whatever format you use
for that, you would probably also use for your save files. The
information does not need to permanently live in one file on the server
side. You can split it out into one file per byte once it gets to the
server side. Or stuff in in a database. Or update the EAR to contain it.
Or whatever.
Hmmm. Most vendors have implemented a mechanism where the DD information
for a module is in that module as one or more XML files in META-INF; and
for EARs, the top level file describes the EAR itself, the module level
files are in each nested module archive's META-INF.
The J2EE spec team wanted to explicitly discourage developers from
putting deployment information into the EAR. Why that is, I couldn't say.
Thus, we have all this plumbing so the server can automagically handle the
deployment information without the user even needing to manually generate,
copy, or package it.
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.
Of course for us, this is not a huge problem, because we will write the tool. And we can just tell everyone to use our tool, but I doubt that was the goal of the spec.
The only ones I can think of that are different are the old (deprecated)
RI and maybe WebSphere with it's separate repository.
Well, one counter-case is enough. The vendors didn't want to be
restricted to a particular format for deployment information, even one as
common as XML. So it's a file/stream, with which you can do what you
will.
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.
-dain
