HTML5 Canvas
Written by: Simon Sarris
Featured Refcardz: Top Refcardz:
  1. Apache Hadoop
  2. Web Driver
  3. MVVM
  4. REST
  5. ADO.NET
  1. HTML5
  2. Ajax
  3. jQuery Selectors
  4. CSS Part 1
  5. Git

Link Details

Link 259378 thumbnail
User 288894 avatar

By anshu mishra
via anshu-manymoods.blogspot.com
Published: Oct 14 2009 / 09:24

This recipe shows how to extend the spring's PropertyPlaceholderConfigurer to access the value of a property key in your application.
  • 8
  • 4
  • 4190
  • 14

Comments

Add your comment
User 203717 avatar

chudak replied ago:

-1 votes Vote down Vote up Reply

Defeats the whole idea of dependency INJECTION and creates a leaky abstraction.

User 283139 avatar

ceaseoleo replied ago:

0 votes Vote down Vote up Reply

I don't think this is correct, in spring 3.0 , you can just do @Value("name") ... something along these lines to get a property value.

User 288894 avatar

anshu mishra replied ago:

0 votes Vote down Vote up Reply

I was not aware of that spring 3.0 way, by the way it is not available to be used in prod. Thanks for sharing it though.
As far as leaky abstraction is concerned it kind of depends on your choice. I am not saying you absolutely need to use it. If only to be used in middleware components, one may pass the properties as spring bean property, and then can access it. However, if you think about the need of it being accessed in your front end components (like freemarker templates), it makes easier for them not to be dependent on java coders to keep adding the accessible props for them.

User 203717 avatar

chudak replied ago:

0 votes Vote down Vote up Reply

"However, if you think about the need of it being accessed in your front end components (like freemarker templates), it makes easier for them not to be dependent on java coders to keep adding the accessible props for them. "

How is programmatically accessing the properties (as described in the blog) solving this problem? Answer: it's not.

User 288894 avatar

anshu mishra replied ago:

0 votes Vote down Vote up Reply

Well, you can do it like this (Didn't mention the use case in the blog, as never thought about it..there could be so many reasons to do it and not to do it this way):-

Put it in some abstract class which the other resources are extending.
model.put("getProperty", propertyConfigurer);

#Add one more helper method for the Freemarker layer
OpenPropertyPlaceholderConfigurer extends PropertyPlaceholderConfigurer implements TemplateMethodModelEx {

public Object exec(List list) throws TemplateModelException {
SimpleScalar property = (SimpleScalar)list.get(0);
try {
return getMergedProperties().getProperty(property.getAsString());
} catch (IOException e) {
throw new TemplateModelException(String.format("Error resolving requested property: %s", property), e);
}
}
}

#Access it in .ftl file

"MyVal": "${getProperty("MyProperty)}"

User 203717 avatar

chudak replied ago:

0 votes Vote down Vote up Reply

Now you have your view pages pulling in runtime properties? THAT's maintainable. Why not have them just pull the data out of the database while you are at it and skip the controller altogether? Perhaps you should be PUSHING those values to the view from your controller? Like you are pushing the rest of the data that the view is displaying? If you can push the configurer to the view, why not just the property that it needs?

No matter how you try to spin it..having components pulling in values from some global 'property manager' is at odds with the goals of IOC, which is supposedly why you chose Spring in the first place.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.