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 02:54:21 GMT
To followup on my own email, are any JSR88 beans for the web.xml 
descriptor available, and if not, then I volunteer to code them.


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 ....

View raw message