I have created a JavaMail inflow resource adaptor and we only support ActivationSpecs that have String properties. If the natural type for an ActivationSpec property is not type String, then the property setter has to handle the type conversion. This seems highly non-JavaBean like given that you have to duplicate all of the PropertyEditor behavior in each non-native String setter.
Given that these are JavaBeans as per the spec, it does not seem a big stretch to support the same semantic we do with MBeans in that we use String to bean property conversion via PropertyEditors and introspection.
I added a generic utility method to org.jboss.util.propertyeditor.PropertyEditors
mapJavaBeanProperties(Object bean, Properties beanProps) throws IntrospectionException
which will do the mapping given the string/string key/value forms of the properties so this is an easy change. This is a pure superset of the existing behavior. Adrian voiced a portability concern that someone who writes a rar that works on jboss will be surprised when the same does not deploy elsewhere due to the extended behavior. I would argue that anything less is not actually supporting the JavaBean spec properly.
I'll look at supporting this with a testcase in head. I guess the question is why should this every be disabled?