In a Talend ESB (SE) project, I have a bean instantiated in the "Spring" configuration using a route resource.
In version 6.5.1 the following (used as a parameter) works fine.
<bean class="java.lang.String">
<constructor-arg>
<bean class="org.springframework.util.FileCopyUtils" factory-method="copyToByteArray" >
<constructor-arg value="classpath:query/sqlQuery.sql" type="java.io.InputStream" />
</bean>
</constructor-arg>
</bean>
but this doesn't for in my Talend 7.1.1 project. It seems to be unable to find the resource. I've looked in the created .kar file, and the resource is in the project .jar in the query folder.
[EDIT] It appears that Talend 7.1.1 encloses the "Spring" configuration in a <blueprint> element, which perhaps has change the way in which this functions.
I presume that something has changed in the way Talend packages the route, or in the way that the Spring xml is interpreted. Camel has no problem finding resources, for example from("sql:classpath:query/sqlQuery.sql"), but the "Spring" classpath search seems not to be able to find them.
I've tried substituting classpath*: for the straight classpath in the parameter as that had been suggested in some of the answers I'd seen to "resource not found" questions, but this didn't seem to be valid and was interpreted as a straight filename.
Am I doing something wrong with the classpath declaration? Is there another way of setting a spring/blueprint bean property with the contents of a resource file?
I've also tried explicitly declaring a ClassPathResource bean and it claims the resource does not exist when using the getInputStream() method, despite the fact I can see it if I open up the contained jar file.
Has the wrapping of the created feature in Maven terms (from Talend 7) had some impact on the classpath I need to use?
Related
I use maven. My web application contains two modules and each has it's own spring context. First is packed to jar, the second one to war. The second one uses first module's jar and calls it's methods.
I need to add property file, which will be used by first module (via spring context). The main issue is that I should be able to access/edit this property file after war deployment.
How can I provide such a property file, that will be used in first jar module and can be changed after war module deployment?
Thanks.
Sorry, don't see the problem, you need to describe that better. From what I understood this is the way to go:
place a.properties in src/main/resources in the JAR module
use a PropertyPlaceholderConfigurer to make the properties available in the Spring context
it'll be packed in root of the JAR
the JAR ends up in WEB-INF/lib of the WAR which again is "root of the classpath" so to speak
Update, 2013-06-09
(question was updated based on comments to initial answer above)
Essentially what you seem to be looking for (still not quite sure) is how to load properties from a properties file that is not packaged with your WAR/JAR.
In this case you can skip all of the above steps except 2.
Use a PropertyPlaceholderConfigurer and specify the location of the file as classpath*:a.properties (see below)
Place a.properties anywhere on the classpath outside the WAR file.
Warning! Of course you can now edit the properties independently from releasing the WAR file but since Spring initializes the beans on application start and since all beans are singletons by default changes to the properties file won't become effective until you restart the app.
XML example
<bean class="....PropertyPlaceholderConfigurer">
<property name="location" value="classpath*:a.properties" />
I have config.properties in my OSGi bundle. but the OSGi bundle can not read it.
Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=dao, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.beans.factory.BeanInitializationException: Could not load properties; nested exception is java.io.FileNotFoundException
I am using Spring to read the config.properties
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="config.properties" />
</bean>
It seems like the OSGi only reads the .xml file.
Does someone has any idea?
You have to specify the correct resource for your value property.
There are some built in implementations, like:
ClassPathResource: value="classpath:/META-INF/config.properties"
FileSystemResource: value="file:C:/foobar/config.properties"
If you want to place the file outside the library you can use a system property (e.g. -DpropertyFile=C:/loremIpsum/config.properties) to specify the path, like
value="file:${propertyFile}"
since Spring 3.0.? even with default value
value="file:${propertyFile:C:/foobar/config.properties}"
(Have a look at your OSGi framework on how to set a system property. I am also not sure if the ClassPathResource works well / is recommended in OSGi environments.)
I'm trying to deploy a spring based bundle in osgi (fuse esb).In spring context, I'm referring to a db4o file which is inside resources folder. As per my understanding, a maven project will make sure that any file available under resources folder will be available in project classpath. I've kept the file under resources/META-INF/spring/repo/test.db4o.
Here's the entry in spring context.
<bean id="objectContainer" class="org.springmodules.db4o.ObjectContainerFactoryBean">
<property name="databaseFile" value="classpath:META-INF/spring/repo/test.db4o" />
</bean>
Once I install and try to start the application, I'm getting the following exception.
java.io.FileNotFoundException: OSGi resource[classpath:META-INF/spring/repo/test.db4o|bnd.id=258|bnd.sym=taxonomydaoimplbundle] cannot be resolved to absolute file path because it does not reside in the file system: bundle://258.0:1/META-INF/spring/repo/test.db4o
I've tried different combinations, but OSGi doesn't seem to recognize this file. Any pointer will be appreciated.
-Thanks
I found the issue finally. ObjectContainerFactoryBean is relying on OSGiResourceBundle to load the resource as a file object. Though OSGiResourceBundle exposes a method called getFile(), it doesn't work as intended in an OSGi environment. It always expects a file protocol whereas the resource returned as an URI has a protocol "bundle".Hence, the exception is being thrown. The workaround is to use a inputstream or getUrl. Since I didn't have the source code of ObjectContainerFactoryBean, I had to extend this class to provide my own implementation which loads the file as an inputstream.
I use Spring to configure my Java Web App and in my Spring configuration I obtain a datasource via JNDI for Jetty as follows:
<jee:jndi-lookup id="dataSource" jndi-name="jdbc/myDataSource" />
but this won't work with Tomcat. With Tomcat I have to do this:
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/myDataSource" />
Whats the best way to solve this? I am already using JNDI as a way to externalize configuration, so I can't externalize my externalized configuration! At the same time I absolutely loath the idea of having two separate Spring configuration files. HELP!!!
I found an answer here, but I thought it was a bit complicated, but it did give me the idea to use the very cool ServerDetector class that blogger had found.
Once I can dynamically figure what type of server I am running in, I was able to use the Spring expression language to do the rest of the work:
<jee:jndi-lookup id="myAppDataSource"
jndi-name="#{ (AppServerType == 'Jetty' ? 'jdbc/' : 'java:comp/env/jdbc/') +
'myAppDataSource' }" />
Easy!
After some experimenting, I figured out I could just force Jetty to use the same JNDI path as Tomcat. The following snippet is from my jetty-env.xml file:
<New id="myDataSource" class="org.mortbay.jetty.plus.naming.Resource">
<!-- We MUST specify the entire JNDI path here to force compliance with the Tomcat/J2EE convention -->
<Arg>java:comp/env/jdbc/myDataSource</Arg>
<Arg>
<New class="com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean">
<Set name="uniqueResourceName">sbeDatabase</Set>
...............
</New>
</Arg>
</New>
Not sure if this is ideal, but it works.
Update:
It works if you put your jetty-env.xml file inside the WAR...but for whatever reason, one you move this configuration outside the WAR and into a context fragment file in Jetty's "contexts" directory then it throws an exception:
Check it out: http://jira.codehaus.org/browse/JETTY-273
The cleanest way to do it is to configure your configuration. ;)
Use a Spring property place holder. See
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-placeholderconfigurer
The basic idea is that you just put a placeholder in your spring config with a property, and then it reads matching property from a properties file. You generate the properties file in your build process. Ive seen it done where the build tool (ant) reads an environment variable and then creates a properties file appropriate for the environment based of a skeleton file populated with tokens.
I'm developing some portlets for Liferay Portal 5.2.3 with bundled tomcat 6.0.18 using Spring IoC container.
I need to map the User_ table used in Liferay database to an entity with Hibernate, so I need to use two different dataSources to separate the liferay db from the db used by portlets.
My jdbc.properties has to hold all connection parameters for both databases: no problem for the one used by portlets, but I am having issues determining which database uses liferay to hold its data.
My conclusion is that i should have something like this:
liferayConnection.url=jdbc:hsqldb:${liferay.home}/data/hsql/lportal
in order to get the database url dynamically loaded, according to Liferay properties found in portal-ext.properties. (Or, better, load the whole portal-ext.properties and read database properties from there).
The problem is that the placeholder is not resolved:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'liferayDataSource' defined in class path resource [WEB-INF/applicationContext.xml]: Could not resolve placeholder 'liferay.home'
To dodge this problem I tried to load explicitly portal-ext.properties with a Spring bean:
<bean id="liferayPropertiesConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
p:location="../../portal-ext.properties"/>
but no luck: liferay.home is not resolved but there aren't other errors.
How can I resolve the placeholder defined by Liferay? Thanks
You can use PropsUtil class (from Liferay) to get values of portal-ext.properties.
String value = PropsUtil.get("key");
For loading properties files from an applicationContext.xml file I usually use the PropertiesFactoryBean specifying the location property with a the name of the file located in the classpath, like this:
<bean name="myHibernateProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="location">
<value>classpath:hibernate.properties</value>
</property>
</bean>
Make sure the properties files are in a folder/package that is in the classpath.
You can call PropsUtil using SpringEL. for example:
#{T(com.liferay.portal.kernel.util.PropsUtil).get('liferay.home')}
I haven't tried exactly this. but you could load the liferay properties that you need with the following:
<util:properties id="liferayProps">
<prop key="liferay.home">#{T(com.liferay.portal.kernel.util.PropsUtil).get('liferay.home')}</prop>
</util:properties>