-
1. Re: How do you override the source for configuration propert
alesj Jul 19, 2007 9:56 AM (in response to vrsn-rbuck)"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 ;-) -
2. Re: How do you override the source for configuration propert
alesj Jul 19, 2007 10:12 AM (in response to vrsn-rbuck)"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) { ... } }
-
3. Re: How do you override the source for configuration propert
alesj Jul 19, 2007 10:14 AM (in response to vrsn-rbuck)It means new bean for every different 'system' property you have, but it is 100% POJO.
-
4. Re: How do you override the source for configuration propert
vrsn-rbuck Jul 19, 2007 4:50 PM (in response to 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 -
5. Re: How do you override the source for configuration propert
alesj Jul 20, 2007 1:23 AM (in response to vrsn-rbuck)"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? -
6. Re: How do you override the source for configuration propert
genman Jul 20, 2007 1:29 PM (in response to vrsn-rbuck)
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? -
7. Re: How do you override the source for configuration propert
alesj Jul 21, 2007 2:19 AM (in response to vrsn-rbuck)See http://jira.jboss.com/jira/browse/JBMICROCONT-197.
Every xml feature will/must have a matching annotation. ;-) -
8. Re: How do you override the source for configuration propert
alesj Jul 22, 2007 7:00 AM (in response to vrsn-rbuck) -
9. Re: How do you override the source for configuration propert
vrsn-rbuck Jul 24, 2007 2:54 PM (in response to 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. -
10. Re: How do you override the source for configuration propert
alesj Jul 24, 2007 4:24 PM (in response to vrsn-rbuck)"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.