[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by adrian@jboss.org
"scott.stark(a)jboss.org" wrote :
| Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.
|
But to answer your question (in brief), the Deployment(Context)
is structurally analyzed (I assume no predetermined managed objects)
into its javaee components which determines the metadata location.
This metadata location identifes a list of configuration files
-security.xml, -logging.xml (besides the javaee files).
These are matched to the deployer chains.
e.g. The -security.xml might create an application policy that is
added to the metadata repository
Input=-security.xml
Output=real
When=some ordering after the metadata repository context is constructed
e.g. A log4j.xml might create a scoped (based on classloader)
logging configuration
Input=log4j.xml
Output=real
When=some ordering after the classloader
The chains are more important when you have flows like the
rar deployer:
ra.xml -> rar metadata -> servicemetadata -> mbean
rar parser -> rar deployer -> servicedeployer -> real
The reason to split the rar parser from the rar deployer is
that:
1) The rar parser is not required for predetermined metadata
2) Some other parser/deployer earlier in the list can construct
the rar metadata for deployment from some other mechanism
and use the later rar deployer to do the real work
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972638#3972638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972638
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by adrian@jboss.org
"scott.stark(a)jboss.org" wrote :
| Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.
|
Ignore the deployment context. That is just the current iteration's
version of the DeploymentInfo. Basically a big horrible
map of metadata and state about the deployment.
What we are really dealing with is:
* managed objects - either predetermined using our metadata formats
or the unparsed xml and annotations
* structure - where to look for unparsed metadata and what makes up
the classpath
* transient state - used during the deployment
In the full solution, the management component of the profile
service should be able to say something like:
"change the pool size of this datasource"
and it is the MainDeployer's job to say (based on the meta annotations),
I can do that (with the help of the relevant deployer)
without going through a redeploy.
It can't do that with the current MainDeployer api and DeploymentContext.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972634#3972634
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972634
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by adrian@jboss.org
"scott.stark(a)jboss.org" wrote : First, I'm not in agreement that hot deployment of deployers is needed. The only post bootstrap configuration I can see are aspects on the deployers themselves, but this can be a function of an individual deployment, not neccessarily a reconfiguration of the deployer.
|
I'm not sure I understand this.
What we are talking about will end up in the full solution as
a profile that looks like:
* kernel/profile/bootstrap
This will be semi-hardwired and represents a minimal set
of features to get the thing working (not what we have now).
* core configuration
These will be plugins, to the above, that need to be done early.
Of course ideally we want as much as possible to be done
through deployers.
Thing that fall into this category:
aop-mc-int
profile plugins, e.g. JBoss ON integration
legacy jmx kernel
core logging (user configurable like conf/log4j.xml)
* deployers
A set of deployer packages that plugin to the main deployer/profile.
* the deployments
A fixed list, scanner based, something else or a mixture.
So basically, I don't believe the MainDeployer/deployers
should be a part of the bootstrap configuration and that
there will be some form of "hotdeployment" even if it
is the initial step that creates a fixed list
before the real deployments are done.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972628#3972628
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972628
19 years, 6 months
[Design of POJO Server] - Re: Deployers and classloading - stumbling block
by adrian@jboss.org
That's fine as long as the deployers are playing by the rules
and are self-contained or semi-self-contained (only reference
other deployers metadata).
If they reference the runtime then you are going to leak
everything into the bootstrap classloaders.
Once one gets in there, the rest will follow like dominos.
The ideal should be to have two packages:
1) That is the deployer and its metadata, e.g. the WebDeployer
2) That is the runtime implementation e.g. web deployment and server
i.e. The deployer parses the metadata and creates a
ServiceMetaData or BeanMetaData with only string references
to the runtime classes
In practice, our implementations are a long way from this currently.
Having something that is closer to JBoss4 as an incremental step
is probably going to help us get things done faster?
I think some form of hotdeployment of deployers is going to
be done at some stage anyway.
e.g. to support people playing with profiles where the results
are more dynamic than a full reboot. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972618#3972618
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972618
19 years, 6 months