Aaron Mulder wrote:
On Sun, 25 Jan 2004, Jeremy Boynes wrote:
A couple of things in the JSR 88 API don't make sense to me - if anyone has definitive answers I would appreciate it.
On distribute(), what exactly is the "deploymentPlan" passed in? I am assuming that it is the tool's responsibility to pass in a File/InputStream containing the information written by DeploymentConfiguraton.save(OutputStream).
It is all the server-specific deployment information. What traditionally goes in the server DDs. But not all servers use DDs, so XML is not mandated here. It can be binary info or XML or whatever.
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.
This seems broken: * during configuration, the tool supplies multiple distinct OutputStreams and the plugin has no knowledge of where the data gets written * during distribute, the tool can only supply one InputStream and the plugin has no idea where to get the remaining data from. If the tool merges the multiple streams together, the plugin does not know how they were merged
And this is just for a single module - more on EAR's below.
If this is the case, how is the information for an EAR module tied together?
As I understand EAR deployment: * the tool constructs a J2eeApplicationObject from the EAR's DD * the tool invokes DeploymentManager.createConfiguration() to construct the DeploymentConfiguration for the EAR * for each DeployableObject (sub-module) in the EAR, the tool calls DeploymentConfiguration.getDConfigBeanRoot(DDBeanRoot) to get the DConfigBeanRoot that it uses to configure the sub-module
Yes.
At this point things get fuzzy. Presumably the tool iterates over all these DConfigBeanRoot's and uses saveDConfigBean(OutputStream, DConfigBeanRoot) to save the configuration information. However, the tool gets to choose the location where the information is written (as it creates the OutputStream).
Now when the tool goes to distribute this application, it would pass the plugin the File/InputStream for the EAR and the File/InputStream for the EAR's deployment plan. How does it communicate to the plugin the location of the DD's for all the sub-modules?
The tool would call DeploymentConfiguration.save() [with no
argument] which would save all the deployment information for the EAR to
one file. That would be used as the Deployment Plan. Likewise, it could
reload that with restore (no argument).
It may be that the server plugin uses different formats for saveing a single DConfigBeanRoot vs an EAR -- perhaps the save(DConfigBeanRoot) saves a single XML DD, and the save() saves a serialized Map relating modules to DDs, or a grand unified XML with children for each DD/module pair, or whatever.
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() :-(
-- Jeremy
