In general this kind of problem is a cross cutting concern.
We have some tree of metadata that needs processing by a deployer aspect,
but only some parts of the metadata are relevent to it.
This is usually done by a vistor pattern.
But as we know, patterns are best implemented with aspects.
1)
Right, security and logging are aspects which should be applied to the
deployment stack, not actually be deployers themselves.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864398#3864398
Reply to the post :
This is the common behavior mode when there is aggregation:
anonymous wrote :
| The use case I can think of where coupling of metadata is required is when
the classloader metadata is constructed. Each subdeployment can add metadata
(urls) to the top level metadata that creates the
Dimitris wrote :
| Lets say we have:
|
| a.bean
| |-b.bean
| |-c.jar
|
| And just 3 deployers, registered in that priority order:
|
| (C)lassLoadingDeployer - (B)eanDeployer - (J)ARDeployer.
|
| After the deployment structure is analyzed (by the bean jar deployers)
The second stage deployers still need to ordered, but it may not be the
same order as the structural orders.
The difference is that ALL second stage deployers get to process the deployment.
The second stage deployers create the BeanMetaData and (un)install it to the
kernel.
They DO NOT create
It would not be a good idea to have the deployers know their own next
since the list can be potentially built and ordered dynamically.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3863401#3863401
Reply to the post :
The points you mention are clear more less, i.e. deployers don't know their
next, they all process the deployment after the structure has been identified
and they don't instantiate objects directly. Their order is decided at
registration time.
What I'm trying to understant is, when having a
I couldn't give you an answer to this without looking at use cases.
I would certainly stick to the current rules (deepest first).
My gut fealing is that you pass each deployment/subdeployment
individually down the chain. i.e. assume each deployment is independent.
PRO: We don't want
Add some tasks for the deployer framework:
http://jira.jboss.com/jira/browse/JBMICROCONT-5
http://jira.jboss.com/jira/browse/JBMICROCONT-6
http://jira.jboss.com/jira/browse/JBMICROCONT-7
http://jira.jboss.com/jira/browse/JBMICROCONT-8
http://jira.jboss.com/jira/browse/JBMICROCONT-9
