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
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 <[EMAIL PROTECTED]> * Associate * Core Developers Network LLC * http://www.coredevelopers.net ****************************************/
