9:42 a.m.
I'm currently working on tidying up the deployers in JBoss5
as part of that I'm adding some JMX operations so
you can query the deployer chains.
The initial simple list (it doesn't look very good without the css
which you get from the jmx console:-) is attached.
A quick scan of this shows some funny things or at least
some misunderstanding of the relative ordering parameter.
The relative order parameter only applies when the deployers
have similar input/outputs. It's there for when you have multiple
"filter"s. i.e. a deployer that has the same input/output type
and you need to control the order in which the filters run
(you should try to design away such a requirement if possible).
e.g. VFSClassLoaderClassPathDeployer is a filter
it inputs and outputs ClassLoadingMetaData.
So does the ClassLoadingDefaultDeployer.
1) Webservices
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE
Currently the ordering of these is pretty weak.
i.e. there is no guarantee the PRE will run before the POST,
except that the relative order of PRE is -1 compared with Tomcat
and the POST must run after Tomcat.
This is very brittle to changes in the Tomcat Deployer which
might move it earlier in the chain due to changes in its requirements.
i.e. The TomcatDeployer takes some additional metadata beyond
JBossWebMetaData.
Shouldn't the PRE deployer also output JBossWebMetaData
to show it modifies or process it and therefore MUST run before Tomcat?
2) AOP ClassLoading
A similar criticism applies for the AOPClassLoaderDeployer
This has no chain definition at all? Only a relative order based
on the main classloader deployer.
Again this is brittle to a refactoring of how the classloader deployer
works.
3) SEAM
org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
doesn't specify any output.
But I don't know where the source is for that?
My guess is that this should really be in Describe and specify an
output of ClassLoadingMetadata since that is where
classloading dependencies should be constructed.
4) WEB CLUSTERING
org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer
I don't know what this is doing in Describe since it is not
establing a deployment dependency. Instead it is modifying the
JBossWebMetaData.
I'd guess this should be after the merge of annotations into that
metadata? Although I don't think there is such an annotation
currently? :-)
5+) There could be others. Like I said this is just a quick scan.
TODO
I'm going to be adding some other queries so you can display individual
metadata chains for an attachment type and graphs so can see
where attachments may have orginated from other attachments.
Additionally you'll also be able to see deployers that were used
for an individual deployment (including by subdeployment/component).
Any other ideas?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:17 a.m.
On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
2) AOP ClassLoading
A similar criticism applies for the AOPClassLoaderDeployer
This has no chain definition at all? Only a relative order based
on the main classloader deployer.
Again this is brittle to a refactoring of how the classloader deployer
works.
https://jira.jboss.org/jira/browse/JBDEPLOY-96
Kabir, can you modify your deployer to specify
java.lang.ClassLoader as an input instead of using the relative
ordering.
Also this deployer says it needs a VFS deployment.
Other than the names used within AOP;
ScopedVFSClassLoaderDomain
VFSClassLoaderDomainRegistry
I don't see any dependency on the VFS api?
It might have done in the past until we refactored the
way in the memory url part of the classpath is done?
Finally, this still hasn't been updated to understand
how subdeployment classloaders work. It should be asking
whether the (sub-)deployment has an
org.jboss.classloading.spi.dependency.Module
attachment and hence its own classloader.
Even the old code which has some hardwiring for JBossWebMetaData
looks broken since it only unregisters top level deployment
classloaders in undeploy() ?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:54 a.m.
I will look early next week https://jira.jboss.org/jira/browse/JBAS-6032
On 3 Oct 2008, at 16:17, Adrian Brock wrote:
On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
> 2) AOP ClassLoading
>
> A similar criticism applies for the AOPClassLoaderDeployer
> This has no chain definition at all? Only a relative order based
> on the main classloader deployer.
>
> Again this is brittle to a refactoring of how the classloader
> deployer
> works.
https://jira.jboss.org/jira/browse/JBDEPLOY-96
Kabir, can you modify your deployer to specify
java.lang.ClassLoader as an input instead of using the relative
ordering.
Also this deployer says it needs a VFS deployment.
Other than the names used within AOP;
ScopedVFSClassLoaderDomain
VFSClassLoaderDomainRegistry
I don't see any dependency on the VFS api?
It might have done in the past until we refactored the
way in the memory url part of the classpath is done?
Finally, this still hasn't been updated to understand
how subdeployment classloaders work. It should be asking
whether the (sub-)deployment has an
org.jboss.classloading.spi.dependency.Module
attachment and hence its own classloader.
Even the old code which has some hardwiring for JBossWebMetaData
looks broken since it only unregisters top level deployment
classloaders in undeploy() ?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:56 a.m.
On 3 Oct 2008, at 16:17, Adrian Brock wrote:
On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
> 2) AOP ClassLoading
>
> A similar criticism applies for the AOPClassLoaderDeployer
> This has no chain definition at all? Only a relative order based
> on the main classloader deployer.
>
> Again this is brittle to a refactoring of how the classloader
> deployer
> works.
https://jira.jboss.org/jira/browse/JBDEPLOY-96
Kabir, can you modify your deployer to specify
java.lang.ClassLoader as an input instead of using the relative
ordering.
I have tried to do the following
public AOPClassLoaderDeployer(int xmlRelativeOrder)
{
setStage(DeploymentStages.CLASSLOADER);
- //This needs to come after the classloader deployer
- setRelativeOrder(xmlRelativeOrder + 1);
+
+ //This makes it come after the ClassLoaderDeployer
+ setInput(ClassLoader.class);
}
but now it looks like deployer is not triggered at all. Is there
anything else I need to do?
Also this deployer says it needs a VFS deployment.
Other than the names used within AOP;
ScopedVFSClassLoaderDomain
VFSClassLoaderDomainRegistry
I don't see any dependency on the VFS api?
Fixed
It might have done in the past until we refactored the
way in the memory url part of the classpath is done?
Finally, this still hasn't been updated to understand
how subdeployment classloaders work. It should be asking
whether the (sub-)deployment has an
org.jboss.classloading.spi.dependency.Module
attachment and hence its own classloader.
Just to be clear, can there be arbitrary levels of classloaders within
a deployment's sub-deployments now?
Even the old code which has some hardwiring for JBossWebMetaData
looks broken since it only unregisters top level deployment
classloaders in undeploy() ?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:58 a.m.
I have tried to do the following
public AOPClassLoaderDeployer(int xmlRelativeOrder)
{
setStage(DeploymentStages.CLASSLOADER);
- //This needs to come after the classloader deployer
- setRelativeOrder(xmlRelativeOrder + 1);
+
+ //This makes it come after the ClassLoaderDeployer
+ setInput(ClassLoader.class);
}
This is just for trying it out, once it works I'll obviously remove
the constructor parameter
10:58 a.m.
On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote:
> Kabir, can you modify your deployer to specify
> java.lang.ClassLoader as an input instead of using the relative
> ordering.
I have tried to do the following
public AOPClassLoaderDeployer(int xmlRelativeOrder)
{
setStage(DeploymentStages.CLASSLOADER);
- //This needs to come after the classloader deployer
- setRelativeOrder(xmlRelativeOrder + 1);
+
+ //This makes it come after the ClassLoaderDeployer
+ setInput(ClassLoader.class);
}
but now it looks like deployer is not triggered at all. Is there
anything else I need to do?
The setInput() means the attachment is required to exist
otherwise it won't invoke your deployer.
If you use addInput() then the name is only used in ordering.
If you look at the deployer interface there are actually
two different properties;
input - required attachment
inputs - only used in ordering
I guess the method should have been called setRequiredInput()
to avoid the confusion. ;-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:35 a.m.
Thanks, addInput() works
On 7 Oct 2008, at 16:58, Adrian Brock wrote:
On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote:
>> Kabir, can you modify your deployer to specify
>> java.lang.ClassLoader as an input instead of using the relative
>> ordering.
> I have tried to do the following
>
> public AOPClassLoaderDeployer(int xmlRelativeOrder)
> {
> setStage(DeploymentStages.CLASSLOADER);
> - //This needs to come after the classloader deployer
> - setRelativeOrder(xmlRelativeOrder + 1);
> +
> + //This makes it come after the ClassLoaderDeployer
> + setInput(ClassLoader.class);
> }
>
> but now it looks like deployer is not triggered at all. Is there
> anything else I need to do?
>
The setInput() means the attachment is required to exist
otherwise it won't invoke your deployer.
If you use addInput() then the name is only used in ordering.
If you look at the deployer interface there are actually
two different properties;
input - required attachment
inputs - only used in ordering
I guess the method should have been called setRequiredInput()
to avoid the confusion. ;-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:25 a.m.
New subject: ClassLoaderDomains and hierarchy WAS Re: Deployment chains
On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote:
> Finally, this still hasn't been updated to understand
> how subdeployment classloaders work. It should be asking
> whether the (sub-)deployment has an
> org.jboss.classloading.spi.dependency.Module
> attachment and hence its own classloader.
Just to be clear, can there be arbitrary levels of classloaders within
a deployment's sub-deployments now?
That's really two different questions/issues.
The old HeirarchicalLoaderRepository only supported one level
of hierarchy, but it could only be used with top level deployments.
The war classloader was a special case, hence all the hacks
you had to do. :-)
Now the ClassLoaderDomains can go to abitrary levels,
and Subdeployment classloaders are no longer restricted
to just wars.
Subdeployment classloaders are created in their own domains.
You can determine the rules from the Module attachments
of the deployment structure.
domain/parent -> result
1) DefaultDomain/Nothing -> this is in the default domain
with a parent of the jboss bootstrap classloader
2) Domain1/Domain2 -> in domain1 with parent domain2
This applies to both top level and subdeployment classloaders.
i.e. if a subdeployment specifies a parent domain, it is
not a child of the top level deployment classloader
3) Domain1/Nothing -> A subdeployment classloader in domain1
with a parent domain equal to the subdeployment's parent
deployment's classloader (phew! :-).
The last one is harder to explain in English, here's an example
which should make it clearer.
Suppose you have an ear in Domain1, which has
a parent domain of DefaultDomain.
Inside the ear is a war in Domain2.
Domain2 is not directly a child of Domain1 like (2). Instead it goes
through the ear's classloader. That way it can see
unexported classes in the ear that others in Domain1 might
not be able to see (this is the OSGi stuff again :-).
NOTE: We may in future support (3) for top level deployments.
i.e. you could have multiple root domains for your classloaders.
That case would be similar to (3) except now the parent
is the jboss bootstrap classloader like (1)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:04 a.m.
New subject: ClassLoaderDomains and hierarchy WAS Re: Deployment chains
I've moved this part of the discussion here
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181042#...
On 7 Oct 2008, at 17:25, Adrian Brock wrote:
On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote:
>> Finally, this still hasn't been updated to understand
>> how subdeployment classloaders work. It should be asking
>> whether the (sub-)deployment has an
>> org.jboss.classloading.spi.dependency.Module
>> attachment and hence its own classloader.
>
> Just to be clear, can there be arbitrary levels of classloaders
> within
> a deployment's sub-deployments now?
That's really two different questions/issues.
The old HeirarchicalLoaderRepository only supported one level
of hierarchy, but it could only be used with top level deployments.
The war classloader was a special case, hence all the hacks
you had to do. :-)
Now the ClassLoaderDomains can go to abitrary levels,
and Subdeployment classloaders are no longer restricted
to just wars.
Subdeployment classloaders are created in their own domains.
You can determine the rules from the Module attachments
of the deployment structure.
domain/parent -> result
1) DefaultDomain/Nothing -> this is in the default domain
with a parent of the jboss bootstrap classloader
2) Domain1/Domain2 -> in domain1 with parent domain2
This applies to both top level and subdeployment classloaders.
i.e. if a subdeployment specifies a parent domain, it is
not a child of the top level deployment classloader
3) Domain1/Nothing -> A subdeployment classloader in domain1
with a parent domain equal to the subdeployment's parent
deployment's classloader (phew! :-).
The last one is harder to explain in English, here's an example
which should make it clearer.
Suppose you have an ear in Domain1, which has
a parent domain of DefaultDomain.
Inside the ear is a war in Domain2.
Domain2 is not directly a child of Domain1 like (2). Instead it goes
through the ear's classloader. That way it can see
unexported classes in the ear that others in Domain1 might
not be able to see (this is the OSGi stuff again :-).
NOTE: We may in future support (3) for top level deployments.
i.e. you could have multiple root domains for your classloaders.
That case would be similar to (3) except now the parent
is the jboss bootstrap classloader like (1)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:19 a.m.
3) SEAM
org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
doesn't specify any output.
But I don't know where the source is for that?
My guess is that this should really be in Describe and specify an
output of ClassLoadingMetadata since that is where
classloading dependencies should be constructed.
There are two ways of doing this.
(1) [current usage] adding url/virtual file to VFSDeploymentUnit classpath
(2) once we enable requirements/capabilities, you'll add the right
requirement
So my question is, should (1) really output CLMD, since it doesn't do
anything wrt it.
btw: the source is here:
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/
10:25 a.m.
On Fri, 2008-10-03 at 17:19 +0200, Ales Justin wrote:
> 3) SEAM
>
> org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
> doesn't specify any output.
> But I don't know where the source is for that?
> My guess is that this should really be in Describe and specify an
> output of ClassLoadingMetadata since that is where
> classloading dependencies should be constructed.
There are two ways of doing this.
(1) [current usage] adding url/virtual file to VFSDeploymentUnit classpath
(2) once we enable requirements/capabilities, you'll add the right
requirement
So my question is, should (1) really output CLMD, since it doesn't do
anything wrt it.
But it will in the future. And other deployers use the CLMD as
input/output to be a proxy for modifying/processing
DeploymentUnit::classpath anyway. It kind of keeps things simple
having one attachment to control the classloader processing order.
e.g. the classpath deployer removes duplicates
and aggregates classpath elements based on the CLMDs of the
(sub-)deployments.
You definitely wnat to run before that happens since its output
(and not the individual classpaths) is what actually
gets used to create the classloaders.
btw: the source is here:
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:35 a.m.
The second part would be a major change.
Each deployer would have to pass some id as it creates/modifies
attachments.
That is unless we hacked it such that the DeployerWrapper sets
a thread local for the AttachmentsImpl to look at?
Even then, unless we changed the Attachments spi,
there's no guarantee AttachmentsImpl gets used.
e.g. the predetermined stuff gets populated from the Deployment
passed to client api of the deployers.
But in general, the deployers should not be putting
anything in predetermined anyway. It defeats the point
and may not even be allowed with some implementations of
Attachments. ;-)
When I say I'm going to show which deployers process which
deployments, its basically going to be a re-calculation
of what gets done in DeployersImpl::isRelevant()
from the attachments/components that exist at the end of the deployment
processing.
On Fri, 2008-10-03 at 08:34 -0700, Scott Stark wrote:
Another runtime view is what the source of an attachment is involved
in the chain:
PredeterminedManagedObjects
TransientManagedObjects
TransientAttachments
and ideally which deployer set the current attachment at each level.
This relates to tracking whether the correct
attachment is being used when the profile service sets a
PredeterminedManagedObject.
Adrian Brock wrote:
> I'm currently working on tidying up the deployers in JBoss5
> as part of that I'm adding some JMX operations so
> you can query the deployer chains.
>
> The initial simple list (it doesn't look very good without the css
> which you get from the jmx console:-) is attached.
>
> A quick scan of this shows some funny things or at least
> some misunderstanding of the relative ordering parameter.
>
> The relative order parameter only applies when the deployers
> have similar input/outputs. It's there for when you have multiple
> "filter"s. i.e. a deployer that has the same input/output type
> and you need to control the order in which the filters run
> (you should try to design away such a requirement if possible).
>
> e.g. VFSClassLoaderClassPathDeployer is a filter
> it inputs and outputs ClassLoadingMetaData.
> So does the ClassLoadingDefaultDeployer.
>
> 1) Webservices
>
> org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE
> org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE
>
> Currently the ordering of these is pretty weak.
>
> i.e. there is no guarantee the PRE will run before the POST,
> except that the relative order of PRE is -1 compared with Tomcat
> and the POST must run after Tomcat.
>
> This is very brittle to changes in the Tomcat Deployer which
> might move it earlier in the chain due to changes in its requirements.
> i.e. The TomcatDeployer takes some additional metadata beyond
> JBossWebMetaData.
>
> Shouldn't the PRE deployer also output JBossWebMetaData
> to show it modifies or process it and therefore MUST run before Tomcat?
>
> 2) AOP ClassLoading
>
> A similar criticism applies for the AOPClassLoaderDeployer
> This has no chain definition at all? Only a relative order based
> on the main classloader deployer.
>
> Again this is brittle to a refactoring of how the classloader deployer
> works.
>
> 3) SEAM
>
> org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
> doesn't specify any output.
> But I don't know where the source is for that?
> My guess is that this should really be in Describe and specify an
> output of ClassLoadingMetadata since that is where
> classloading dependencies should be constructed.
>
> 4) WEB CLUSTERING
>
> org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer
> I don't know what this is doing in Describe since it is not
> establing a deployment dependency. Instead it is modifying the
> JBossWebMetaData.
> I'd guess this should be after the merge of annotations into that
> metadata? Although I don't think there is such an annotation
> currently? :-)
>
> 5+) There could be others. Like I said this is just a quick scan.
>
> TODO
>
> I'm going to be adding some other queries so you can display individual
> metadata chains for an attachment type and graphs so can see
> where attachments may have orginated from other attachments.
>
> Additionally you'll also be able to see deployers that were used
> for an individual deployment (including by subdeployment/component).
>
> Any other ideas?
>
>
>
> ____________________________________________________________________
>
> JMX MBean Operation View
> warjort
>
>
>
>
>
> Stage/Deployer
> top
> component
> parent last
> input
> output
> Real
> `--org.jboss.ejb.deployers.EjbDeployer@c221d7
>
>
>
> org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.ejb.deployers.EjbDeployment
>
>
>
>
>
> org.jboss.system.metadata.ServiceMetaData
>
>
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
> `--org.jboss.ejb3.deployers.Ejb3ClientDeployer@b40443
>
>
>
> org.jboss.metadata.client.jboss.JBossClientMetaData
> org.jboss.ejb3.clientmodule.ClientENCInjectionContainer
>
>
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
> `--org.jboss.ejb3.deployers.Ejb3Deployer@102abdb
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.ejb3.Ejb3Deployment
>
>
>
>
> org.jboss.ejb3.metadata.jpa.spec.PersistenceUnitsMetaData
> org.jboss.kernel.spi.deployment.KernelDeployment
> `--org.jboss.deployers.vfs.deployer.kernel.AliasDeploymentDeployer@1aff012
>
>
>
> org.jboss.beans.metadata.spi.NamedAliasMetaData
> org.jboss.beans.metadata.spi.NamedAliasMetaData
>
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
>
> `--org.jboss.hibernate.deployers.HibernateDeployer@13dff89
>
>
>
> org.jboss.hibernate.deployers.metadata.HibernateMetaData
> org.jboss.beans.metadata.spi.BeanMetaData
> `--org.jboss.jpa.deployers.PersistenceDeployer@17fe89
>
>
>
> org.jboss.metadata.jpa.spec.PersistenceMetaData
>
> `--org.jboss.jpa.deployers.PersistenceUnitDeployer@a06824
>
> X
>
> org.jboss.metadata.jpa.spec.PersistenceUnitMetaData
> org.jboss.beans.metadata.spi.BeanMetaData
> `--org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer@39ea58
>
>
>
> org.jboss.beans.metadata.spi.BeanMetaData
> org.jboss.beans.metadata.spi.BeanMetaData
>
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
>
> `--org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer@10ff62a
>
> X
>
> org.jboss.beans.metadata.spi.BeanMetaData
>
> `--org.jboss.deployers.vfs.deployer.kernel.DeploymentAliasMetaDataDeployer@11ef9f6
>
> X
>
> org.jboss.beans.metadata.spi.NamedAliasMetaData
>
>
>
>
>
> org.jboss.beans.metadata.spi.BeanMetaData
>
> `--org.jboss.resource.deployers.ManagedConnectionFactoryDeployer@1b2601c
>
>
>
> org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentGroup
> org.jboss.system.metadata.ServiceDeployment
> `--org.jboss.resource.deployers.RARDeployer@1ecda50
>
>
>
> org.jboss.resource.metadata.RARDeploymentMetaData
> org.jboss.system.metadata.ServiceMetaData
> `--org.jboss.varia.deployment.LegacyBeanShellScriptDeployer@f7ce53
>
>
>
> org.jboss.varia.deployment.BeanShellScript
>
> `--org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB@13be416
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.wsf.spi.deployment.integration.WebServiceDeployment
>
>
>
>
> org.jboss.ejb.deployers.EjbDeployment
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
>
>
>
> org.jboss.ejb3.Ejb3Deployment
>
> `--org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE@83cf00
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
> `--org.jboss.web.tomcat.service.deployers.TomcatDeployer@dfa65c
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
> org.jboss.web.deployers.WarDeployment
>
>
>
>
>
> org.jboss.system.metadata.ServiceMetaData
> `--org.jboss.system.deployers.ServiceDeploymentDeployer@bc6007
>
>
>
> org.jboss.system.metadata.ServiceMetaData
> org.jboss.system.metadata.ServiceMetaData
>
>
>
>
> org.jboss.system.metadata.ServiceDeployment
>
> `--org.jboss.system.deployers.ServiceDeployer@1a697a1
>
> X
>
> org.jboss.system.metadata.ServiceMetaData
>
> `--org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE@1560b81
>
>
>
> org.jboss.web.deployers.WarDeployment
>
> ClassLoader
>
`--org.jboss.deployers.plugins.classloading.AbstractLevelClassLoaderSystemDeployer@2726b2
>
>
>
> org.jboss.deployers.structure.spi.ClassLoaderFactory
>
> `--org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer@19845fb
>
>
>
>
>
> PostClassLoader
> `--org.jboss.aop.asintegration.jboss5.AOPDeploymentAopMetaDataDeployer@1b88122
>
>
>
> org.jboss.aop.microcontainer.beans.metadata.AOPDeployment
> org.jboss.aop.asintegration.jboss5.AopMetaDataDeployerOutput
> `--org.jboss.aop.asintegration.jboss5.BeansDeploymentAopMetaDataDeployer@14f1726
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
> org.jboss.aop.asintegration.jboss5.AopMetaDataDeployerOutput
> `--org.jboss.deployment.EarLibExcludeDeployer@2957a4
> X
>
>
> org.jboss.metadata.ear.jboss.JBossAppMetaData
> org.jboss.classloading.spi.visitor.ResourceFilter.recurse
>
`--org.jboss.deployers.vfs.plugins.annotations.FilteredAnnotationEnvironmentDeployer@25502e
>
>
>
> org.jboss.classloading.spi.dependency.Module
> org.jboss.deployers.spi.annotations.AnnotationEnvironment
>
>
>
>
> org.jboss.classloading.spi.visitor.ResourceFilter.recurse
>
> `--org.jboss.deployment.EarSecurityDeployer@1fac352
>
>
>
> org.jboss.metadata.ear.jboss.JBossAppMetaData
> jboss.jacc
>
>
>
>
>
> org.jboss.system.metadata.ServiceMetaData
> `--org.jboss.deployment.OptAnnotationMetaDataDeployer@7f9e04
>
>
>
> org.jboss.metadata.web.spec.WebMetaData
> annotated.org.jboss.metadata.ejb.spec.EjbJarMetaData
>
>
>
>
> org.jboss.metadata.ejb.spec.EjbJarMetaData
> annotated.org.jboss.metadata.web.spec.WebMetaData
>
>
>
>
> org.jboss.metadata.client.spec.ApplicationClientMetaData
> annotated.org.jboss.metadata.client.spec.ApplicationClientMetaData
>
>
>
>
> org.jboss.deployers.spi.annotations.AnnotationEnvironment
>
> `--org.jboss.ejb.deployers.MergedJBossMetaDataDeployer@1ad552c
>
>
>
> annotated.org.jboss.metadata.ejb.spec.EjbJarMetaData
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
>
>
>
>
> org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.metadata.ejb.jboss.JBossMetaData
>
>
>
>
> org.jboss.metadata.ejb.spec.EjbJarMetaData
>
> `--org.jboss.ejb3.deployers.MergedJBossClientMetaDataDeployer@1219665
>
>
>
> annotated.org.jboss.metadata.client.spec.ApplicationClientMetaData
> merged.org.jboss.metadata.client.jboss.JBossClientMetaData
>
>
>
>
> org.jboss.metadata.client.jboss.JBossClientMetaData
> org.jboss.metadata.client.jboss.JBossClientMetaData
>
>
>
>
> org.jboss.metadata.client.spec.ApplicationClientMetaData
>
>
`--org.jboss.ha.framework.server.deployers.Ejb2HAPartitionDependencyDeployer@19bb448
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
>
`--org.jboss.ha.framework.server.deployers.Ejb3HAPartitionDependencyDeployer@1033c7e
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> `--org.jboss.ejb.deployers.EjbMetadataJndiPolicyDecoratorDeployer@8ee94b
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> EjbMetadataJndiPolicyDecoratorDeployer
> `--org.jboss.ejb.deployers.StandardJBossMetaDataDeployer@101f8f4
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.metadata.ejb.jboss.JBossMetaData
>
>
>
>
> org.jboss.metadata.ejb.jboss.JBossMetaData
> raw.org.jboss.metadata.ejb.jboss.JBossMetaData
>
>
>
>
> standardjboss.xml
>
> `--org.jboss.ejb.deployers.EjbSecurityDeployer@514577
>
>
>
> merged.org.jboss.metadata.ejb.jboss.JBossMetaData
> jboss.jacc
>
>
>
>
> org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.system.metadata.ServiceMetaData
> `--org.jboss.web.deployers.MergedJBossWebMetaDataDeployer@1c9982e
>
>
>
> org.jboss.metadata.web.spec.WebMetaData
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
>
>
>
> annotated.org.jboss.metadata.web.spec.WebMetaData
> merged.org.jboss.metadata.web.jboss.JBossWebMetaData
>
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
> `--org.jboss.deployment.MappedReferenceMetaDataResolverDeployer@1908558
>
>
> X
> org.jboss.metadata.ejb.jboss.JBossMetaData
> org.jboss.deployment.spi.DeploymentEndpointResolver
>
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
>
>
>
>
> org.jboss.metadata.client.jboss.JBossClientMetaData
>
> `--org.jboss.web.deployers.WarSecurityDeployer@18a4622
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
> jboss.jacc
>
>
>
>
>
> org.jboss.system.metadata.ServiceMetaData
> Describe
> `--org.jboss.deployers.vfs.plugins.classloader.InMemoryClassesDeployer@4de3fe
> X
>
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
>
`--org.jboss.deployers.vfs.plugins.classloader.VFSClassLoaderClassPathDeployer@157b39f
>
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
>
`--org.jboss.deployers.vfs.plugins.classloader.VFSClassLoaderDescribeDeployer@e0d16b
>
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
>
> `--org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer@ebdfff
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
> org.jboss.metadata.web.jboss.JBossWebMetaData
> PreDescribe
> `--org.jboss.deployers.plugins.classloading.ClassLoadingDefaultDeployer@721965
> X
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> PostParse
> `--org.jboss.resource.deployers.ManagedConnectionFactoryClassLoaderDeployer@11d00cf
>
>
>
> org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentGroup
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> `--org.jboss.system.deployers.HackClassloaderMetaDataDeployer@1eef2c
>
>
>
> org.jboss.mx.loading.LoaderRepositoryFactory$LoaderRepositoryConfig
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> `--org.jboss.web.tomcat.service.deployers.ClusteringDefaultsDeployer@f8d6a6
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
> org.jboss.metadata.web.jboss.JBossWebMetaData
> `--org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer@192c4c
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
>
>
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
>
>
`--org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer@145240a
>
>
>
> org.jboss.metadata.web.jboss.JBossWebMetaData
>
> Parse
> `--org.jboss.deployers.vfs.deployer.kernel.BeanDeployer@57dc15
>
>
>
>
> org.jboss.kernel.spi.deployment.KernelDeployment
> `--org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer@13bc30a
>
>
>
>
> org.jboss.classloading.spi.metadata.ClassLoadingMetaData
> `--org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer@1ba1d9
>
>
>
>
> org.jboss.aop.microcontainer.beans.metadata.AOPDeployment
> `--org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer@543937
>
>
>
>
> org.jboss.security.microcontainer.beans.metadata.SecurityPolicyMetaData
> `--org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer@bbe4cf
>
>
>
>
> org.jboss.hibernate.deployers.metadata.HibernateMetaData
> `--org.jboss.deployment.AppParsingDeployer@97ed28
>
>
>
>
> org.jboss.metadata.ear.spec.EarMetaData
> `--org.jboss.deployment.JBossAppParsingDeployer@17a33f2
>
>
>
>
> org.jboss.metadata.ear.jboss.JBossAppMetaData
> `--org.jboss.ejb3.deployers.AppClientParsingDeployer@b11287
>
>
>
>
> org.jboss.metadata.client.spec.ApplicationClientMetaData
> `--org.jboss.ejb3.deployers.JBossClientParsingDeployer@18cecd
>
>
>
> org.jboss.metadata.client.spec.ApplicationClientMetaData
> org.jboss.metadata.client.jboss.JBossClientMetaData
> `--org.jboss.ejb3.deployers.PersistenceUnitParsingDeployer@d9c6e2
>
>
>
>
> org.jboss.metadata.jpa.spec.PersistenceMetaData
> `--org.jboss.jpa.deployers.PersistenceParsingDeployer@105e560
>
>
>
>
> org.jboss.metadata.jpa.spec.PersistenceMetaData
> `--org.jboss.resource.deployers.ManagedConnectionFactoryParserDeployer@1310e0a
>
>
>
>
> org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentGroup
> `--org.jboss.resource.deployers.RARParserDeployer@1ba640
>
>
>
>
> org.jboss.resource.metadata.RARDeploymentMetaData
> `--org.jboss.system.deployers.SARDeployer@83e35b
>
>
>
>
> org.jboss.system.metadata.ServiceDeployment
> `--org.jboss.varia.deployment.LegacyBeanShellDeployer@4a4e31
>
>
>
>
> org.jboss.varia.deployment.BeanShellScript
> `--org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer@1e40274
>
>
>
>
> org.jboss.aop.microcontainer.beans.metadata.AOPDeployment
> `--org.jboss.deployment.EARContentsDeployer@f003c1
>
>
>
>
> org.jboss.metadata.ear.jboss.JBossAppMetaData
> `--org.jboss.deployment.WebAppParsingDeployer@156cd93
>
>
>
>
> org.jboss.metadata.web.spec.WebMetaData
> `--org.jboss.deployment.JBossWebAppParsingDeployer@12b2f7f
>
>
>
> org.jboss.metadata.web.spec.WebMetaData
> org.jboss.metadata.web.jboss.JBossWebMetaData
> `--org.jboss.deployment.EjbParsingDeployer@1d1e765
>
>
>
>
> org.jboss.metadata.ejb.spec.EjbJarMetaData
> `--org.jboss.deployment.JBossEjbParsingDeployer@10725b4
>
>
>
> org.jboss.metadata.ejb.spec.EjbJarMetaData
> org.jboss.metadata.ejb.jboss.JBossMetaData
>
>
>
>
>
> org.jboss.metadata.ApplicationMetaData
>
>
>
>
>
> org.jboss.mx.loading.LoaderRepositoryFactory$LoaderRepositoryConfig
>
>
>
>
>
> standardjboss.xml
>
>
>
> ____________________________________________________________________
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:43 a.m.
Ok, I'm going to be working with Emanuel to get the admin edits pushed
into the profile deployments next week, so we'll see
what comes up. I expect the profile service could/should be using an
AttachmentsImpl that does preclude any further setting of
the predetermined value once set?
Adrian Brock wrote:
The second part would be a major change.
Each deployer would have to pass some id as it creates/modifies
attachments.
That is unless we hacked it such that the DeployerWrapper sets
a thread local for the AttachmentsImpl to look at?
Even then, unless we changed the Attachments spi,
there's no guarantee AttachmentsImpl gets used.
e.g. the predetermined stuff gets populated from the Deployment
passed to client api of the deployers.
But in general, the deployers should not be putting
anything in predetermined anyway. It defeats the point
and may not even be allowed with some implementations of
Attachments. ;-)
When I say I'm going to show which deployers process which
deployments, its basically going to be a re-calculation
of what gets done in DeployersImpl::isRelevant()
from the attachments/components that exist at the end of the deployment
processing.
On Fri, 2008-10-03 at 08:34 -0700, Scott Stark wrote:
> Another runtime view is what the source of an attachment is involved
> in the chain:
>
> PredeterminedManagedObjects
> TransientManagedObjects
> TransientAttachments
>
> and ideally which deployer set the current attachment at each level.
> This relates to tracking whether the correct
> attachment is being used when the profile service sets a
> PredeterminedManagedObject.
>
>
10:08 a.m.
I've managed to do this another way.
I basically only keep track of who changes the transient
(managed object) attachments. See JBDEPLOY-99 for more
implementation details.
A sample output is attached (this is for the console-mgr.sar)
The "UNKNOWN" means it is getting created/referenced outside
a deployer.
If you want to try it yourself, build the latest deployers
and modify conf/deployers.xml to uncomment the FIXME JBAS-6030
You can find the JMX mbeans in the jboss.deployment domain.
The operation is listAttachments(boolean) where the parameter
says whether you want to see the attachment contents.
On Fri, 2008-10-03 at 09:43 -0700, Scott Stark wrote:
Ok, I'm going to be working with Emanuel to get the admin edits
pushed
into the profile deployments next week, so we'll see
what comes up. I expect the profile service could/should be using an
AttachmentsImpl that does preclude any further setting of
the predetermined value once set?
Adrian Brock wrote:
> The second part would be a major change.
>
> Each deployer would have to pass some id as it creates/modifies
> attachments.
>
> That is unless we hacked it such that the DeployerWrapper sets
> a thread local for the AttachmentsImpl to look at?
>
> Even then, unless we changed the Attachments spi,
> there's no guarantee AttachmentsImpl gets used.
> e.g. the predetermined stuff gets populated from the Deployment
> passed to client api of the deployers.
>
> But in general, the deployers should not be putting
> anything in predetermined anyway. It defeats the point
> and may not even be allowed with some implementations of
> Attachments. ;-)
>
> When I say I'm going to show which deployers process which
> deployments, its basically going to be a re-calculation
> of what gets done in DeployersImpl::isRelevant()
> from the attachments/components that exist at the end of the deployment
> processing.
>
> On Fri, 2008-10-03 at 08:34 -0700, Scott Stark wrote:
>
>> Another runtime view is what the source of an attachment is involved
>> in the chain:
>>
>> PredeterminedManagedObjects
>> TransientManagedObjects
>> TransientAttachments
>>
>> and ideally which deployer set the current attachment at each level.
>> This relates to tracking whether the correct
>> attachment is being used when the profile service sets a
>> PredeterminedManagedObject.
>>
>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:17 a.m.
New subject: AspectManager in the wrong bucket WAS Re: Deployment chains
On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
A sample output is attached (this is for the console-mgr.sar)
The sample out on the earlier post shows that
org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
is putting the AspectManager attachment in the wrong "bucket".
Implementation details should go in the transient attachments.
Which is the default if you use addAttachment().
The managed objects are intended to hold attachments that
come from xml so we can differentiate what we create and
what the user specified.
e.g. You'll also see that for the console-mgr.sar
the ClassLoadingMetaData is also in the transient attachments.
That is because it was created from the <loader-repository/>
xml of the -service.xml.
If it had come from META-INF/jboss-classloading.xml
it would be in the managed objects.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:09 p.m.
New subject: Deployment chains
Adrian, how much work you have left with the deployers?
Just asking, since I'm about to do CR2 release tomorrow.
Should I wait - for some stuff you still wanna include in the CR2,
or I can go ahead?
I'll at least wait for the reply to this email. ;-)
(not that hard, since deployers are the last in MC release chain :-)
Adrian Brock wrote:
On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
> A sample output is attached (this is for the console-mgr.sar)
The sample out on the earlier post shows that
org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
is putting the AspectManager attachment in the wrong "bucket".
Implementation details should go in the transient attachments.
Which is the default if you use addAttachment().
The managed objects are intended to hold attachments that
come from xml so we can differentiate what we create and
what the user specified.
e.g. You'll also see that for the console-mgr.sar
the ClassLoadingMetaData is also in the transient attachments.
That is because it was created from the <loader-repository/>
xml of the -service.xml.
If it had come from META-INF/jboss-classloading.xml
it would be in the managed objects.
2:37 p.m.
New subject: Deployment chains
You can release it as is.
More management stuff can be added required.
The stuff I've done so far, was just so I could
easily see what the deployers were actually doing
for this task:
https://jira.jboss.org/jira/browse/JBAS-5044
I dare say Scott may have other requirements
when he gets chance to review it.
On Mon, 2008-10-06 at 21:09 +0200, Ales Justin wrote:
Adrian, how much work you have left with the deployers?
Just asking, since I'm about to do CR2 release tomorrow.
Should I wait - for some stuff you still wanna include in the CR2,
or I can go ahead?
I'll at least wait for the reply to this email. ;-)
(not that hard, since deployers are the last in MC release chain :-)
Adrian Brock wrote:
> On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
>> A sample output is attached (this is for the console-mgr.sar)
>
> The sample out on the earlier post shows that
> org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
> is putting the AspectManager attachment in the wrong "bucket".
>
> Implementation details should go in the transient attachments.
> Which is the default if you use addAttachment().
>
> The managed objects are intended to hold attachments that
> come from xml so we can differentiate what we create and
> what the user specified.
>
> e.g. You'll also see that for the console-mgr.sar
> the ClassLoadingMetaData is also in the transient attachments.
> That is because it was created from the <loader-repository/>
> xml of the -service.xml.
> If it had come from META-INF/jboss-classloading.xml
> it would be in the managed objects.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:23 p.m.
New subject: Deployment chains
What about that discussion you had with Carlo,
about porting the component visitor?
Although I must say I didn't fully understand that discussion :-)
as to what is currently missing in AbstractComponentDeployer.
An abstract component visitor?
To relieve you of this code?
protected static void addXComponent(DeploymentUnit unit, X x)
{
DeploymentUnit component = unit.addComponent(getComponentName(x));
component.addAttachment(getAttachmentName(), x);
}
protected static void removeAliasComponent(DeploymentUnit unit, X x)
{
unit.removeComponent(getComponentName(x));
}
Adrian Brock wrote:
You can release it as is.
More management stuff can be added required.
The stuff I've done so far, was just so I could
easily see what the deployers were actually doing
for this task:
https://jira.jboss.org/jira/browse/JBAS-5044
I dare say Scott may have other requirements
when he gets chance to review it.
3:44 p.m.
New subject: Deployment chains
On Mon, 2008-10-06 at 22:23 +0200, Ales Justin wrote:
What about that discussion you had with Carlo,
about porting the component visitor?
It's not exactly a high priority.
Fixing the PersistenceDeployer to specifiy that it outputs
PersistenceUnitMetaData is. :-)
Although I must say I didn't fully understand that discussion
:-)
as to what is currently missing in AbstractComponentDeployer.
I don't understand it either.
Why setComponentVisitor() didn't work for him
is a mystery that remains unresolved, it clearly works
for the MC beans and JMX services?
So there's something different or it is too easy
to it wrong. :-)
The class in question is this one:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jpa/trunk/dep...
It obviously has nothing to do with JPA.
It's a useful abstraction so it belongs as a
deployers helper class.
It is similar to BeanMetaDataFactoryVisitor
except it only deals with the boiler plate by
adding a getName() callback.
There's a FIXME
// TODO: determine proper component meta data class
component.addAttachment(componentMD.getClass().getName(), componentMD);
Which needs to be resolved by having the subclass pass the actual component
class in the constructor, for correct use of generics.
public AbstractComponentVisitor(Class<C> componentType)
{
this.componentType = componentType;
}
component.addAttachment(componentType, componentMD);
Although if you are going to allow subclasses of C, then
the collections need fixing to be for example
List<? extends C>
An abstract component visitor?
To relieve you of this code?
protected static void addXComponent(DeploymentUnit unit, X x)
{
DeploymentUnit component = unit.addComponent(getComponentName(x));
component.addAttachment(getAttachmentName(), x);
}
protected static void removeAliasComponent(DeploymentUnit unit, X x)
{
unit.removeComponent(getComponentName(x));
}
Adrian Brock wrote:
> You can release it as is.
> More management stuff can be added required.
>
> The stuff I've done so far, was just so I could
> easily see what the deployers were actually doing
> for this task:
> https://jira.jboss.org/jira/browse/JBAS-5044
>
> I dare say Scott may have other requirements
> when he gets chance to review it.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
4:19 p.m.
New subject: Deployment chains
I don't understand it either.
Why setComponentVisitor() didn't work for him
is a mystery that remains unresolved, it clearly works
for the MC beans and JMX services?
Sure.
And for n tests that we have.
Nah, this is just being Carlo again. :-)
So there's something different or it is too easy
to it wrong. :-)
:-)
The class in question is this one:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jpa/trunk/dep...
Yeah, found it.
Thanks anyway.
It obviously has nothing to do with JPA.
It's a useful abstraction so it belongs as a
deployers helper class.
Done. ;-)
It is similar to BeanMetaDataFactoryVisitor
except it only deals with the boiler plate by
adding a getName() callback.
There's a FIXME
// TODO: determine proper component meta data class
component.addAttachment(componentMD.getClass().getName(), componentMD);
Which needs to be resolved by having the subclass pass the actual component
class in the constructor, for correct use of generics.
public AbstractComponentVisitor(Class<C> componentType)
{
this.componentType = componentType;
}
component.addAttachment(componentType, componentMD);
Although if you are going to allow subclasses of C, then
the collections need fixing to be for example
List<? extends C>
I've done a simpler version of it.
Just dealing with a single component.
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep...
Perhaps a split into:
- single component
- list of deployments
visitor would be better?
5:05 p.m.
New subject: Deployment chains
> Perhaps a split into:
> - single component
> - list of deployments
> visitor would be better?
This should read 'list of _components_' instead of deployments.
Done. ;-)
-
http://fisheye.jboss.org/changelog/JBossAS/projects/jboss-deployers/trunk...
3:02 a.m.
New subject: AspectManager in the wrong bucket WAS Re: Deployment chains
So where are you saying I should put it?
On 6 Oct 2008, at 16:17, Adrian Brock wrote:
On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
> A sample output is attached (this is for the console-mgr.sar)
The sample out on the earlier post shows that
org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
is putting the AspectManager attachment in the wrong "bucket".
Implementation details should go in the transient attachments.
Which is the default if you use addAttachment().
The managed objects are intended to hold attachments that
come from xml so we can differentiate what we create and
what the user specified.
e.g. You'll also see that for the console-mgr.sar
the ClassLoadingMetaData is also in the transient attachments.
That is because it was created from the <loader-repository/>
xml of the -service.xml.
If it had come from META-INF/jboss-classloading.xml
it would be in the managed objects.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:55 a.m.
New subject: AspectManager in the wrong bucket WAS Re: Deployment chains
On Tue, 2008-10-07 at 09:02 +0100, Kabir Khan wrote:
So where are you saying I should put it?
The transient attachments part. i.e. use
DeploymentUnit.addAttachment().
Generally, it is only the parsing deployers that should do
DeploymentUnit.getTransientManagedObjects().addAttachment()
On 6 Oct 2008, at 16:17, Adrian Brock wrote:
> On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
>> A sample output is attached (this is for the console-mgr.sar)
>
> The sample out on the earlier post shows that
> org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
> is putting the AspectManager attachment in the wrong "bucket".
>
> Implementation details should go in the transient attachments.
> Which is the default if you use addAttachment().
>
> The managed objects are intended to hold attachments that
> come from xml so we can differentiate what we create and
> what the user specified.
>
> e.g. You'll also see that for the console-mgr.sar
> the ClassLoadingMetaData is also in the transient attachments.
> That is because it was created from the <loader-repository/>
> xml of the -service.xml.
> If it had come from META-INF/jboss-classloading.xml
> it would be in the managed objects.
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Adrian Brock
> Chief Scientist
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:11 a.m.
New subject: AspectManager in the wrong bucket WAS Re: Deployment chains
Read below.
> Implementation details should go in the transient attachments.
> Which is the default if you use addAttachment().
;-)
Kabir Khan wrote:
So where are you saying I should put it?
On 6 Oct 2008, at 16:17, Adrian Brock wrote:
> On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
>> A sample output is attached (this is for the console-mgr.sar)
>
> The sample out on the earlier post shows that
> org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer
> is putting the AspectManager attachment in the wrong "bucket".
>
> Implementation details should go in the transient attachments.
> Which is the default if you use addAttachment().
>
> The managed objects are intended to hold attachments that
> come from xml so we can differentiate what we create and
> what the user specified.
>
> e.g. You'll also see that for the console-mgr.sar
> the ClassLoadingMetaData is also in the transient attachments.
> That is because it was created from the <loader-repository/>
> xml of the -service.xml.
> If it had come from META-INF/jboss-classloading.xml
> it would be in the managed objects.
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Adrian Brock
> Chief Scientist
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:25 a.m.
New subject: Bug in JMX Console WAS Re: Deployment chains
On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
If you want to try it yourself, build the latest deployers
and modify conf/deployers.xml to uncomment the FIXME JBAS-6030
You can find the JMX mbeans in the jboss.deployment domain.
The operation is listAttachments(boolean) where the parameter
says whether you want to see the attachment contents.
I also found a bug in the JMX console while testing this.
If you look at the jacc mbeans, I create a deployment mbean
called:
jboss.deployment:id="jboss.jacc:id="vfsfile:/home/ejort/jboss-head/build/output/jboss-5.0.0.GA/server/default/deploy/ROOT.war/",service=jacc",type=Component
Notice the " that I'm escaping to make sure the ObjectName parses
correctly.
This works fine when you display the MBean.
However when you invoke an operation on this MBean something in the web
layer is turning the " into " leading to a
MalformedObjectNameException.
I could of course escape it with something else, but that doesn't fix
the real problem.
I assume the problem is with the url?
But I don't know whether this should be fixed by turning
" into &quot before giving it to the browser or if the problem
is elsewhere?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:39 a.m.
New subject: Bug in JMX Console WAS Re: Deployment chains
Just to clarify the correct ObjectName
contains a property something like:
id="jboss.jacc:id="vfsfile:....""
This is being sent to the browser as is.
I think this getting is converted to
id="jboss.jacc:id="vfsfile:....""
which means it parses it wrong when creating
the ObjectName.
I guess the correct thing to write to the html page is:
id="jboss.jacc:id=&quot;vfsfile:....&quot;"
i.e.
" -> "
& -> &
so
" -> &quot;
On Mon, 2008-10-06 at 17:25 +0200, Adrian Brock wrote:
On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
> If you want to try it yourself, build the latest deployers
> and modify conf/deployers.xml to uncomment the FIXME JBAS-6030
>
> You can find the JMX mbeans in the jboss.deployment domain.
> The operation is listAttachments(boolean) where the parameter
> says whether you want to see the attachment contents.
I also found a bug in the JMX console while testing this.
If you look at the jacc mbeans, I create a deployment mbean
called:
jboss.deployment:id="jboss.jacc:id="vfsfile:/home/ejort/jboss-head/build/output/jboss-5.0.0.GA/server/default/deploy/ROOT.war/",service=jacc",type=Component
Notice the " that I'm escaping to make sure the ObjectName parses
correctly.
This works fine when you display the MBean.
However when you invoke an operation on this MBean something in the web
layer is turning the " into " leading to a
MalformedObjectNameException.
I could of course escape it with something else, but that doesn't fix
the real problem.
I assume the problem is with the url?
But I don't know whether this should be fixed by turning
" into &quot before giving it to the browser or if the problem
is elsewhere?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:58 a.m.
New subject: Bug in JMX Console WAS Re: Deployment chains
FYI. I found the invokeOp was doing some strange
quoteName() stuff that replaced quotes and apostrophies.
I replaced this with URL encoding:
https://jira.jboss.org/jira/browse/JBAS-6044
and I no longer see the problem
On Mon, 2008-10-06 at 17:39 +0200, Adrian Brock wrote:
Just to clarify the correct ObjectName
contains a property something like:
id="jboss.jacc:id="vfsfile:....""
This is being sent to the browser as is.
I think this getting is converted to
id="jboss.jacc:id="vfsfile:....""
which means it parses it wrong when creating
the ObjectName.
I guess the correct thing to write to the html page is:
id="jboss.jacc:id=&quot;vfsfile:....&quot;"
i.e.
" -> "
& -> &
so
" -> &quot;
On Mon, 2008-10-06 at 17:25 +0200, Adrian Brock wrote:
> On Mon, 2008-10-06 at 17:08 +0200, Adrian Brock wrote:
> > If you want to try it yourself, build the latest deployers
> > and modify conf/deployers.xml to uncomment the FIXME JBAS-6030
> >
> > You can find the JMX mbeans in the jboss.deployment domain.
> > The operation is listAttachments(boolean) where the parameter
> > says whether you want to see the attachment contents.
>
> I also found a bug in the JMX console while testing this.
> If you look at the jacc mbeans, I create a deployment mbean
> called:
>
jboss.deployment:id="jboss.jacc:id="vfsfile:/home/ejort/jboss-head/build/output/jboss-5.0.0.GA/server/default/deploy/ROOT.war/",service=jacc",type=Component
>
> Notice the " that I'm escaping to make sure the ObjectName parses
> correctly.
>
> This works fine when you display the MBean.
> However when you invoke an operation on this MBean something in the web
> layer is turning the " into " leading to a
> MalformedObjectNameException.
>
> I could of course escape it with something else, but that doesn't fix
> the real problem.
>
> I assume the problem is with the url?
> But I don't know whether this should be fixed by turning
> " into &quot before giving it to the browser or if the problem
> is elsewhere?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:10 a.m.
Adrian Brock wrote:
1) Webservices
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE
Currently the ordering of these is pretty weak.
i.e. there is no guarantee the PRE will run before the POST,
except that the relative order of PRE is -1 compared with Tomcat
and the POST must run after Tomcat.
This is very brittle to changes in the Tomcat Deployer which
might move it earlier in the chain due to changes in its requirements.
i.e. The TomcatDeployer takes some additional metadata beyond
JBossWebMetaData.
Shouldn't the PRE deployer also output JBossWebMetaData
to show it modifies or process it and therefore MUST run before Tomcat?
https://jira.jboss.org/jira/browse/JBWS-2336
I'll look at this soon, btw the WebServiceDeployerPreJSE currently also
has JBossWebMetaData as its input.
I agree the ordering is weak here.
Cheers
Alessio
12:28 p.m.
New subject: PersistenceDeployer WAS Re: Deployment chains
On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
5+) There could be others. Like I said this is just a quick scan.
5) JPA Deployer
The PersistenceDeployer needs to specify that its output is
PersistenceUnitMetaData.
That is unless we change or extend the DeploymentVisitor
interface to let it specify an optional output and do it automatically
in setDeploymentVisitor().
But more importantly...
I don't understand why this isn't setting the ComponentVisitor
which would do that without you having to think about it?
It is commented out, so some problem must have been encountered?
public PersistenceDeployer()
{
//setComponentVisitor(new PersistenceUnitDeploymentVisitor());
setDeploymentVisitor(new PersistenceDeploymentVisitor());
}
Instead there is a class in the jpa project called
AbstractDeploymentVisitor which looks like it should be
in the deployer project and really called
AbstractComponentVisitor?
Finally, shouldn't there be a way for somebody to create
a PersistenceUnitDeployment that doesn't come from
a PersistenceDeployment?
i.e. like you can create a ServiceMetaData or BeanMetaData
from any other deployer.
Currently this can only be done if you wrap it in a
PersistenceDeployment which looks incredibly ugly to me
and certainly isn't compatible with the Profile Service
persisting overrides to it somewhere.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12:37 p.m.
New subject: PersistenceDeployer WAS Re: Deployment chains
On Fri, 2008-10-03 at 19:28 +0200, Adrian Brock wrote:
Currently this can only be done if you wrap it in a
PersistenceDeployment which looks incredibly ugly to me
and certainly isn't compatible with the Profile Service
persisting overrides to it somewhere.
Oops, you can tell its late on Friday.
I'm getting confused between PersistenceDeployment
and PersistenceMetaData :-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:11 a.m.
New subject: PersistenceDeployer WAS Re: Deployment chains
Adrian Brock wrote:
On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
> 5+) There could be others. Like I said this is just a quick scan.
>
5) JPA Deployer
The PersistenceDeployer needs to specify that its output is
PersistenceUnitMetaData.
That is unless we change or extend the DeploymentVisitor
interface to let it specify an optional output and do it automatically
in setDeploymentVisitor().
But more importantly...
I don't understand why this isn't setting the ComponentVisitor
which would do that without you having to think about it?
That because I don't understand why we should set one. :-)
What is AbstractComponentDeployer?
For the EJB3 Embeddable deployers I've switched back to
AbstractRealDeployerWithInput.
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/m...
What I don't want to see (yet) is having both the module deployer and
component deployer in one class. That maybe a nice optimization, but I
first want to know what's going on.
It is commented out, so some problem must have been encountered?
I couldn't get the ComponentVisitor to fire off in any test scenario, so
I commented it. :-P
public PersistenceDeployer()
{
//setComponentVisitor(new PersistenceUnitDeploymentVisitor());
setDeploymentVisitor(new PersistenceDeploymentVisitor());
}
Instead there is a class in the jpa project called
AbstractDeploymentVisitor which looks like it should be
in the deployer project and really called
AbstractComponentVisitor?
Yes, that was the plan. This is the precursor for that class. I dropped
the ball there.
And no, it's an AbstractDeploymentVisitor because it's an implementation
on DeploymentVisitor meant for setDeploymentVisitor. The fact that
setComponentVisitor takes the 'same' thing is another mind boggler to
me. If we're doing an AbstractComponentVisitor it shouldn't have
getComponents, but getComponent.
Finally, shouldn't there be a way for somebody to create
a PersistenceUnitDeployment that doesn't come from
a PersistenceDeployment?
i.e. like you can create a ServiceMetaData or BeanMetaData
from any other deployer.
Currently this can only be done if you wrap it in a
PersistenceDeployment which looks incredibly ugly to me
and certainly isn't compatible with the Profile Service
persisting overrides to it somewhere.
I don't see why there should be a way, but I'm as creative as a piece of
rock. ;-)
There shouldn't be any problem to have that function. Scoping needs to
be taken into account. And maybe the resolver needs a change.
So correct me if I'm wrong: the AbstractComponentDeployer creates the MC
component and stuffs the component meta data into it. Then the
PersistenceUnitDeployer still creates the JavaEE component? (I feel a
javadoc moment coming. :-) )
Carlo
9:41 a.m.
New subject: ComponentVisitor was Re: PersistenceDeployer WAS Re: Deployment chains
On Mon, 2008-10-06 at 09:11 +0200, Carlo de Wolf wrote:
> I don't understand why this isn't setting the
ComponentVisitor
> which would do that without you having to think about it?
>
That because I don't understand why we should set one. :-)
What is AbstractComponentDeployer?
A deployer so you only have to write the component visitor. :-)
> Instead there is a class in the jpa project called
> AbstractDeploymentVisitor which looks like it should be
> in the deployer project and really called
> AbstractComponentVisitor?
>
Yes, that was the plan. This is the precursor for that class. I dropped
the ball there.
Ok. I should have provided an AbstractComponentVisitor in the
initial work, instead you've created one so it just needs moving
into the deployers project.
And no, it's an AbstractDeploymentVisitor because it's an
implementation
on DeploymentVisitor meant for setDeploymentVisitor. The fact that
setComponentVisitor takes the 'same' thing is another mind boggler to
me. If we're doing an AbstractComponentVisitor it shouldn't have
getComponents, but getComponent.
The setComponentVisitor() initialises the AbstractComponentDeployer
from the DeploymentVisitor metadata so you don't have
to repeat yourself. ;-)
A component visitor (there's no such interface)
is just a deployment visitor that creates components.
And for those that don't know, a deployment visitor is used
when you want to look at all attachments and do work
that is atomic. i.e. it will automatically invoke
you to unwind what you previously did if you throw an error
part way through deploy().
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
1:22 p.m.
Adrian Brock wrote:
4) WEB CLUSTERING
org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer
I don't know what this is doing in Describe since it is not
establing a deployment dependency. Instead it is modifying the
JBossWebMetaData.
I'd guess this should be after the merge of annotations into that
metadata? Although I don't think there is such an annotation
currently? :-)
No, there's not, and I'm not sure what someone would annotate as this
metadata applies to the webapp overall. :-)
For sure Describe is wrong. For a similar task with EJB2 beans
(Ejb2HAPartitionDependencyDeployer) I put it in PRE_DESCRIBE, whose
javadoc documents it as "The pre describe stage - where default
dependencies metadata can be created". For EJB3 it's in PRE_REAL, which
I didn't like, but the annotation merging wasn't done until
POST_CLASSLOADER. Seems like PRE_DESCRIBE is more appropriate for the
webapp case.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5693
days inactive
5698
days old
jboss-development@lists.jboss.org
34 comments
7 participants
participants (7)
-
Adrian Brock -
Ales Justin -
Alessio Soldano -
Brian Stansberry -
Carlo de Wolf -
Kabir Khan -
Scott Stark