It seems like there's been a few iterations of property support in spring it's hard to tell what's best practice and the manuals are written from the point of view of someone who is familiar with every other iteration. I feel like this should be a simple and common requirement but given how hard it's been please correct me if there's a more idiomatic way.
What I want is to pass an additional properties file to my spring web app based on a context property which the client is setting using a tomcat descriptor like so
<Context path="/foo" reloadable="true">
<Parameter name="foo.config" value="file:${catalina.base}/conf/foo.properties"/>
</Context>
In spring for the live profile I have this
<beans profile="live">
<context:property-placeholder location="classpath:timetabling.live.properties,${timetabling.config}"
ignore-resource-not-found="true" />
</beans>
So I'd assumed this doesn;t work because I'm trying to configure placeholder suppport with a placeholder. If I use a system property however then this works fine. I know that spring 3.1 has baked in support for system and environment properties so I guess my question is how can I augment this support with something context aware before the placeholder is resolved?
--Update--
looking at http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/ particularly at footnote 1, I would expect to have a DefaultWebEnvironment which should already have aceess to context init params. Now I am more confused, can someone provide me with a concrete example of context property retrieval? At this point I feel like I've read every javadoc available and they are just not helpful.
<context:property-placeholder /> sets up a PropertyPlaceholderConfigurer which reads from .properties, system properties and environment variables. A Tomcat context.xml however sets up a servlet context init parameter. So what you need is a ServletContextPropertyPlaceholderConfigurer.
Related
When deploying "regular" web apps to Liberty, I was used to binding the global datasource configured in Liberty's server.xml to the individual application by using a child element within the element, like this:
<application context-root="helloApp" location="..." name="helloApp" type="war">
<application-bnd>
<data-source id="db2appDs" name="jdbc/datasource" binding-name="jdbc/theDB"/>
</application-bnd>
...
</application>
<dataSource id="db2ds" jndiName="jdbc/theDB" type="javax.sql.DataSource">
...
</dataSource>
When configuring my first Spring Boot application to deploy to Liberty, I am trying to use the new <springBootApplication> element for it - but I don't seem to be able to add a binding for the datasource I want to use the same way, as this element doesn't seem to support such a child. (It seems to want only <classloader> as a child).
I've seen people suggest I use an #Resource annotation that includes both application-local JDNI name and global JNDI name for the datasorce - but that defeats the purpose, since I don't want to know what the global name is until deploy time.
Is there another way to do this, like we used to before? Or are applications deployed through <springBootApplication> expected to know the global JNDI name of the datasource(s) they want?
Application-defined datasources are not supported for <springBootApplication/>’s. While your application may certainly access a Liberty datasource using its global JNDI name, you should configure the spring.datasource.jndi-name property within your Spring Boot application as described in section 29.1.3 of the Spring Boot features reference. For your example try spring.datasource.jndi-name=jdbc/theDB.
I can't entirely configure property-placeholder from system property because I can't give comma-separated list of resources.
I'm trying to do like:
<context:property-placeholder location="${config-location}" />
I use system property to configure this. It works if I give one location only, like "classpath:main.properties", but it does not if I'm trying this: "classpath:main1.properties,classpath:main2.properties".
If I use this latter exact value directly in xml configuration it works fine. I guess it resolves comma-separation earlier than placeholders. It should be the other way around.
P.S : version 4.3.4
Another possible worth tryout would be,
<context:property-placeholder location="#{systemProperties['config-location']}" />
how to read System environment variable in Spring applicationContext
I am new to spring and happy to see that following works as expected:
<bean id="..." class="server.Shell">
<property name="usableCommands" value="cat"/>
</bean>
The above is in the client code, where I have provided the server.Shell. Now I would like for the clients to be able to use the following:
<shell id="...">
<usableCommands value="cat"/>
</shell>
Is there anything in springframework that I can use to map say an xsd to bean classes? Any other suggestion for easily creating a simple xml based domain language?
You can register a custom XML Namespace in Spring that would allow you to customize your configuration XML. If you're looking to create a sort of DSL in your Spring configuration XML, that might be a good place to start.
UPDATE:
Check out this link for a general example of how custom namespaces in Spring work. This pattern should hold in OSGi as well -- check out Section 6.4 of the Spring OSGi docs for an explanation. If you're new to OSGi, it can be daunting in general. SpringDM can help. Try here for some background and here for an example. Hope that helps.
I'm creating a custom taglib, and would like to use some config options that are loaded via the underlying Spring framework using:
<context:property-placeholder location="classpath:config.properties" />
How would I get access to these variables in my taglib?
Thanks,
James.
The JSP taglibs have nothing in common with the Spring context's lifecycle, they're managed by the servlet container. This can complicate things a bit, for example: inject-dependency-into-a-taglib-class, how-to-write-tag-in-my-spring-project.
Since you're only mentioning the need for contents of the properties file, you could use plain old java.util.ResourceBundle (or, if you need more flexibility, Apache Commons' org.apache.commons.configuration.PropertiesConfiguration).
(One could also argue that requiring access to configuration in your tags indicates a design problem...)
I've developed a web service with jax-ws and Spring using the tutorials at the jax-ws commons website. It shows you how to define and reference your service from your spring applicationContext file (https://jax-ws-commons.dev.java.net/spring/).
What is the reason for the "#" when referencing the web service? I would expect to see something more like
<ws:service name="myEventWS" ref="eventWebService"/>
but following example at the above link I created the following which works.
<bean id="eventWebService" class="com.myws.EventWS">
<property name="model" ref="EventModel"/>
</bean>
<wss:binding url="/EventWS">
<wss:service>
<ws:service bean="#eventWebService"/>
</wss:service>
</wss:binding>
<ws:service> is using a custom configuration namespace, which is a feature of Spring which allow you to express complex bean graphs using simpler namespace. The meaning and interpretation of these custom namespaces is down to the implementation in question, in this case the JAX-WS-Commons project. It seems the authors of that decided that bean=#eventWebService means what you refer to as ref="eventWebService".
I don't know whay they did it that way, maybe they thought it was more readable... maybe they thought that bean=eventWebService (without the hash) means a name, rather than a reference... I don't know. The documentation isn't very clear either.
Either way, I'm pretty sure sure it's not a core Spring syntax, nor a convention that I've seen before.
the "#" tells the bean that it's not a class, but rather a ref.
HTH
#eventWebService refers to the bean of type EventWebService (according to the default Spring naming convention when bean is is not specified).