geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Clarification on 88 anyone?
Date Mon, 26 Jan 2004 16:01:54 GMT
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 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.  :)


View raw message