-
1. Re: annotation plugin - mismatch
alesj Feb 12, 2009 11:54 AM (in response to obrien)I don't see what you are trying to do?
Or what exactly doesn't work? -
2. Re: annotation plugin - mismatch
obrien Feb 12, 2009 1:21 PM (in response to obrien)I'm trying to implement annotation plugin for custom annotation, exactly as described in ALR's blog post. In this case I've got demo object Library with field 'xyz' annotated and I'm expecting the plugin to inject correct value/object (custom logic).
plugin1 - is annotation plugin
library - is target object
everything works, except annotation plugin is never activated. What I'm not sure about is MetaDataAnnotationAdapter. I see callback addAnnotationPlugin successfully invoked, but when Microcontainer tries to install my bean 'library' my annotation adapter is never called to handle it, therefore there's no injection of custom object/value. -
3. Re: annotation plugin - mismatch
obrien Feb 12, 2009 1:25 PM (in response to obrien)This is just demonstration, in my project I need to inject proxy to remote object (non-EJB). I followed implementation of @EJB injection to MC beans, but can't see why it doesn't work.
Doesn't work = no injection is being done, because Annotation Adapter used for it is different from the one with my annotation plugin. -
4. Re: annotation plugin - mismatch
alesj Feb 12, 2009 4:48 PM (in response to obrien)"obrien" wrote:
<bean name="BMDAdapter" class="org.jboss.kernel.plugins.annotations.AbstractMetaDataAnnotationAdapter" access-mode="ALL"> <incallback method="addAnnotationPlugin"/> <uncallback method="removeAnnotationPlugin"/> </bean>
You didn't "copy" ALR's code well enough. ;-)
Your BeanAnnotationAdapter is not a singleton.
See
* BeanAnnotationAdapterFactory
* AnnotationsAction -
5. Re: annotation plugin - mismatch
obrien Feb 12, 2009 6:45 PM (in response to obrien)"alesj" wrote:
You didn't "copy" ALR's code well enough. ;-)
Your BeanAnnotationAdapter is not a singleton.
See
* BeanAnnotationAdapterFactory
* AnnotationsAction
sorry, I changed it last night when I couldn't figure out what's wrong. So this is now fixedBeanAnnotationAdapter beanAnnotationAdapter = BeanAnnotationAdapterFactory.getInstance().getBeanAnnotationAdapter(); String beanAnnotationAdapterBindName = "MyBeanAnnotationAdapter"; BeanMetaDataBuilder bmdb = BeanMetaDataBuilder.createBuilder(beanAnnotationAdapterBindName, beanAnnotationAdapter.getClass().getName()); bmdb.addMethodInstallCallback("addAnnotationPlugin"); bmdb.addMethodUninstallCallback("removeAnnotationPlugin"); //bmdb.setAccessMode(BeanAccessMode.FIELDS); kernel.getController().install(bmdb.getBeanMetaData(), beanAnnotationAdapter);
but to get FieldAnnotationPlugin to work, I had to delete/comment out setter in my class, like:public class Library { @DoSomething private String name; public Library() { } public String getName() { return name; } /* public void setName(String name) { this.name = name; } */ }
Digging down to the code, I've found couple things I don't understand:
- when 'access-mode=FIELDS' then field filter is set only to IsPublicFieldFilter, and the 'name' wouldn't get handled
- when 'access-mode=ALL' field filter is AllFieldFilter, but then within FieldBeanInfo.setProperties property precedes and it seems like FieldAnnotationPlugin is not used, unless setter property is not present. What annotation plugin I have to extend?
Is this correct behaviour? And if it is, can you point me in the right direction where to look for explanation why? -
6. Re: annotation plugin - mismatch
alesj Feb 13, 2009 5:41 AM (in response to obrien)"obrien" wrote:
but to get FieldAnnotationPlugin to work, I had to delete/comment out setter in my class, like:
Yes, it's the same issue ALR had."obrien" wrote:
Is this correct behaviour? And if it is, can you point me in the right direction where to look for explanation why?
This is expected.
Where?
Some MC dev forum post - hard to find with this crappy forum software.
Why?
If there is a public setter it should be used.
As this keeps the bean/pojo integrity less hackish.
What can be done?
It's very trivial to extend BeanAccessMode.
See its Creator interface.
So, if there are very legit reasons to do so, I'm wiling to listen. ;-) -
7. Re: annotation plugin - mismatch
obrien Feb 13, 2009 6:19 AM (in response to obrien)"alesj" wrote:
Where?
Some MC dev forum post - hard to find with this crappy forum software.
Why?
If there is a public setter it should be used.
As this keeps the bean/pojo integrity less hackish.
What can be done?
It's very trivial to extend BeanAccessMode.
See its Creator interface.
So, if there are very legit reasons to do so, I'm wiling to listen. ;-)
got it now, followed your @Inject and created different plugins. I can live the default bean access mode behaviour, but it was unexpected - considering experience with other annotation based frameworks. -
8. Re: annotation plugin - mismatch
alesj Feb 13, 2009 6:26 AM (in response to obrien)"obrien" wrote:
but it was unexpected - considering experience with other annotation based frameworks.
Yup.
Most of them are keen on doing complete lookup - private fields, ...
Which imho breaks the pojo encapsulation,
hence we only use that as a last resort.
If this really turns out to be a common use case, we could easily add it.
But I rather see "clean" pojo interaction - java beans style. :-) -
9. Re: annotation plugin - mismatch
obrien Feb 13, 2009 6:59 AM (in response to obrien)I should be pushing my integration concept to wider development team soon, so will let you know how people cope with it.
-
10. Re: annotation plugin - mismatch
obrien Feb 13, 2009 8:23 AM (in response to obrien)All this leads me to the question if there's any global/deployment configuration to specify Bean Access Mode? XML descriptor or pragmatically?
it comes again to the scope configuration as discussed before. -
11. Re: annotation plugin - mismatch
alesj Feb 13, 2009 8:29 AM (in response to obrien)No, it's currently per bean.
I can push it into deployment element,
afterward inherited by all beans.