geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo components
Date Sun, 24 Aug 2003 07:17:45 GMT
I've had a bit more of a look at the JSR88 spec. I'm not convinced that 
these DConfigBeans and DDBeans are the entities that the geronimo 
deployer should be passing around to eg the web container.

Whilst the JSR88 beans are nice in that they provide a tree modelling of 
the contents of deployment descriptors, they are designed specifically 
to allow a 3rd party deployment tool to interoperate with a J2ee 
platform provider. Therefore they necessarily provide a lot of 
functionality (property change listeners, xpath listeners etc) that just 
isn't needed by the platform's internal deployment process. Moreover, 
they provide methods that should not be exposed outside of the tool 
environment - eg DConfigBean.removeDConfigBean().

Shouldn't the internal deployment process really just expose some 
*immutable* bean trees representing the standard and geronimo specific 
deployment descriptors and pass these to the targets of the deployment 
eg the web container?  The deployment target (eg web container) then 
executes xpath expressions on each descriptor tree in order to extract 
the configuration information.


Jan Bartel wrote:
> Jeremy Boynes wrote:
>> I would say - neither!
>> The JSR88 deployer will have mechanisms for converting the XML to 
>> DDBean and
>> DConfigBean trees. I would suggest these are exposed rather than the 
>> XML in
>> either form.
>> This allows the deployer to store the config in any form - we have 
>> already
>> talked about storing config in an external, not-necessarily XML 
>> repository
>> such as RDBMS or JNDI. It also matches the future direction of 
>> replacing XML
>> DDs with J2SE metadata.
> Let me explain the background to my question re exporting Documents. All 
> existing web containers like Jetty and Tomcat expect to crack open a URI 
> and extract a web.xml file from WEB-INF, parse it into some dom 
> structure and go ahead with the configuration. To make matters worse, 
> Jasper too wants to crack open the web.xml file and also parse it into a 
> dom. In JBoss, the AbstractWebContainer also parses the web.xml as well, 
> making a total of 3 dom-ifications of the same descriptor!
> To try and decrease this re-parsing, I was proposing parse the 
> descriptor to a dom in the AbstractWebApplication as part of the 
> deployment step, and then expose it to container. It would be easy to 
> modify Jetty to accept a dom and quite reasonable to have Jasper and 
> Tomcat modified the same way.
> However, if the deployer is going to parse the descriptor into JSR88 
> beans then there seems little point in trying to optimise the re-parsing 
> by introducing another re-parse. So, for now, I will expect the various 
> container impls to continue to do their own parsing of web.xml.
> In order to make progress on geronimo's web container infrastructure, I 
> need to clarify what will be the nature of the interface to the 
> deployer. Firstly, will the deployer be creating JSR88 beans for 
> deployments via both JSR88 compliant tools and for deployment by 
> dropping the ear/war etc into a watched deployment directory?
> Secondly, what JSR88 beans will be passed on deployment?
> There are 2 cases:
> 1) the webapp is a standalone unit
>    This translates to a JSR88 DeployableObject with a
>    DConfigBeanRoot for the geronimo-web.xml and DDBeanRoot for web.xml
> 2) the webapp is part of an ear
>     The webapp is still a DeployableObject, but it needs the context
>     for the webapp from the application.xml descriptor of the parent
>     J2eeApplicationObject.
> The interface could potentially be:
> 1)
>  deploy (DeployableObject, /* URI of webapp etc */)
>    or
>  deploy (DDBeanRoot,      //equiv to web.xml
>          DConfigBeanRoot, //equiv to geronimo-web.xml
>          /* URI of webapp etc */)
>    or
>     ???
> 2)
>     deploy (DeployableObject, /*URI of webapp etc */, String context);
>     or
>     deploy (DDBeanRoot,      //equiv to web.xml
>             DConfigBeanRoot, //equiv to geronimo-web.xml
>             DDBeanRoot,      // equiv to application.xml
>             /*URI of webapp etc*/)
>     or
>      ????
> Jan
>>> Some of the web container components would like to expose a parsed XML
>>> Document in their methods.  Do we have any policy on whether any such
>>> exposed Documents from the core infrastructure should be w3c only, or
>>> would we allow a dom4j Document to be exposed?  The w3c interfaces
>>> guarantee interoperability but they are such a pain to work with ....


  * Jan Bartel <>
  * Associate
  * Core Developers Network LLC

View raw message