You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jan Bartel <ja...@coredevelopers.net> on 2003/08/24 04:50:02 UTC
[web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo
components
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 <ja...@coredevelopers.net>
* Associate
* Core Developers Network LLC
* http://www.coredevelopers.net
****************************************/
Re: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo
components
Posted by Jan Bartel <ja...@mortbay.com>.
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
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 ....
>
>
>
>
>
Re: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo
components
Posted by Jan Bartel <ja...@coredevelopers.net>.
Jeremy
It seems like the app client container is 1 : 1 with an application
instance. This is also similar to the situation with the ejb container,
where whilst the container may have a number of beans within it, all
beans are of the same type. In both of these cases, setters on the
container for configuration make sense. This isn't the case with the web
container - it will contain many different web applications, each with
different config. Setters on an individual webapp to pass in the
contents of the web.xml could make sense, but this would be a little
awkward as the web app must provide the xml of it's deployment
descriptor as a String to satisfy JSR77 - the webapp would have to
reconstruct it from the data from the setters. Plus, as the concrete
containers all want to access the web.xml file anway, I'm starting to
think it would just be easier (for now) to assume the web container only
requires to be passed the URI of a webapp to deploy, and possibly a
context path derived from an application.xml file if the webapp is part
of an ear.
Jan
> I don't know enough about the internals of the web container, so if you
> can bear with me I'll go through how I envisage the AppClient container
> working (as that is the simplest one). Hopefully it translates.
>
> The AppClient container hosts a thick client application providing it
> with J2EE resources:
> * J2EE Environment accessed via JNDI in java:comp
> * Security (login mechanism, propagation to invoked EJBs, URLs and
> resources)
> * Transactions (optional, but I want to make UserTransaction available)
>
> I see these as being attributes of the AppClientContainer itself -
> currently there are JMX Attributes for:
> * The URL of the client jar, so it can construct a ClassLoader
> * The name of the Class with main, so it can construct the invoker
> * (uncommitted) The Context that will be bound to JNDI java:comp by the
> interceptor
>
> It is designed so that (when it is STOPPED) the container MBean can be
> persisted and reloaded later (once Dain gets ModelMBean persistence
> going).
>
> With this model, the AppClientContainer does not need to know about XML,
> about DDBean and DConfigBeans, even anything about the deployment
> process. This keeps it lean - the last thing we need is 20MB of overhead
> just to run HelloWorld. [Resource usage is important for thick client
> apps especially in multi-user configurations e.g. LTSP or Citrix. ]
>
> The deployment tool is responsible for generating this MBean
> configuration from the XML DDs and user input by the Deployer. This
> could happen in several ways:
> * a adminstrator runs a GUI deployment tool for a specific client jar
> * a platform installer configures the app during the installation
> process
> * the app client launcher reads the XML DDs during startup
> However it happens, it is a totally distinct phase from
> creating/starting the runtime container.
>
> So there are three things participating here:
> * the deployment tool, which has its own mechanism for converting XML
> DDs to DDBeans
> and communicates with the deployment provider using DDBeans and
> DConfigBeans
> * the deployment provider, which deals with DDBeans and DConfigBeans and
> the persistent
> form of the geronimo config (in XML or whatever). This converts the
> configured deployment
> into MBean attributes for the container
> * the container, which uses its MBean attributes to run and knows
> nothing of DDBeans,
> DConfigBeans, XML DDs or other editable configuration data.
>
>
> --
> Jeremy
--
/****************************************
* Jan Bartel <ja...@coredevelopers.net>
* Associate
* Core Developers Network LLC
* http://www.coredevelopers.net
****************************************/
RE: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo components
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> From: Jan Bartel [mailto:jan@coredevelopers.net]
> 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.
>
I don't know enough about the internals of the web container, so if you
can bear with me I'll go through how I envisage the AppClient container
working (as that is the simplest one). Hopefully it translates.
The AppClient container hosts a thick client application providing it
with J2EE resources:
* J2EE Environment accessed via JNDI in java:comp
* Security (login mechanism, propagation to invoked EJBs, URLs and
resources)
* Transactions (optional, but I want to make UserTransaction available)
I see these as being attributes of the AppClientContainer itself -
currently there are JMX Attributes for:
* The URL of the client jar, so it can construct a ClassLoader
* The name of the Class with main, so it can construct the invoker
* (uncommitted) The Context that will be bound to JNDI java:comp by the
interceptor
It is designed so that (when it is STOPPED) the container MBean can be
persisted and reloaded later (once Dain gets ModelMBean persistence
going).
With this model, the AppClientContainer does not need to know about XML,
about DDBean and DConfigBeans, even anything about the deployment
process. This keeps it lean - the last thing we need is 20MB of overhead
just to run HelloWorld. [Resource usage is important for thick client
apps especially in multi-user configurations e.g. LTSP or Citrix. ]
The deployment tool is responsible for generating this MBean
configuration from the XML DDs and user input by the Deployer. This
could happen in several ways:
* a adminstrator runs a GUI deployment tool for a specific client jar
* a platform installer configures the app during the installation
process
* the app client launcher reads the XML DDs during startup
However it happens, it is a totally distinct phase from
creating/starting the runtime container.
So there are three things participating here:
* the deployment tool, which has its own mechanism for converting XML
DDs to DDBeans
and communicates with the deployment provider using DDBeans and
DConfigBeans
* the deployment provider, which deals with DDBeans and DConfigBeans and
the persistent
form of the geronimo config (in XML or whatever). This converts the
configured deployment
into MBean attributes for the container
* the container, which uses its MBean attributes to run and knows
nothing of DDBeans,
DConfigBeans, XML DDs or other editable configuration data.
--
Jeremy
Re: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo
components
Posted by Jan Bartel <ja...@coredevelopers.net>.
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
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 <ja...@coredevelopers.net>
* Associate
* Core Developers Network LLC
* http://www.coredevelopers.net
****************************************/