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

[Design of JBoss Web Services] - Re: JBossWS project structure has changed

by thomas.diesler＠jboss.com

Legacy branches and tags have been moved to | https://svn.jboss.org/repos/jbossws/legacy | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070711#4070711 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070711

16 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS project structure has changed

by thomas.diesler＠jboss.com

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by adrian＠jboss.org

The point I was trying to make before was that it probably be easier for the mangement layer to deal with a map, so an alternative markup might be to define on the collection: | @MangementObject | public class SecurityDeployment | { | // login-config.xml has many policies | @ManagedProperty(managed=true map-id="name" id-qualifier="SecurityDomain") | Collection<SecurityPolicy> getPolicies(); | } | Then the profile service when it does getProperty("policies") would get a TableMetaValue of String(id/name)->ManagedObject instead of having to iterate over an array of managed objects. It's still a Collection underneath, we've just exposed it as a map (since we know it has a unique id) for ease of use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070708#4070708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070708

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by adrian＠jboss.org

anonymous wrote : | Somewhere else there needs to be a type="SecurityDomain' managed object with a name that matches the SecMetaData.domain value. If the @ManagedObjectID(type="SecurityDomain") annotation is identifying the key space of the managed objects of type="SecurityDomain' then I follow. Otherwise I don't. | It is, but I put it on the policy not the deployment. The login-config.xml can have multiple policies. It is the policy that represents the security domain. All I'm saying is that where-ever it is, you just need to identify what the id of the ManagedObject is and its type/qualifier. >From above (but more explicit): | @MangementObject | public class SecurityDeployment | { | // login-config.xml has many policies | @ManagedProperty(managed=true) | Collection<SecurityPolicy> getPolicies(); | } | | @ManagedObject | public SecurityPolicyMetaData | { | // This is its id which has qualifier/type/discriminator "SecurityDomain" | @ManagedObjectID(type="SecurityDomain") | public String getName(); | } | So the profile service can look at the SecurityPolicyMetaData managed objects and see they are keyed by "SecurityDomain"/name and match that with what is on the connection manager metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070703#4070703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070703

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WriteThroughManagedPropertyImpl

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | I don't know what ManagementObejct.fieldsFactory is? | Are you talking about the annotation or something else? | Yes, its a field in the @ManagementProperty I added. "adrian(a)jboss.org" wrote : | It should be upto the caller (deployer or overrides) to decide how to generate the fields, | i.e. | 1) it is a flattened javabean tree | 2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans | 3) it is from an MBean definition | 4) it represents a XML DOM | 5) something else | etc. | Right, which is why I added the ability to describe what the Fields and ManagedProperty implementation are from the annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070702#4070702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070702

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding applyMetaData method to KernelControllerContext

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : "alesj" wrote : | | | After you add new MetaData, it needs to be 'visited', in order to plugin all those dependencies, callbacks, installs, ... | | | So the easiest way for me to do that was to use the existing MetaDataVisitor concept, and just twist it a bit to suite my need - not starting from BeanMetaData, but on newly added MetaDataVisitorNode + pushing BMD at the bottom of the stack before executing it. | | | | | Ok. But I'm not sure it needs to be this complicated? | | | Complicated? | This is what looked natural to me, to use existing visitor concept. | Since we are already in Describe state, executing both of them - initial and describe. No need for changing existing MetaData impl. | What would you do? | I don't know, but I'd try to find someway to avoid the isAlreadyDone() that is bound to lead to confusion (and most likely errors). The fundamental problem is that there are three points when we know that metadata could be introduced and that is really complete. 1) Initial install - we know the xml (really BeanMetaData) 2) PreInstall - for a simple bean - we know the class (and we know it exists) 3) Instantiate - for a bean from a factory - it is only here we know the class from object.getClass() I'd find someway to make the retrieval lazy such that steps 1 and 2 only look at the metadata they absolutely need to and step 3 does the all rest (most of it). e.g. You can't specify a classloader using an annotation | @ClassLoader(name="Whatever") | public class MyClass {} | because it couldn't load the class until the classloader exists so it could never read the annotation. That is an example of the MetaData that needs to be visited in step (1) and the dependency constructed. Others like property injection can be left to step 3 when we know we have access to the full picture, i.e. we don't use the annotation from the class if the xml/metadata has one. This is also related to something I discussed with Carlo about ejb annotations. The annotations in the xml are "instance scope" annotations, while the annotations on the class are "Class scope" annotations. Any "instance scope" annotation makes the "class scope" invisible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070696#4070696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070696

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by scott.stark＠jboss.org

I'm not following the example then as it does not match the existing jca metadata/managed object view. What exists logically is: | @ManagementObject | class DSDeployments | { | @ManagementObject | List<ConnMetaData> deployments(); | } | | @ManagementObject | class ConnMetaData | { | @ManagementProperty(name="jndi-name") | String getJndiName(); | | @ManagementProperty(name="security-domain", managed=true) | SecMetaData getSecMetaData(); | } | | @ManagementObject | class SecMetaData | { | @ManagementProperty | @ManagedObjectRef(type="SecurityDomain'); | String getDomain(); | } | Somewhere else there needs to be a type="SecurityDomain' managed object with a name that matches the SecMetaData.domain value. If the @ManagedObjectID(type="SecurityDomain") annotation is identifying the key space of the managed objects of type="SecurityDomain' then I follow. Otherwise I don't. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070691#4070691 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070691

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WriteThroughManagedPropertyImpl

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed. | I don't know what ManagementObejct.fieldsFactory is? Are you talking about the annotation or something else? It should be upto the caller (deployer or overrides) to decide how to generate the fields, i.e. 1) it is a flattened javabean tree 2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans 3) it is from an MBean definition 4) it represents a XML DOM 5) something else etc. The only one I'd implemented was (2) and then that wasn't complete, e.g. it didn't update the javabean in the setValue(). That is unless you count the crappy MockDomFields in the testsuite. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070689#4070689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070689

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding applyMetaData method to KernelControllerContext

by alesj

"adrian(a)jboss.org" wrote : "alesj" wrote : | | After you add new MetaData, it needs to be 'visited', in order to plugin all those dependencies, callbacks, installs, ... | | So the easiest way for me to do that was to use the existing MetaDataVisitor concept, and just twist it a bit to suite my need - not starting from BeanMetaData, but on newly added MetaDataVisitorNode + pushing BMD at the bottom of the stack before executing it. | | | Ok. But I'm not sure it needs to be this complicated? | Complicated? This is what looked natural to me, to use existing visitor concept. Since we are already in Describe state, executing both of them - initial and describe. No need for changing existing MetaData impl. What would you do? "adrian(a)jboss.org" wrote : | anonymous wrote : | | When we do a re-install on the controller context, do we need a new look at the annotations? | | | | Of course, the class could change. | Yup. Can you give a scenario how this would work and that the underlying controller context wouldn't be removed during that process? Probably if we remove the underlying Classloader, context gets unistalled - into PreInstall state - and then re-installed with new Classloader. Will that do? :-) "adrian(a)jboss.org" wrote : | Ok. So the code that didn't compile was just out-of-the-box factory settings | for bootstrapping? The JavaBeanAnnotationPlugin? I think the compiling problem was simply because I had some classes locally which my IDEA/SVN didn't 'noticed', so they weren't commited. Or which problem do you have in mind? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070686#4070686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070686

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WriteThroughManagedPropertyImpl

by scott.stark＠jboss.org

Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070685#4070685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070685

16 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2007