How do you override the source for configuration properties?

[vrsn-rbuck]

Hi,

Many of our products have configuration properties stored centrally in LDAP and/or Oracle databases. We would like to be able to refer to these properties in JBoss configuration files using property references such as:

${somekey:somedefault}

This is what I would consider ideal:

1. have a way to intercept calls to resolve this property so that I can first attempt to load it from our own properties manager.

2. If my properties manager returns null, have JBoss attempt to resolve the property using System properties much as it does today.

FYI: An attempt had been made in years past to load ALL properties as system properties, but this does not scale, and it just makes no sense design wise: it does not make sense loading entire property sets into memory when all you need is one or two properties.

Apart from modifying the microkernel itself to call directly into our properties manager, are there any other options? Are there any interceptors for property expansion or resolution?

Thanks

[alesj]

"rbuckvrsn" wrote:

Apart from modifying the microkernel itself to call directly into our properties manager, are there any other options? Are there any interceptors for property expansion or resolution?

You could do something like this:

 <bean name="LDAPSystemPropertyHolder" class="org.acme.LDAPPropProvider"/>

 <bean name="NeedsOurSystemProperty" class="org.acme.PropWanna">
 <install bean="LDAPSystemPropertyHolder" method="provideProperty">
 <parameter><this/></parameter>
 <parameter>setMyPropertyWanna</parameter>
 <parameter replace="false">${somekey:somedefault} </parameter>
 </install>
 </bean>

Where mock classes look like:

 public class LDAPPropProvider
 {
 public void provideProperty(Object target, String method, String propKey)
 {
 String ldapProp = LDAP.lookup(propKey);
 Method m = ... // find method on target
 m.invoke(target, ldapProp);
 }
 }

 public class PropWanna
 {
 public void setMyPropertyWann(String prop)
 {
 ...
 }
 }

This is first that it comes to my mind.
It's a big long, but it should work.

But I don't really like it, since it includes that reflection call.
I'll see if there is some better way.

Aha, just remembered one ... one sec ;-)

[alesj]

"alesj" wrote:
Aha, just remembered one ... one sec ;-)

XML:

<bean name="prop1" class="org.acme.LDAPPropProvider">
<constructor>
 <parameter replace="false">${somekey:somedefault} </parameter>
</constructor>
</bean>

 <bean name="NeedsOurSystemProperty" class="org.acme.PropWanna">
 <property name="someProp"><inject bean="prop1" property="provideProperty">/</property>
 </bean>

Where mock is now:

public class LDAPPropProvider
 {
 private String propKey;

 public LDAPPropProvider(String prop)
 {
 this.propKey = prop;
 }

 public String getProvideProperty()
 {
 return LDAP.lookup(propKey);
 }
 }

 public class PropWanna
 {
 public void setSomeProp(String prop)
 {
 ...
 }
 }

[alesj]

It means new bean for every different 'system' property you have, but it is 100% POJO.

[vrsn-rbuck]

Hi,

Thanks for the response.

Is there any decent documentation on what the syntax of these XML files is, and what it means? I have not found much anywhere. Perhaps if there was some documentation on how this XML format works, I could figure out what you wrote below.

I see one example that creates a bean for every property in existence, which does not scale particularly well. I see that in XML people have tons of coding to do when it ought to be something simple to override the internals of property resolution. I see examples that are not dynamic; the property values may change at runtime. I am not sure if any of these examples will allow the JBoss properties manager to be used as a fallback; it looks like each case uses the external repository only.

Are there other options?

Bob

[alesj]

"rbuckvrsn" wrote:

Is there any decent documentation on what the syntax of these XML files is, and what it means? I have not found much anywhere. Perhaps if there was some documentation on how this XML format works, I could figure out what you wrote below.

There is almost complete User Guide for MC 2.0 in SVN trunk:
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/docs/gettingstarted/
It covers basic use cases for MC's xml.
We don't have a concrete release yet, but you can very easily build it with maven2.

"rbuckvrsn" wrote:

I see one example that creates a bean for every property in existence, which does not scale particularly well. I see that in XML people have tons of coding to do when it ought to be something simple to override the internals of property resolution. I see examples that are not dynamic; the property values may change at runtime. I am not sure if any of these examples will allow the JBoss properties manager to be used as a fallback; it looks like each case uses the external repository only.

XML always has that problem.
We'll provide some generic dependency handling via http://jira.jboss.com/jira/browse/JBMICROCONT-167.
And I've just started with porting annotation features into MC's BeanMetaData.
For the runtime property changes, you then need some other mechanism - String is immutable. ;-)

"rbuckvrsn" wrote:

Are there other options?

AOP?

[genman]

I was thinking of doing something like this for my project.

Basically, you would annotate the properties you want to load from the DB/LDAP or whatever with the corresponding property name.

Something like

@DBProperty(name = "foo")
public void setFoo(String foo) {
}

And then isn't there a way to create a deployer that will scan your objects for annotations and do something?

[alesj]

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

Every xml feature will/must have a matching annotation. ;-)

[alesj]

"rbuckvrsn" wrote:
Are there other options?

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

[vrsn-rbuck]

XML always has that problem.

Sounds like we have to modify the microcontainer, and rebuild JBoss to suit our needs. Fallback to microkernel system-properties is required to enable people to migrate off the old Oracle based properties manager and migrate to the new system.

[alesj]

"rbuckvrsn" wrote:

Sounds like we have to modify the microcontainer, and rebuild JBoss to suit our needs.

What's wrong with value-factory?
I'm just adding annotation handling, I guess the initial version will be finished next week.
I'll make it plugable as possible.