JBossDeveloper

"alesj" wrote:
A first hurdle.

How to get past this usage in PropertyDispatchWrapper (kernel module):

 PropertyInfo propertyInfo = BeanInfoUtil.getPropertyInfo(beanInfo, target, name);
 ValueMetaData valueMetaData = property.getValue();
 Object value = valueMetaData.getValue(propertyInfo.getType(), cl);
 beanInfo.setProperty(target, name, value);

Since I need the expected type of the value in order to convert it to the right type, e.g. string --> Date.

But what if my bean is in FIELD or ALL mode, and there is no such property?

Anything that comes to my mind in api extension to get the type by name from BeanInfo feels wrong. :-)

public class MyClass
{
 private Date myDate;
}

"adrian@jboss.org" wrote:

FieldInfo field; (there is no getter/setter)

// Readable?
if (property.getGetter() != null)

"alesj" wrote:

Or you could be psychic. :-)

"alesj" wrote:

"adrian@jboss.org" wrote:

This should have a BeanInfo with one property which is a FieldPropertyInfo

What about if the bean is in ALL or FIELDS mode and the property has just setter or just getter?
OK, there should be some kind of CombinedPropertyInfo.

The real question is, should I also replace the existing AbstractPropertyInfo in AbstractBeanInfo.properties or just in AbstractBeanInfo.propertiesByName?

public abstract class AbstractPropertyInfo implements PropertyInfo { String name }
public class StandardPropertyInfo extends AbstractPropertyInfo { MethodInfo getter, MethodInfo setter }
public class FieldPropertyInfo extends AbstractPropertyInfo { FieldInfo field }

"adrian@jboss.org" wrote:

"alesj" wrote:

"adrian@jboss.org" wrote:

This should have a BeanInfo with one property which is a FieldPropertyInfo

What about if the bean is in ALL or FIELDS mode and the property has just setter or just getter?
OK, there should be some kind of CombinedPropertyInfo.

I don't know, I'm not deep in the implementation details and don't want to be.
I have my own work to do. :-)

If you think there is a policy choice to be made then let
the user decide with a addtional enum value.

"alesj" wrote:

"adrian@jboss.org" wrote:

I know you're probably scared of me telling you did it wrong after the fact,
but now I'll tell you that you are asking a stupid question before the fact. :-)

Could be, but I think it's again the case of 'me explaining what I want badly'. :-)
See below for more details.

...

Eh, during thinking what I wanted to ask/write, I understood what I really needed to do.
So, yes, we can call my previous post again a bad explanation. Since I see I couldn't explain it even to myself at that time. :-)

This is a security hole:

 /**
 * Set the field
 *
 * @param field the field
 */
 public void setField(Field field)
 {
 this.field = field;
 if (isPublic() == false && field != null)
 field.setAccessible(true);
 }

 /**
 * Get the field
 *
 * @return the field
 */
 public Field getField()
 {
 return field;
 }
=

java.lang.reflect.Field field = ...; // I can't do setAccesible
ReflectFieldInfoImpl impl = new ReflectionFieldInfoImpl();
impl.setField(); // So I'll use this hole
field = impl.getField(); // This should have an access check

Also I don't see a test in the kernel project that is validating
that you can't use the xml deployment (or programmatic deployment)
to bypass the private field access.

e.g. See the AccessControlContextTestCase that validates
that somebody can't use the MC to get access the system properties if they
don't have the right to do so.

"adrian@jboss.org" wrote:

public void setField(Field field)
{
this.field = field;
if (isPublic() == false && field != null)
field.setAccessible(true);
}