geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <...@coredevelopers.net>
Subject [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo components
Date Sun, 24 Aug 2003 02:50:02 GMT
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 <jan@coredevelopers.net>
  * Associate
  * Core Developers Network LLC
  * http://www.coredevelopers.net
  ****************************************/


Mime
View raw message