Accessing a web application context from "outside"

[john_brinnand]

If a class is outside of a web application context, how should it access resource in the web context. (Besides putting every resource in WEB-INF/classes?????)

The ContextLoader in web.xml is aware of resources directly below WEB-INF. However the resource locator (SingletonBeanFactoryLocator) is looking for resources in the classpath: WEB-INF/classes and WEB-INF/lib. While this is compliant to the Java Servlet Specification, it poses quite a problem: If we use the SingletonBeanFactoryLocator to learn of resources in WEB-INF then all references to resources inside the applicationContext files under WEB-INF must be in the classpath. This can create a conflict with the ContextLoader. So......

How can we get the ClassPathXmlApplicationContext to load resources from WEB-INF, such that other non-web aware classes can access them.

[Costin Leau]

there are various ways you can work around the problem. You can use the FileSystemXmlApplicationContext which doesn't care about classpath. you can put the location into some property or add some small functionality inside your webapp which can automatically detect the path so your other classes can ask the web application for its file path.
You can also use JNDI so that once the webapp starts it will put its location inside the JNDI and other classes can take it from there.

[john_brinnand]

Yes - we have visited many of these potential solutions:
------------------------------------------------------------------------------------------------------------------------
FileSystemApplicatonContext: takes the root of the filesystem from the JVM. So the directory from which tomcat is started is the root of the URL. We have found that if, for instance, we start tomcat from /usr/local/tomcat/logs then the FileSystemApplication context uses that containment hierarchy as the root of its resource path. So, we have to develop workarounds for this. Also, Spring recommeds that we not use FileSystemApplicationContext except for standalone apps.
------------------------------------------------------------------------------------------------------------------------
ClassPathXmlApplicationContext: placed in the locatorFactorySelector <context-param>

<param-name>locatorFactorySelector</param-name>

<param-value>beanRefApplicationContext.xml</param-value>

</context-param>

<context-param>

<param-name>parentContextKey</param-name>

<param-value>mainApplicationContext</param-value>

</context-param>

beanRefApplicationContext
<beans>
<bean id="mainApplicationContext" class="org.springframework.context.support.ClassPa thXmlApplicationContext">
<constructor-arg>
<list>
<value>applicationContext.xml</value>
<value>dataSourceApplicationContext.xml</value>
</list>
</constructor-arg>
</bean>
</beans>
__________________________________________________ __________

This has the obvious consequence of having every resource in the classpath (WEB-INF/classes or WEB-INF/lib).

getApplicationContext() from a Controller that inherits from AbstractController gives us the ApplicationContext we require and what we have done is pass that around in a Map to all dependent classes.

So, I guess the message is: we are on our own on this one. I was hoping for a more seamless methodology but I guess there is none. So we will use whats at hand and work it out.

Many thanks for your reply,

John

[zlendon]

I think there are other options (I'm presuming your non-web-aware classes run in the same container as your "web-aware" classes)...

What I have done before is have a servlet that extends HttpServlet. Have a static, private, non-final class variable representing the context; in the init method of the servlet, put

ServletClassName.context =
			WebApplicationContextUtils.getRequiredWebApplicationContext(
				getServletContext());

Load this custom servlet after ContextLoaderServlet/ContextLoaderListener in web.xml - so that the web application context is ensured to already be initialized. Have a static public getter (getWebApplicationContext()) to retrieve your 'context'. Therefore - no need to pass things around.

I would imagine that part of the argument against an "elegant" solution like your requesting is having dependencies wired in via Spring, instead of retrieved through the application context. The reason I had involvement in the above solution is we had classes not managed by Spring (because of their legacy beauty), but they were classes which we wanted to leverage Spring against. This may or may not be similar to constraints you are under.

[john_brinnand]

Thanks for the reply. We will give it a try.

John Brinnand