Re: Overriding XML configuration from system properties

[Roger Marshall <ro...@aetopia.com>]

David, Niklas, thank you for your replies. Reassuring to find that I  
was roughly on the right track.

David Latorre wrote:

>> My first question is whether there is actually valid set of  
>> properties file
>> entries that would work with the first version of ftpserver.xml  
>> (the one
>> using the http://mina.apache.org/ftpserver/spring/v1 schema)?
>
> I don't know Spring myself but it's my understanding that adding a
> factory.getBeanDefinitionNames() to your example above should print
> all the bean names which are available. There are only a few of them
> (i'd say you cannot see inner beans) so I don't know if this approach
> is suitable for you ( Let's wait to Nilklas response but I think that
> inner beans are not supported by PropertyOverrideConfigurer, you might
> ask in their mailing list )
>

That's useful - I hadn't spotted that method.

>> My second question (assuming the answer to the first is 'no'), is  
>> how to
>> reference a bean with a dot in its name from a properties file?
>
> By default, PropertyOverrideConfigurer takes the right part of the
> first dot as the bean name (
> 'ftpserver.connection.maxLogins' would mean that the bean name is  
> 'ftpserver'
>
> You can change the bean Name separator with
> PropertyOverrideConfigurer.setBeanNameSeparator(String
> beanNameSeparator) so you can do something like this:
>
> poc.setBeanNameSeparator(":");
>
> ftpserver.connection:maxLogins = 5;
>
> I haven't  checked if the  ':' character would be accepted though.
>
>>

poc.setBeanNameSeparator(String beanNameSeparator) worked as  
advertised. However, the ':' character did cause problems as it's one  
of the key-value separators in Java properties, so it must be escaped  
with a backslash. For that reason I'll probably choose a different  
separator, but the following worked perfectly:

ftpserver.connection\:maxLogins=5


Incidentally, the following worked when using the custom schema  
(pointless, unfortunately, because of the other issues you both  
mentioned):

org.apache.ftpserver.listener.ListenerFactory#0\:serverAddress=4.3.2.1

"org.apache.ftpserver.listener.ListenerFactory#0" came from  
factory.getBeanDefinitionNames(), and poc.setBeanNameSeparator(String
beanNameSeparator) was required again because of the dots in the bean  
name.



David Latorre wrote:

> Yeah it's a same that because of different issues none of them,
> PropertyPlaceholder nor PropertyOverriden will work :-S
>
>
>
> 2009/5/31 Niklas Gustavsson <ni...@protocol7.com>:
>> On Sun, May 31, 2009 at 12:06 AM, Niklas Gustavsson
>> <ni...@protocol7.com> wrote:
>>> On Fri, May 29, 2009 at 7:17 PM, Roger Marshall
>>> <ro...@aetopia.com> wrote:
>>>> My first question is whether there is actually valid set of  
>>>> properties file
>>>> entries that would work with the first version of ftpserver.xml  
>>>> (the one
>>>> using the http://mina.apache.org/ftpserver/spring/v1 schema)?
>>>
>>> We do not currently support property based configuration (I  
>>> personally
>>> find this a major gap since I'm a big user of property replacement
>>> with Spring). However, there is an issue reported
>>> (https://issues.apache.org/jira/browse/FTPSERVER-282) that we plan  
>>> on
>>> fixing for 1.1. Not waiting for 1.1, I think your solution is the  
>>> best
>>> available. I'm not very familiar with the problem your having so I  
>>> do
>>> not have any more input than the excellent reply you already  
>>> received
>>> from David.
>>
>> I should also have noted that you can used a
>> .PropertyPlaceholderConfigurer in which case you can choose the
>> property name yourself. However, as FTPSERVER-282 points out, if  
>> using
>> our custom schema, you will not be able to use this for numeric
>> values, instead you would have to use the standard Spring <bean>  
>> tags.
>>
>> /niklas
>>
>
>

With the old properties-based configuration, we were able to introduce  
properties at deployment time without ever having referenced those  
properties in our application code. I was aware of the existence of  
PropertyPlaceholderConfigurer, but I had avoided it because it looked  
like I would have to create placeholders for every settable property  
if I wanted to retain that flexibility. (And I wasn't sure whether I  
would also be compelled to specify values for every defined  
placeholder.)

--
Roger Marshall