geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Geronimo Deployment Descriptors
Date Tue, 09 Sep 2003 12:26:29 GMT
On Tuesday, Sep 9, 2003, at 13:23 Europe/London, Alan Cabrera wrote:

>> -----Original Message-----
>> From: Jeremy Boynes []
>> 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 

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.


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.

View raw message