debugging propertyPlaceholderConfigurer

[Wm Stafford]

In my daoContext.xml I specified a propertyPlaceholderConfigurer

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.Pr opertyPlaceholderConfigurer">
<property name="location">
<value>/WEB-INF/classes/app.properties</value>
</property>
</bean>

and some db connection properties, for example:
<bean id="DataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="username">
<value>$UserStr}</value>
</property>

my app.properties file has matching values:
UserStr=phaseOneTesting

There are no startup errors related to locating the properties file but the first attempt to access the db indicates that the connection parameters are wrong or misssing:
DBCP borrowObject failed: java.sql.SQLException: ORA-01017: invalid username/password; logon denied

I know the connection parameters are correct in the properties file because I am moving from Ant property placeholder replacement via filtering to the Spring way of doing things.

I don't know where to go from here in trying to determine what went wrong. Is there a way to debug the process of replacing placeholders?

Thanks for any guidance,
-=bill

[Andrei Stefan]

How do you load your configuration files ?

Is there a way to debug the process of replacing placeholders?

Afaik there are some debug informations from this class when files are loaded.
You can make a simple test case with another bean to see what value your PropertyPlaceholderConfigurer class gets.

[Wm Stafford]

So you're saying there is no way to tell Spring to display or document the placeholders it is replacing?

[al0]

So you're saying there is no way to tell Spring to display or document the placeholders it is replacing?

No. The best that you can achieve without modification of the source code is name of replaced placeholder (by setting logging level to "Trace").

But, really, I would suggest to double-check your configuration files (mostly for simple mistyping, including false case for some characters). It is very unlikely that bug is inside PropertyPlaceholderConfuigurer as it is one of the most used components in the Spring.

Regards,
Oleksandr

[Wm Stafford]

I never suggested that there was a bug in PropertyPlaceholderConfigurer, in fact I totally agree with you, it is extremely unlikely given its many years of faithful service.

I'm sure my properties are correct because I have been using the same properties file for months as an Ant filter file.

I have never used PropertyPlaceholderConfigurer before so I'm sure the problem lies with me. I just don't know how to proceed.

Thanks for the reply,
-=bill

[karldmoore]

You can obviously turn up the logging and see what's coming out. If you really wanted to I don't see why debugging this would be a problem. It would probably make more sense to debug the connection pool though and see what it's creating the connections with. If you really wanted to you could post the configuration (minus sensitive details). Are there any other files on the classpath it might be picking up?

[sabarish]

/WEB-INF/classes/app.properties

In a web application classes folder will already be in classpath. So if app.properties is going to be in classes folder then you should give app.properties as the location instead of /WEB-INF/classes/app.properties.

Also u didn't mention how ur loading ur config files. Only ApplicationContexts process postprocessors like this PropertyPlaceHolderConfigurer automatically. Beanfactories do not.

[karldmoore]

Also u didn't mention how ur loading ur config files. Only ApplicationContexts process postprocessors like this PropertyPlaceHolderConfigurer automatically. Beanfactories do not.

If the place holders weren't getting resolved though, I would have expected to see an exception. OK, you're missing a bracket.

$UserStr}

${UserStr}

[Wm Stafford]

Many, many thanks to all who replied! The problem turned out to be unannounced db maintenance which clobbered some resource needed for logins.

As several suggested, I looked at the values in my DataSource object and they were correct. So the problem had to be outside of the application.

Thanks again to all who took the time to reply,
-=bill