[Design the new POJO MicroContainer] - Re: Field signature usage
by adrian＠jboss.org
"alesj" wrote : When doing annotation lookup on fields in AbstractBeanAnnotationAdapter there are two ways of doing that.
|
| 1) The same way as I'm doing it now via propertys
| This is possible since fields are now 'propertys'.
| But would require Signature abstraction on PropertyInfo.
|
Why? What are you talking about?
BeanInfo/Reflection is not based on the metadata repository. It is the other way around.
anonymous wrote :
| 2) Doing normal fields inspection
| This would require a change to AnnotatedElementMetaDataLoader, since currently only public fields are supported.
| Dealing with possible duplicates, e.g. existing only setter + FIELDS|ALL mode
|
If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137036#4137036
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137036
18 years
[Design of JBoss jBPM] - Re: LDAP assignment handler
by tom.baeyens＠jboss.com
if i understand you correctly, you would want to introduce an IdentityService session facade between the expression assignment handler and the identity component.
that way, people would just have to implement the identity service session facade instead of the assignment handler and the link to their own identity component.
right ?
here's why i'm in doubt:
* to make it pluggable for LDAP as well, all the relations would have to be navigated over the session facade as well. that on itself is not a big deal, but it breaks a bit the simplicity that we get by systematically using the hibernate persistence architecture.
in this case we would not be able to use object navigation and hibernate's the lazy loading, but instead we would have to invoke e.g. the getGroupsForUser(userId, groupType) on the session facade.
* secondly not all identity components have a model that is exposable as the model that we assume when building the session facade interface. so in some cases it would work and in some cases the models are too far apart.
* we would need to document which methods are used by which features. as users probably don't have to implement all of the methods in the session facade. e.g. suppose that a user only uses the email functionality, which needs userid-to-email-resolving. then this user might find himself implementing all the methods used by the assignment expression handler that he might not even use.
i see pros and cons. not yet a clear direction that we should take. more input is welcome.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137005#4137005
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137005
18 years