July 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by alesj

I guess we can keep registerDirectly, it's plain and simple. And we want to move people away from MBeans anyway ... go POJOs. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062113#4062113 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062113

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What is going on with aliases?

by alesj

I'll change the order of DeploymentAliasMetaDataDeployer by renaming it to AliasMetaDataDeployer. Not that it matters in state machine ;-), but I think it is less confusing. This way 2nd deployment will resolve the alias bean right away. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062110#4062110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062110

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Uniquely identifying services and actions

by tcunning

I'm interested in per-ESB Server/AS, we may be interested in globally later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062109#4062109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062109

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What is going on with aliases?

by alesj

"adrian(a)jboss.org" wrote : Looking at the code, I think this should also work to alias JMX contexts? | but it obviously needs testing. I think it should work. I'm just about to do more tests for JMX names. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062105#4062105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062105

18 years, 9 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J

by bstansberry＠jboss.com

Focus on AS trunk (i.e. 5.x). For now I want to very much restrict new feature development in Branch_4_2. Branch_4_0 is definitely bug-fix only. Suggest you start with a post on the JBoss Serialization forum to check the status of support for serializing non-Serializable classes; i.e. how stable, is it being actively maintained or developed, etc. From what I understand, in the more recent JDK 5 releases, standard JDK serialization has fixed the stuff that had made JBoss Serialization more performant. So, one reason for ongoing work on JBoss Serialization is gone. Before introducing a feature to JBoss AS that depends on a JBoss Serialization feature, I want to be sure that the JBS feature is stable for the long term. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062094#4062094 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062094

18 years, 9 months

1
0
0 / 0

[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

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Optional input for AbstractSimpleVFSRealDeployer

by wolfc

How can I tell an AbstractSimpleVFSRealDeployer (org.jboss.ejb3.deployers.AppClientScanningDeployer) that its input is optional? In this case there is no xml descriptor, so the AppClientParsingDeployer didn't create an attachement. But there are annotations, so the AppClientScanningDeployer should move. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062077#4062077 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062077

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007