October 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] - Re: ClassInfo::getAnnotations bug

by alesj

Forget about this post. :-) Looks like there was several oversights from my side. * @ManagementObject is already @Inherited. * gave bad instructions to Flavia * probably my Deployers failing test was a result of some bug in my mc-ann code. I guess we could introduce declared annotations, but since this only differs for classes, in that case one can use my set intersection suggestion. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261785#4261785 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261785

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Optimizing ControllerState

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : The whole point is that you're supposed to be able to add/interpolate new states. | You might as well just make it an enum if you're going to add an ordinal to the state | (especially if they are sequential ;-) | Ales's suggestion actually handles addition of states, although in different controllers states could be different. E.g. In Controller 1 State-A should be before State-B, and in Controller 2 State-B should be before State-A View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261771#4261771 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261771

16 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Cleanup path for Structure Deployers

by alesj

"david.lloyd(a)jboss.com" wrote : | Hoping this makes sense. | I would actually have to see this "in action" to really understand it. Or I'll do a few re-reads in the evening. :-) Thinking about how to hack this non-automount approach. ;-) e.g. Lets say we just have component deployers (probably not gonna happen, but still ...), no parsing stuff, nothing that would need to touch resources, hence no VFS usage. But we have a bunch of pre-attached component metadatas, meaning those component deployers would pick this up and deploy it. And one of our services at runtime calls URL.inputStream on a location that is sure it exists, but as an inner resource (double nested jar entry). What would happen in this case or how you make sure this is mounted and unmounted? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261756#4261756 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261756

16 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss Web Development] - HTTPOnly

by suminda

Hi All, Im new to Jboss and need help from you experts please. Does anyone know if Jboss support HTTPOnly cookie attribute? If so, on what versions? and how to you enable it? Hope im not asking too much Many thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261738#4261738 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261738

16 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: feature suggestion: add a description for transitions

by koen.aers＠jboss.com

Are we back in the 'id' versus 'name' discussion? ;-) Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261731#4261731 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261731

16 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: interested in contributing ?

by koen.aers＠jboss.com

Ah I have 2 more months to finish the documentation then... :-)) The support for it is currently in the build already so it will be in 4.2. It just needs to be documented and it probably will change a bit here and there based on you guys' feedback because I have no clear view on all the use cases. Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261729#4261729 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261729

16 years, 5 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 October 2009