[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
18 years, 9 months
[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
18 years, 9 months
[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
18 years, 9 months
[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
18 years, 9 months