[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer
by adrian@jboss.org
No, you don't create the components yourself.
You leave that to the component deployer.
The key part is that the attachment doesn't have to be named ServiceMetaData.class.getName(). Most people call it that,
but that's just a convention.
(It's always called that at the component level though).
The component deployer looks for any attachment that implements the
type, it's doesn't care what it is called and creates a component for it.
JMX component deployer
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/m...
Helper
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine...
| protected void deployComponents(DeploymentUnit unit) throws DeploymentException
| {
| if (compVisitor == null)
| return;
|
| Set<? extends C> components = unit.getAllMetaData(getOutput());
| for (C component : components)
| compVisitor.deploy(unit, component);
| }
|
And because it uses a visitor pattern, it knows how to unwind errors.
Your version suffers from the usual, "I'm not going to bother to tidyup
if I get an error part way through" bug. Which is just going to lead to
"InstanceAlreadyExists" errors in the MBeanServer when you try to redeploy.
>From a brief look at the code you posted,
it breaks the following basic design princples of the deployers
1) It sidesteps the deployer chain with one deployer calling another directly
2) Since the metadata is deleted it won't be available to the management tool
3) It doesn't create components for the individual services, so there's no
way the IncompleteDeploymentException to know which MBeans are part of
the deployment and give a reasonable error message.
Finally, there already is a ServiceMetaDataSet, its called a ServiceDeployment
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/m...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131393#4131393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131393
18 years, 1 month
[Deployers on JBoss (Deployers/JBoss)] - Deploying multiple service through the ServiceDeployer
by thomas.diesler@jboss.com
Folks,
I have/had an issue with a deployment wanting to create multiple services
1) EJBDeployer attaches ServiceMetaData
2) WebServiceDeployer generates and attaches JBossWebMetaData
3) TomcatDeployer also attaches ServiceMetaData
my proposed fix is
| // In case there already is a ServiceMetaData object attached, we use a set
| ServiceMetaData prevService = unit.getAttachment(ServiceMetaData.class);
| if (prevService != null)
| {
| ServiceMetaDataSet services = new ServiceMetaDataSet();
| services.add(prevService);
| services.add(webModule);
| unit.addAttachment(ServiceMetaDataSet.class, services);
| unit.removeAttachment(ServiceMetaData.class);
| }
| else
| {
| unit.addAttachment(ServiceMetaData.class, webModule);
| }
|
and a new deployer
| public class MultipleServicesDeployer extends AbstractSimpleRealDeployer<ServiceMetaDataSet>
| {
| private ServiceDeployer serviceDeployer;
|
| public MultipleServicesDeployer()
| {
| super(ServiceMetaDataSet.class);
| }
|
| public void setServiceDeployer(ServiceDeployer serviceDeployer)
| {
| this.serviceDeployer = serviceDeployer;
| }
|
| @Override
| public void deploy(DeploymentUnit unit, ServiceMetaDataSet deployment) throws DeploymentException
| {
| Iterator<ServiceMetaData> it = deployment.iterator();
| while (it.hasNext())
| {
| ServiceMetaData service = it.next();
| unit.addAttachment(ServiceMetaData.class, service);
| try
| {
| serviceDeployer.deploy(unit, service);
| }
| finally
| {
| unit.removeAttachment(ServiceMetaData.class);
| }
| }
| }
| ...
|
| |
| | Please review.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131387#4131387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131387
18 years, 1 month
[Design the new POJO MicroContainer] - ClassLoader for a subdeployment
by adrian@jboss.org
One of the things left to do is the managed classloader for a subdeployment.
This is so we can use the new classloader framework for the war classloader
which would include having OSGi style imports for the isolated wars.
The way I'm planning to do it, is that if a subdeployment has a ClassLoadingMetaData
then it will trigger this processing.
The subdeployment will become a classloading "Module" in its right,
capable of importing dependencies that are different to the main classloader
of the deployment.
Also, its ClassPath will NOT be included in the main classloader classpath.
For the war classloader I expect this to be triggered by a specific deployer
that decides that wars should get their own classloader
and what the default policy should be, e.g. excluded classes, parent first, etc.
The are some gotchas:
OLD LOADER REPOSITORY CONFIG
Previously we only checked for subdeployment classloader config
for a war (and then only if the useJBossClassloade was configured).
e.g. a loader repository config in a jboss.xml of a nested ejb jar
would be ignored.
With this new feature, it wouldn't be ignored anymore and
the nested ejb would get its own subclassloader.
We can probably fix this in the "hack" that ignores it for non-wars
or at least add a warning?
PARENTS
There are two ways to implement it, both have issues.
1) Just create a classloader with the main deployment classloader as the parent.
This may run into the circularity issue in the Sun Classloader,
although, I haven't seen it myself with the Tomcat classloader doing this?
2) With the new classloader we can create an hierarchical domain
with the main deployment classloader as parent. This would allow us
to "schedule" the classloading like we do for other hierarchical domains.
But this means creating a domain for the subdeployment classloader (not a big issue),
it's more ugly that the "parentDomain" in the metadata would be ignored since the parent
is already defined to be the main deployment classloader.
PROPOSAL
I'm going to try to implement it as (2), since having a domain
would also allow multiple copies of a dependency.
e.g. two wars with servlet style classloading could OSGi style
import apache clogging and we could let them have their own
singletons/versions of the classes.
i.e. for isolated classloading, the import would be a peer clasloader in the
sub-deployment's constructed domain not visible to others.
JOKE:
WAR developers like to have their own singletons and other junk.
Admins don't trust them and so like to give them their own sandbox. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131348#4131348
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131348
18 years, 1 month