September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

Yes, I guess that is the right approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088649#4088649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088649

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

"wolfc" wrote : | You can see that a Description annotation never even enters the picture. | Right. What is needed is an annotation scanning deployer that has a plugin maps a set of annotations onto the metadata instance that resulted from the parse phase. If its a pure annotation deployment it would create the metadata from the annotations. The steps should be: 1. annotation scanning deployer provides sets of annotations based on the types the plugins have defined. This is used to create the base metadata. 2. Parsing deployer would create the next level of metadata that delegates to the annotation based instance. "wolfc" wrote : | Secondly we use the class container as meta data repository, so we can do this: | <bind pointcut="execution(public * *->@javax.ejb.Remove(..))"> | | <interceptor-ref name="org.jboss.ejb3.stateful.StatefulRemoveFactory"/> | | </bind> | This should be metadata on the managed aspect mc bean. We talked with Kabir about this today. The stateful ejb3 container should have a number of beans for the aspects associated with a stateful container domain. "wolfc" wrote : | Another problem: we can't use the API annotations to express all meta data, because they're not conclusive. Not everything can be expressed in annotations. So I would rather have the unified meta data as the base, which is conclusive and un-ambiguous and some translator on top. So if you ask for getAnnotation(@Remove) it will look it up in the right meta data repository in the right meta data. I would say there should never be a lookup for an annotation, unless that is the proper metadata. The annotation should have been translated into the metadata by the annotation scanning deployer/annotation to metadata plugin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088648#4088648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088648

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"scott.stark(a)jboss.org" wrote : Its the ManagedProperty.getManagedObject().getAttachment() value, but DefaultFieldsImpl does not have access to this currently. | So what do you propose to do here? Should we push this attachment as another field value into Fields --> Fields.ATTACHMENT? Would this work? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088646#4088646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088646

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

Yes. The problem I see with the metadata update is that the Fields api does no t explicitly provide access to the metadata instance. For the case of the AbstractManagedObjectFactory we are pushing the PropertyInfo as the Fields.PROPERTY_INFO, but the instance to which the property applies is not available. Its the ManagedProperty.getManagedObject().getAttachment() value, but DefaultFieldsImpl does not have access to this currently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088645#4088645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088645

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

Eh ... you beat me to it ... just about to post this. :-) So we want to update both at the same time: metadata value + runtime component. Will see what I can do with the proxy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088644#4088644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088644

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

"alesj" wrote : | But PS need something like MetaDataNameProvider to get the actual runtime component name. | Yes, I don't see that the RuntimeComponentDispatcher should be in the mc. Its ps integration code. "alesj" wrote : | So you want to change this: | | | ctxProp.setValue((Serializable)prop.getValue()); | | | with the actual runtime invocation - via KernelBus? | No, we need an aspect that applies to setValue and: 1. writes the value back to the metada instance 2. forwards the value to the KernelBus if its a runtime property. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088643#4088643 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088643

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

"alesj" wrote : | Changes metadata instance? How, where? | But there is no actual runtime component invocation at the moment, right? | The ManagedProperty Fields implementation needs an advice that catches the setValue call to write the update onto the metadata instance property the field is associated with. This would apply for javabean type of metadata. Other implementations could be specified for different metadata types. We are missing the setup of the Fields proxy. The fields creation in AbstractManagedObjectFactory needs to be using the org.jboss.managed.plugins.advice.WrapperAdvice.wrapFields utility to allow an advice to update the metadata instance on the setValue call. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088639#4088639 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088639

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"scott.stark(a)jboss.org" wrote : Where is the RuntimeComponentDispatcher, I don't see it in the mc trunk. | The RuntimeComponentDispatcher impl is in AS trunk. I can move it into MC, since all it's components are MC based. "scott.stark(a)jboss.org" wrote : Its not clear why the PS can't be doing the KernelBus invocation once it has the name and setter for the runtime property. | Sure. But PS need something like MetaDataNameProvider to get the actual runtime component name. So you want to change this: | ctxProp.setValue((Serializable)prop.getValue()); | with the actual runtime invocation - via KernelBus? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088638#4088638 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088638

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

"alesj" wrote : | The RuntimeComponentDispatcher will stay, it's the KernelBus that has changed. And by that our RuntimeComponentDispatcher impl has changed as well. | | I agree it should go into MVImpl, but what if we are deep into MC impl - which should be PS unaware? | Where is the RuntimeComponentDispatcher, I don't see it in the mc trunk. Its not clear why the PS can't be doing the KernelBus invocation once it has the name and setter for the runtime property. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088634#4088634 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088634

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"alesj" wrote : Weston, what's the status/progress of this? This is the point of our discussion - guess forum wiki ate it :-) "alesj" wrote : | Was this fixed? | Code: | | *** CONTEXTS IN ERROR: Name -> Error | | vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testHq | ldbDS-ds.xml -> org.xml.sax.SAXParseException: Premature end of file. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088632#4088632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088632

16 years, 7 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 September 2007