[Design the new POJO MicroContainer] - Re: What is going on with aliases?
by alesj
"adrian(a)jboss.org" wrote : Ok, I see what you are doing.
| Each alias is associated with a name
|
|
| | <deployment xmlns="urn:jboss:bean-deployer:2.0">
| | <alias name="Test">MyAlias</alias>
| | </deployment>
| |
|
| So you're saying I want to alias the context "Test" with the new name "MyAlias".
| And this is a seperate deployment to where "Test" is defined.
|
Yup.
This is the point.
e.g. you have a deployment which already uses a lot of different names for the bean you have defined earlier.
You simply add a deployment alias.
"adrian(a)jboss.org" wrote :
| It's an interesting idea. But if this really is the solution then it needs some
| kind of marker in the component to say it is "NOT REAL", otherwise other
| stuff built on the deployers like what I'm going to do with the metadata
| repository and jsr77 or what the profile service is doing
| is going to get very confused. :-)
:-)
Do we have this kind of marker?
Or better, how/where do I add it? ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062104#4062104
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062104
19 years
[Design the new POJO MicroContainer] - Re: What is going on with aliases?
by alesj
"adrian(a)jboss.org" wrote :
| None of this makes any sense to me. I don't remember you discussing
| any of these changes?
|
| The order of the aliases cannot matter and you can't have an alias more than once.
| So why a List when a Set describes exactly what is required.
|
I agree, I'll put the Set back.
Though I'll need a list, but I don't.
"adrian(a)jboss.org" wrote :
| Also what does it mean for a deployment rather than a bean to have an alias?
| Is this a Spring thing?
|
Yup, this was originally taken from Spring.
But I think they have a full implementation - the one mentioned on the JIRA. Which I think we initially don't need .
"adrian(a)jboss.org" wrote :
| As far as I can tell, your DeploymentAliasMetaDataDeployer is just going to fail
| when a deployment has more than one bean in it.
| You will try to apply the alias names to all the beans in the deployment.
| Only one of the beans can have an alias. It must be unique!
|
| Also, the component deployer was not intended for this kind of thing.
|
| The idea of a component is to represent a part of a deployment,
| e.g. a single ejb in an ejb jar or single bean in a -beans.xml
| soon I will be using the components to assign scopes for the MetaDataRepository
| where instance=component-name
| This kind of hack is just going to confuse things.
| There should be only one scope not a scope for every alias.
|
I don't understand this.
How else do you think to deploy this, if not as a component?
Or is this not relevant anymore due to next posts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062100#4062100
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062100
19 years
[Design of POJO Server] - Re: @JMX aspect and aop/mc integration
by bstansberry＠jboss.com
Hmm. Seems AUTO is not totally trivial. It's easy to validate whether a given class is either a DynamicMBean or meets the standard mbean naming rules.
But, @JMX has a required exposedInterface attribute. So, we have to validate that the bean is a valid mbean with respect to the given interface. Simple enough for the standard mbean check, but if the bean is a DynamicMBean, that basically means examining all the methods in the exposedInterface and checking the bean's MBeanInfo to confirm that there is a matching attribute or operation.
Doable, but involves a fair amount of code and a lot of testing. So, back to the original question: Do we still want to do the AUTO/STRICT/NONE approach? The advantage versus the existing registerDirectly is a small ease of use benefit whereby users don't have to add registerDirectly=true to their annotation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062098#4062098
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062098
19 years
[Deployers on JBoss (Deployers/JBoss)] - Re: Optional input for AbstractSimpleVFSRealDeployer
by adrian＠jboss.org
The real answer is that the annotations should be parsed to create an
ApplicationClientDD before hitting your deployer.
You're going to need something like eventually so you can create
a ManagedObject for the profile service to use.
The longer answer is that you can't do that with the AbstractSimpleVFSRealDeployer.
You'll have to write an AbstractMoreComplicatedVFSRealDeployer :-)
What you are really asking for is something that does
setInputs(ApplicationClientDD.class) (optional input) instead of setInput(ApplicationClientDD.class) a requirement.
But then you'll have to be careful about the "deployment" being null
and this code in AbstractSimpleRealDeployer
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| T deployment = unit.getAttachment(getInput());
| if (deployment != null)
| {
| // Set the deployer type
| unit.getTypes().add(getType());
| deploy(unit, deployment);
| }
| }
|
You don't want the deployment unit getting tagged as an appclient if it is not! :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062084#4062084
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062084
19 years