On Tuesday, Sep 9, 2003, at 13:23 Europe/London, Alan Cabrera wrote:
-----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
I believe that the Deployment Descriptors are the standardized input to the Configuration process. The specification does not define what a platform's configuration data looks like, allowing solutions such as WebLogic's where is it stored in the archive as XML files, or solutions such as WebSphere's where it is stored in a configuration repository.
There is a difference though between what WebSphere's data looks like between developer tool and deployer, and what it looks like when it's in the actual environment, though.
WebSphere Studio App Dev generate XML files for storing the mapping and places them in the EJB-JAR/WAR/EAR files. These are then read during deployment (configuration?) and then uploaded into the central repository (for AE) or XML file (for AEs).
There is no requirement for the platform to read the deployment descriptor itself at runtime; a platform may choose to do so (especially if that is the sole location for configuration information, e.g. BEA or JBoss) but it is not required.
True, but this is for apps that have already been run through the configuration process. For unconfigured apps, you'd still have to go through the same process of configuration to generate such information.
This allows us, if we wish, to pre-compile the configuration information into other forms. For example, it could be an archive of serialized MBean states that can simply be unmarshalled by the server and started. This has many potential advantages, such as reducing the startup time for very large applications or reducing the resources required for an embedded server.
This is obviously a compelling scenario. I'm sold.
I agree that it is a useful thing to do, but is the configuration information needed in an EAR file at all? Since the configuration information will be part of the application within Geronimo, isn't it unlikely that an EAR-with-Geronimo-info will ever be exported outside of a Geronimo environment? In fact, since the same argument of 'the spec doesn't force us to use any kind of configuration', I think the same is also true of the deployable code as well; we may not even need to store it as an EAR file, which would probably avoid most of the problems.
There are also issues to consider with updating as well; what happens if an EAR file is updated? Can we guarantee that the configuration will also get updated? In which case, shouldn't the xml file take precedence?
I see a potential problem (perhaps it's not, though -- I'm happy to be proved wrong :-) where an administrator takes an EAR, configures it (generating said geronimo-specific-configuration), and then deploys it into Geronimo. Later, the developer finds a bug, sends it to the Administrator, who then redeploys it. What happens to the configuration information? Does it need to be regenerated?
Lastly, from experience with VisualAge and EJBs of long ago; the problem with pre-generating code is that any bugs you've got in the generation process are immediately frozen the minute you generate the configuration code (like the MBeans). Thus, it was necessary several times throughout one VAJ/WAS project to repeatedly re-generate every configuration file when upgrading from 3.0 to 3.0.1, because the bugs they'd fixed were in the generation process. It didn't matter that the server was updated, nor the development client, because all the generated code was based on the original 3.0 codebase, and thus was a potential source of problems.
That's why IBM switched to using XML files and regenerating in WebSphere. That way, the information is information, and the deployment always uses the most up-to-date mechanism to generate deployed code.
So, please let's not use code to represent configuration. Use configuration files and generate when required.
Alex.
PS Doesn't mean that it's not a bad idea for the server to cache pre-generated code between server runs, though -- it's just not something that a client should ever do.
