This content has been marked as final.
Show 43 replies
-
1. Re: Field injection
kabirkhan Mar 11, 2008 11:19 AM (in response to alesj)"alesj" wrote:
Or what's the difference between invoking method vs. field via reflection on the AOP proxy?
The proxy is a subclass of the class AND contains a reference to the wrapped object.
Calling a method on the proxy delegates to a method in the wrapped object.
Setting a field on the proxy does not get reflected in the wrapped object, and setting a field in the wrapped object does not get reflected in the proxy since the proxy and the wrapped object are different instances. -
2. Re: Field injection
alesj Mar 11, 2008 11:41 AM (in response to alesj)"kabir.khan@jboss.com" wrote:
The proxy is a subclass of the class AND contains a reference to the wrapped object.
Calling a method on the proxy delegates to a method in the wrapped object.
Setting a field on the proxy does not get reflected in the wrapped object, and setting a field in the wrapped object does not get reflected in the proxy since the proxy and the wrapped object are different instances.
We can detect if the target is plain pojo (probably trivial via some AOP specific interface check) or if it's aspectized but woven (this probably also already exists), else throwing an error saying user cannot do field injection. -
3. Re: Field injection
kabirkhan Mar 11, 2008 11:51 AM (in response to alesj)if (o instanceof org.jboss.aop.proxy.container.AspectManaged) { //It is a proxy } else if (o instanceof org.jboss.aop.Advised) { //It is woven } else { //Plain class }
-
4. Re: Field injection
adrian.brock Mar 12, 2008 9:21 AM (in response to alesj)"alesj" wrote:
Scott is working on the EJBs where field injection is heavily used, and he needs this asap. :-)
From the distance it looks very similar to what we have with propertys.
e.g.<bean name="mybean" class="org.jboss.acme.MyBean"> <field name="somefield"><inject bean="somebean"/></field> <field name="mynumber" class="java.lang.Long">123456789</field> </bean>
NO!!!!!! Do NOT add a field element to the bean metadata.
if you want to do field injection then these should be included in
the BeanInfo abstract as properties.
i.e. the property has the same name as the field and the
get/set operations work on the field joinpoints.
But only if the property has no relevant getter/setter.
I'd suggest that field injection should be enabled explicitly
by specifying some sort of access rule on the bean element/BeanMetaData
like JAXB does.
http://java.sun.com/javaee/5/docs/api/javax/xml/bind/annotation/XmlAccessType.html -
5. Re: Field injection
alesj Mar 12, 2008 9:25 AM (in response to alesj)"adrian@jboss.org" wrote:
NO!!!!!! Do NOT add a field element to the bean metadata.
This is one hellova clear no. :-) -
-
7. Re: Field injection
alesj Mar 13, 2008 8:25 AM (in response to alesj)"kabir.khan@jboss.com" wrote:
if (o instanceof org.jboss.aop.proxy.container.AspectManaged) { //It is a proxy } else if (o instanceof org.jboss.aop.Advised) { //It is woven } else { //Plain class }
Do we need such a check?
e.g. JoinpointFactory// perhaps name param is too much boolean isFieldAccesible(Object target, String name);
Where AOPJpF would do the above mentioned check, and BasicJpF just returned true.
Since relying on ClassInfo.getDeclaredField to do the trick would mean that we would have to do it for the proxy's classinfo.
And since usually EJBs have their fields private, but still want the injection.
I guess we wont be able to do it w/o Field.setAccessible(true)? -
8. Re: Field injection
alesj Mar 13, 2008 11:07 AM (in response to alesj)"alesj" wrote:
I guess we wont be able to do it w/o Field.setAccessible(true)?
Should we introduce setAccessible(boolean) to FieldInfo, MethodInfo, ConstructorInfo?
Does Javassist have something equivalent? -
9. Re: Field injection
adrian.brock Mar 13, 2008 11:18 AM (in response to alesj)"alesj" wrote:
"alesj" wrote:
I guess we wont be able to do it w/o Field.setAccessible(true)?
Should we introduce setAccessible(boolean) to FieldInfo, MethodInfo, ConstructorInfo?
No because the objects are shared unlike the normal reflection objects.
This makes them more efficient in terms of memory and construction.
That is one of the reasons why the reflect classes were created in the first place.Does Javassist have something equivalent?
Do you even read the JIRA issues assigned to you? :-) -
10. Re: Field injection
alesj Mar 13, 2008 11:32 AM (in response to alesj)"adrian@jboss.org" wrote:
Do you even read the JIRA issues assigned to you? :-)
No, I have you to remind me of them. :-)
- http://jira.jboss.com/jira/browse/JBREFLECT-2
You did the issue moving just recently, and now you're showing off. :-)
But yeah, I need to clean some of my JBREFLECT issues.
Constantly putting them to the back of my mind."adrian@jboss.org" wrote:
No because the objects are shared unlike the normal reflection objects.
So, even after this JBREFLECT-2 is done, it wont be possible to create that method on the spi interfaces?
Or what would resolved JBREFLECT-2 issue do? -
11. Re: Field injection
alesj Mar 13, 2008 11:41 AM (in response to alesj)"adrian@jboss.org" wrote:
i.e. the property has the same name as the field and the
get/set operations work on the field joinpoints.
But only if the property has no relevant getter/setter.
How should we pass in the 'AccessType' info/param to this?
e.g.
I only allow strict property access, so I don't want the BeanInfo abstract to failover to fields on not found property.
And another access issue.
Should I allow mixing the usage of properties and fields with JBMICROCONT-220? -
12. Re: Field injection
adrian.brock Mar 13, 2008 11:46 AM (in response to alesj)You should setAccessible(true) by default for non-public stuff.
Then if the somebody invokes on it you do the permission check
if a security manager is installed.private static Permission accessCheck = new ReflectPermission("suppressAccessChecks"); if (notPublic) { SecurityManager sm = System.getSecurityManager(); if (sm != null) sm.checkPermission(accessCheck); }
JBREFLECT-2 is just finding a portable way to do what setAccesible(true) does
across JVMs for the javassist generated "reflection" objects (which are
more efficient than the JDK classes). -
13. Re: Field injection
adrian.brock Mar 13, 2008 11:56 AM (in response to alesj)"alesj" wrote:
"adrian@jboss.org" wrote:
i.e. the property has the same name as the field and the
get/set operations work on the field joinpoints.
But only if the property has no relevant getter/setter.
How should we pass in the 'AccessType' info/param to this?
e.g.
I only allow strict property access, so I don't want the BeanInfo abstract to failover to fields on not found property.
And another access issue.
Should I allow mixing the usage of properties and fields with JBMICROCONT-220?
It's just a case of extending the BeanInfoFactory abstraction to add an enum or something
which is configured as an attribute on our BeanMetaData.// Old method for backwards compatibility public BeanInfo getBeanInfo(Class<?> clazz) { return getBeanInfo(clazz, BeanModel.STANDARD); } public BeanInfo getBeanInfo(Class<?> clazz, BeanMode mode) { // Cache different versions based on the enum } public enum BeanMode { STANDARD, // Getters and Setters FIELDS, // Getters/Setters and fields without getters and setters ALL // As above but with non public fields included, }
The rest is just implementation detail.
One possible implementation would be to create a lightweight "filter"
BeanInfo impl over the ALL model for the other models? -
14. Re: Field injection
alesj Mar 13, 2008 12:01 PM (in response to alesj)"adrian@jboss.org" wrote:
One possible implementation would be to create a lightweight "filter"
BeanInfo impl over the ALL model for the other models?
Hmmm ... this sounds interesting approach.
I'll go in this direction and see where it leads.