I would like to create a front end for this process in the web console. I was thinking about it last night (before I read this morning's encouraging posts). Richard Monson-Haefel wrote about it a while back--easing the process of deployment by removing the need for people to work directly with the deployment descriptors. His suggestions fall perfectly in line with what Jeremy's written here.
I think making the deployment data persist is a great idea. It could also allow multiple deployment profiles for each application (higher / lower security, etc). -- N. Alex Rupp ([EMAIL PROTECTED]) ----- Original Message ----- From: "Alex Blewitt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 09, 2003 7:26 AM Subject: Re: Geronimo Deployment Descriptors > 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. > >
