Property lookup interceptors

[alesj]

Is this a reasonable feature?
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113937

Maybe we could add something similar as what we did with ProgressionConvertor to ValueConvertor regarding the property replace, having StringPropertyReplacer as default?

A PropertyLookup interface, which you can set as a system property?

[adrian.brock]

This is the wrong approach. The system property stuff is legacy from the MBean days.
It's certainly the wrong api to be extending, we need to let it die. :-)

The correct approach is should be to create your own ValueMetaData

<deployment xmlns="urn:jboss:bean-deployer:2.0" xmlns:ldap="urn:jboss:ldap:1.0">

<bean name="LDAPLookUp" ...>
 <!-- ldap config here -->
</bean>

<bean name="blah">
 <property name="x"><ldap:property bean="LDAPLookUp" key="ldapkeyhere" default="...">
</deployment>

The ldap:property parses to an implementation of ValueMetaData,
something similar to the inject value metadata (AbstractDependencyValueMetaData),
except it gets the value from the LDAPLookUp bean.

(untested code)

 public Object getValue(TypeInfo info, ClassLoader cl) throws Throwable
 {
 ControllerState state = dependentState;
 if (state == null)
 state = ControllerState.INSTALLED;
 Controller controller = context.getController();
 ControllerContext lookup = controller.getContext(getUnderlyingValue(), state);

 if (isLookupValid(lookup) == false)
 throw new Error("Should not be here - dependency failed - " + this);

 if (lookup == null)
 return null;

 Object ldap = lookup.getTarget();
 if (result instanceof LDAPLookup == false)
 throw new IllegalStateException("Not an LDAPLookup: " + ldap);
 LDAPLookup ldapLookup = (LDAPLookup) ldap;
 Object result = ldapLookup.lookup(key);
 if (result == null)
 return defaultValue;
 return result;
 }

But it is not documented how to do this, the only close example
is the javabean namespace but that just creates objects directly from the xml.

There maybe a case for abstracting this such that a bean could
implement a "ValueFactory" interface

public interface ValueFactory
{
 Object getValue(String key);
}

and us including a generic piece of xml in our schema to enable its use

<property name="x"><value-factory bean="LDAPLookup" key="..." default="..."/></property>

Which would probably cover most simple use cases?

[adrian.brock]

NOTE: The example code above does not include the property type conversion.
i.e. the value-factory probably just returns strings that need converting to the
type of the property.

[adrian.brock]

<deployment xmlns="urn:jboss:bean-deployer:2.0" xmlns:ldap="urn:jboss:ldap:1.0">

<bean name="LDAPLookUp" ...>
 <!-- ldap config here -->
</bean>

If you did go the seperate namespace route, then you'd probably
also want to define a seperate BeanMetaDataFactory to make the ldap configuration
easier. e.g.

<ldap:config name="LDAPLookUp">
 <!-- simple ldap xml here instead of the MC property xml -->
</ldap:config>

[alesj]

Which would probably cover most simple use cases?

What about:

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" />
 <parameter>foo.bar.prop</parameter>
 <parameter>mydefault</parameter>
 </value-factory>
</property>

[adrian.brock]

"alesj" wrote:

Which would probably cover most simple use cases?

What about:

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" />
 <parameter>foo.bar.prop</parameter>
 <parameter>mydefault</parameter>
 </value-factory>
</property>

That would remove the need for the interface (what was I thinking? :-)
But I don't think the value factory needs to know the default value,
it just returns "null" when it doesn't have the property.

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" default="mydefault">
 <parameter>foo.bar.prop</parameter>
 </value-factory>
</property>

We should probably still have the shorthand mechanism for simple one
parameter methods.

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" parameter="foo.bar.prop" default="mydefault"/>
</property>

[alesj]

That would remove the need for the interface (what was I thinking? :-)

Think POJO. ;-)

[alesj]

But I don't think the value factory needs to know the default value,
it just returns "null" when it doesn't have the property.

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" default="mydefault">
 <parameter>foo.bar.prop</parameter>
 </value-factory>
</property>

Value factory can take as many parameters as it wants, and return whatever you implement.
What I meant was that LDAPLookup is something like this:

public class LDAPLookup {

 public String getValue(String key, String default)
 {
 String value = LDAP.lookup(key);
 return value != null ? value : default;
 }

}

So your version would just be:

public class LDAPLookup {

 public String getValue(String key)
 {
 return getValue(key, null);
 }

 public String getValue(String key, String default)
 {
 String value = LDAP.lookup(key);
 return value != null ? value : default;
 }

}

We should probably still have the shorthand mechanism for simple one
parameter methods.

<property name="x">
 <value-factory bean="LDAPLookup" method="getValue" parameter="foo.bar.prop" default="mydefault"/>
</property>

That sounds reasonable.

[adrian.brock]

Actually, I'm wondering whether this feature shouldn't just be a part of the

<inject/>

xml.

We already support retrieving a property from another bean
(the default value may also be useful for that!)
So this is just a different case where you invoke a method with parameters
instead.

[alesj]

Actually, I'm wondering whether this feature shouldn't just be a part of the

<inject/>

xml.

I thought of that too.
But we already stuffed 'inject' with all sorts of things - bean property, contextual injection, fromContext.
The concept is the same, but lets keep it separate, not to confuse people with too many configurations - specially if we want to have shorthand single parameter value-factory.

[starksm64]

This also relates to the metadata repository and loaders notion where the source of a property can start out coming from an xml file on a server, and then be overriden by a management layer to redirect to an ldap server/database. I can see plugging different sources of property values, but its not clear that supporting ldap namespace syntax is an mc concern.

[alesj]

..., but its not clear that supporting ldap namespace syntax is an mc concern.

I agree.
I'll just focus on the actual value-factory.

[alesj]

"alesj" wrote:

I'll just focus on the actual value-factory.

Done.
http://jira.jboss.com/jira/browse/JBMICROCONT-197