Unless I put META-INF in the root, context.xml along with the resources defined (queues, jdbc connection pool, etc) are not read correctly and Spring throws exceptions during start up.
Now I end up with two META-INF folders, I need one on the classpath (WEB-INF/classes/META-INF) due to persistence.xml.
Is is okay to have two META-INF's? I always configured resources in Spring's applicationContext so didn't notice before.
Thanks.
I guess it is all right. They both might have slightly different purposes.
webapp-root/META-INF is directory for metadata of the web application, which you can access via servletContext.getResource("/META-INF/foo").
webapp-root/WEB-INF/classes/META-INF is directory for metadata of java classes, which you can read via getContextClassLoader().getResource("/META-INF/foo").
Related
I am running hibernate search with spring boot. I have written a working configuration for my application. How ever, i want to externalize my configuration and use ./config/hibernate.properties instead of src/main/resources/hibernate.properties. After copying my properties file to the desired location, i am getting and exception:
nested exception is java.io.FileNotFoundException: class path resource [hibernate.properties] cannot be opened because it does not exist
Anyone with any idea on how i should tell spring to read my configuration file?
Move your configuration to an src/main/resources/application.properties file and prepend spring.jpa.properties. everywhere, so hibernate.dialect will become spring.jpa.properties.hibernate.dialect, for example.
Then you can use Spring features to move your configuration wherever you want. To move it to ./config/application.properties I suppose you will have to add #PropertySource("./config/application.properties") to one of your #Configuration classes, or something similar.
I'm sure you can also keep the hibernate configuration in a separate file (separate from the rest of your application configuration).
See https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html for more details about externalizing configuration in Spring Boot.
For some reason, it seems hibernate-search will prevent application from starting as long as a hibernate.properties configuration file does not exist. After trying for a while without success, i found a work around for my problem.
First, i created an empty hibernate.properties file and place it under src/main/resources.
Secondly, i moved all hibernate-search configurations to application.properties as follows:
spring.jpa.properties.hibernate.search.default.indexmanager = elasticsearch
spring.jpa.properties.hibernate.search.default.elasticsearch.host = http://my-server.com
spring.jpa.properties.hibernate.search.default.elasticsearch.index_schema_management_strategy = CREATE
spring.jpa.properties.hibernate.search.default.elasticsearch.required_index_status = yellow
This way, the application will start and spring will get all configuration from the externalized configuration as documented here.
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'm probably thinking about this incorrectly, but here's what I'm up against:
I'm injecting Spring Resource objects into my app that give me the location of security certificates, for example:<property name="certificateResource" value="SomeCert.p12" /> where certificateResource is of type org.springframework.core.io.Resource
Running under JUnit the Resource is a classpath resource and everything is fine. When deployed as a war under Tomcat the the Resource is in a Servlet Context and requires WEB-INF/classes/ prepended to the certificate.
I've tried a number of Resource prefix and wildcard combinations but can't come-up with a single string that satisfies both contexts. So far the "solution" is to override the bean definition in src/test/resources/test-applicationContext.xml but that means maintaining the strings in two locations.
Any pointers to better solutions would be appreciated, thanks.
I have tried to make a small but descriptive application using spring-test and spring-webmvc and using resources referenced in xml configs while these xml's are reused by production and testing spring configurations. Here is what I recieved: github.com/isopov/spring-resource-test
The central is the referencing of the prodcution xml config from the testing config:
<import resource="file:src/main/webapp/WEB-INF/applicationContext.xml" />
it is also possible to not import one xml from the other, but give each test several configs:
#ContextConfiguration(locations = { "classpath:test-applicationContext.xml",
"file:src/main/webapp/WEB-INF/applicationContext.xml" })
the resource itself resides in src/main/resources (I assumed you are using Maven or something derived from the "Standard Directory Layout") so is always accessible with "classpath:hello.txt" from any spring config.
I tested this with maven build, as web-application and running UTs inside Eclipse.
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 have a problem accessing JNDI resources from within an OSGI bundle, hosted in
WebSphere Application Server (WAS) using a servlet bridge.
It is failing on creating the JNDI initial context. My code is:
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
InitialContext ctx = new InitialContext(env);
This fails with:
javax.naming.NoInitialContextException:
Failed to create InitialContext using factory specified in hashtable {java.naming.provider.url=corbaloc:rir:/NameServiceServerRoot, java.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory, java.naming.factory.url.pkgs=com.ibm.ws.naming:com.ibm.ws.runtime:com.ibm.iscportal.jndi} [Root exception is java.lang.NullPointerException]
When I run the same code directly within a WAR module (not using OSGI), it is successful. I assume therefore the problem is something about accessing JNDI from within OSGI.
I have seen some references to Class Loader problems when accessing JNDI from within OSGI ... not sure if this is my problem, since the above exception does not explicitly relate to class loading, but maybe it is. Anyhow, if this is the problem, I am not sure how to fix it!
Is it in fact possible to access JNDI and JDBC entries set up within WAS, from within my OSGI module?
My application is an Eclipse RAP (Rich Ajax Plugin), packaged into a WAR file using the Eclipse WAR Product Tooling described at:
http://eclipsesource.com/blogs/2010/08/17/equinoxrap-war-deployment-an-end-to-the-pain/
This works successfully so far, apart from the JNDI access.
Many thanks
David
By default the thread context classloader will be used to load the InitialContextFactory. This is probably (but no guarantee) your bundle's classloader. You have a couple of options:
Configure the org.osgi.framework.bootdelegation property. This is probably implicitly set to sun.,com.sun. so you want to change it to be sun.,com.sun.,com.ibm.websphere.naming.* I believe this can be set in the servlet bridge wars WEB-INF/launch.ini
You could also import comibm.websphere.naming which would require you to add to the launch.ini org.osgi.framework.system.packages.extra=com.ibm.websphere.naming
Either should work.
Good luck.