On Mon, 26 Jan 2004, Jeremy Boynes wrote:
Sorry if I'm being dense, but how does the tool merge together all the server specific information? For example, there could be several files generated by different calls to save(OutputStream) and save(OutputStream, DConfigBeanRoot) for the different files in the module (I think the example is the primary DD and those associated with web services).
However, when the tool goes to distribute this module it only gets to pass in one file.
The tool cannot call save on individual DConfigBeans and then merge the save files. It must call the save that takes no arguments if its going to deploy an EAR. That method saves all the deployment info for the EAR to one file. The individual save(DConfigBean)s could be used for deploying only one module, or for the user to save their progress on individual modules separately. OK, it's not terribly useful.
So for 88 to be useful, the vendor must support having all their DD information in one file? But the RI does not that...
So the spec forces the vendor's to save all configuration for an EAR in one file, just like the old RI did? Does it not allow tools to use per-module DD's like BEA, JBoss, and yes SunOne/the new RI?
Hmm, that may be why the new RI does not appear to support the configuration part of the spec - it returns null from getDConfigBeanRoot() :-(
The server can store the data in whatever format it wants on its
side of the network. Some products use XML (ok, most), some use a
database, some used serialized thingys, etc. But the server has to
transfer the data over the network as a single stream. Is this such a big
deal? How about a serialized map where the key is some combination of
module name and/or DD name and the value is the XML DD? If not, how about
just writing a bunch of DDs in a row to the stream? If not, how about one
big DD that holds all the little DDs? There are plenty of ways to implement this. In the long run, all the data is going over one network stream anyway; it's just a question of at what stage it gets combined. :)
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 only ones I can think of that are different are the old (deprecated) RI and maybe WebSphere with it's separate repository.
-- Jeremy
