[JBoss Microcontainer Development] - Re: ClassInfo::getAnnotations bug
by flavia.rainone@jboss.com
"Ales" wrote : The fix for Managed could be:
| * make @ManagementObject @Inherited
| * check the whole hierarchy
I think there is a misunderstanding here. You said you wanted ClassInfo.getAnnotations to return only the declared annotations. I followed the nomenclature used on JDK, that says that declared annotations excludes inherited annotations. So, the way it is implemented now, it doesn't matter if @ManagementObject is inherited or not, because getAnnotations method is ignoring the inherited annotations.
Before we changed the getAnnotations implementation, this method was returning exactly all the annotations of that particular class plus the inherited ones, as it was delegating to Class<?>.getAnnotations. This was being tested and that's why I had to change the tests to make them pass with the new implementation.
"Ales" wrote : I still prefer the way JDK does it. :-)
So maybe we should revert the changes and add a getDeclaredAnnotations method to AnnotatedInfo, similar to java.lang.reflect.AnnotatedElement interface?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261763#4261763
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261763
16 years, 5 months
[jBPM Development] - Re: feature suggestion: add a description for transitions
by sebastian.s
Hi Bernd, hi Koen
I don't want to start over old discussions again but since I missed it what was the outcome of this diskussion? Was this the on about the question if task names should be unique or not?
anonymous wrote :
| Hmm, why do you need that "technical short name" and don't just use the name as business name (meaning the longer description")?
|
| There is no real downside of it, or is it? Introducing a new attribute is not necessary here in my oppinion, but correct me if I am wrong or missing something.
|
>From my point of view transition names should help business users understand the process.
When coding and using for example taskService.completeTask(taskId, outcome) I somehow don't feel comfortable to use this long name even with spaces since transition names need to be unique for one task so they name is a kind of identifier or even a signal name to take this specific transition.
Furthermore to facilate development of clients using the engine I would like to use a a kind of convention for transition names. For example after tasks which implement a user's decision which path to take in the process I'd prefer to give the same names to the transitions in different processes but a process specific description or long name for the transition. I hope I was able to point out my aspects.
cheers
Sebastian
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261762#4261762
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261762
16 years, 5 months
[JBoss Microcontainer Development] - ClassInfo::getAnnotations bug
by alesj
While doing annotation scanning on top of Reflect,
I stumbled upon what seems to me an invalid impl of how we get annotations of the class.
ClassInfoImpl uses InheritableAnnotationHolder who's getAnnotations returns all annotations in the class hierarchy.
This way we cannot just get the annotations declared on the class,
making it look like all annotations are marked as @Inherited.
In my case AnnotationRepository was picking up class which wasn't annotated, but its super class was.
Flavia and me fixed this by introducing a notion of getDeclaredAnnotations on InheritableAnnotationHolder,
which is then used by ClassInfoImpl.
But this leads to another problem. :-(
While testing Deployers, ManagedObjectClassLoadingParserUnitTestCase was failing for me.
This is due to the fact that Managed is trying to create ManagedObject
while looking for @ManagementObject on the attachment's class.
In this case the attachment is of ClassLoadingMetaData10,
where @ManagementObject is on its superclass, ClassLoadingMetaData.
With the current Reflection fix AbstractManagedObjectFactory::getAnnotation only checks top class,
not the whole hierarchy as before.
The fix for Managed could be:
* make @ManagementObject @Inherited
* check the whole hierarchy
But this seems more generic problem as just Managed.
I guess only change to Reflect 2.2.x will expose them all.
Or, is there actually a reason behind why we returned all annotations?
If there is one, how did we expect to just get class's annotations?
e.g. clazz::getAnnotations - clazz.getSuperclass.getAnnotations
I still prefer the way JDK does it. :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261751#4261751
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261751
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - AS weld-int
by kabir.khan@jboss.com
I'm looking at the as weld-int project how to integrate the work I have done on MC's weld-int.
Here's an outline of what I believe I have to do
== 1 - Initialize Weld =====
This is done by BootstrapBean.initialize(). The BeanMetaData for BootstrapBean is created by WeldBootstrapDeployer, and deployed by BeanMetaDataDeployer.
== 2 - Deploy the MC beans using WeldKernelControllerContext so that we can have Weld->MC injection, and also be pushed to weld for MC->Weld injection =====
a) I need the BeanManager. BootstrapBean is initialised, so I can call BB.getWeldManager(). I do however need access to the bean manager to use, which I can get from the (Flat)Deployment attachment. I do see some issues down the line if a deployment has several bean managers, but want to get something up and running before digging into that.
b) How do I make sure that WeldKernelControllerContexts are deployed instead of KernelControllerContexts? Replace BeanMetaDataDeployer with something else?
== 3 - Deploy Weld beans =====
This is done by BootstrapBean.boot() which is called as part of BootstrapBean's start phase. I need to make sure this happens after 2), which looks like it is the case in BootDeployerTestCase, due to some mysterious dependency on EjbContainer#1 (line 79)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261739#4261739
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261739
16 years, 5 months