External directory with static content in Tomcat with SpringMVC - java

I have an app which should save content (user avatars) in some directory, for example C:\avadir. In my app I'm using SpringMVC. I need to show user defined avatars. For this I have to configure Tomcat to use this external directory.
I have such opthions in my ROOT.xml, placed in %CATALINA_HOME%\conf\Catalina\localhost:
<Context path="/ava" docBase="c:/avadir" debug="0" reloadable="true" crossContext="true" />
and next settings in my servlet-context.xml:
<resources mapping="/ava/**" location="/ava/" />
After set up this settings I still can't get access to my file placed in C:\avadir\file.jpg by url localhost:8080/ava/file.jpg.
Is there something missed?

You can achieve what you want without modifying your ROOT.xml file which should make your application slightly more easy to manage.
So firstly I would remove the Context definition from ROOT.xml.
Secondly I would modify your current Spring MVC configuration to serve the images as part of the Spring MVC application. Using the path that you have suggested I would update your <resources> definition to:
<mvc:resources mapping="/ava/**" location="file:///C:/avadir"/>
This is essentially configuring your Spring MVC implementation to serve resources directly from the filesystem rather than relying upon the second context that you have configured in Tomcat.
You also need to remember that the Spring MVC resources mapping will be relative to the context of your web application. For example: if your application is deployed at http://example.com:8080/myApp then the /ava mapping will actually match when accessed with URL http://example.com:8080/myApp/ava/file.jpeg

Related

Java - Tomcat: Reload context.xml without restarting server

I'm using spring mvc and tomcat as a server. I want to be able to change a jndi field that is Autowired(as String):
<jee:jndi-lookup id="someMessage" jndi-name="someMessage"/>
in one of the my services, that is referenced to conf/context.xml of Tomcat, that looks something like this:
<Environment name="someMessage" value="Change this." type="java.lang.String" />.
However, when I change the value on context.xml, this change is not reflected on my service managed by spring, unless I restart server. Is there anyway to reflect this change without restarting or redeploying war? I know there is a solution to include such a dynamic field in one of properties file and then use commons configuration library to reload the changes, but I'm looking for a solution to keep this field on my conf/context.xml...
I think that is not possible. Why don't use a property file or a static class?
As far as I know, it's impossible if you put it into the conf/context.xml of your tomcat home as the following doc shows:
StandardContext.html#reload(): If the context.xml has changed, you should stop this Context and create (and start) a new Context instance instead. -- i.e. can't achieve by original context
Reload Existing App: Reload an existing web application, to reflect changes in the contents of /WEB-INF/classes or /WEB-INF/lib. -- i.e. not reflect the change of context.xml
But you can define your app's /META-INF/context.xml, which will be packed into war and you can replace war without restart server.

reflect on web-application changes in servlets class file

I just want to know how to make automatic reflect on web application if i make changes in my servlets class file .
Because when ever I make changes in servlets class file I have to do server shutdown and startup
Otherwise go to tomcat web application manager
And reload the web-application
Is there another method which automatic do this
Set <Context reloadable="true" />, Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development. But not in production environment. See the reloadable doc.
Edit:
How to set context
Edit install_dir/conf/server.xml and add a DefaultContext subelement to the main Service element and supply true for the reload able attribute
Add
<DefaultContext reloadable="true"/>
before the
</host>
tag.

off-the-shelf web application working directory

I've just started working with Spring/java web. I'm wondering how to accomplish following scenario:
Let's say that I'm creating an application which supports file upload, uses a database connection and maybe a web service. This is an off-the-shelf system, so all the settings are customer specific and should be configured by customer's IT people on the deployment time.
More general in the web.xml file I would like to point the application working directory containing uploaded files, license key file, configuration files, other customer specific resources and maybe even fragments of spring context.
<context-param>
<param-name>workdir</param-name>
<param-value>/var/r2/</param-value>
</context-param>
In my application I would like use the workdir value in order to include configuration files ...
<import resource="wordir_param_value/settings.properties" />
context config fragments
<import resource="wordir_param_value/security.xml"/>
And how may I later use these values in the java code? What is "the best" approach in case like this anyway (off-the-shelf application config)?
Best Regards,
Alek
You can use Spring's property support for that. This allowed two different approaches:
Having a property file outside the application (at a fixed location), the admin can edit it, and the application loads it
In a Tomcat you can write properties in the application specific context.XML file
In the code use #value annotation to inject the properties in a variable.
In the spring XML file you use it with ${name}
Of course you need to configure the proprtyPlaceholderConfigurer

context.xml vs web.xml in web application

I am developing a small web application application. The objective is to create one welcome index.html page with Ajax + one servlet to handle ajax requests.
Although I thought I would be fine with a web.xml only, I don't want to deploy to /, but to /MyApp. NetBeans's project properties offers options to set a context path, which helps me deploying to /MyApp. However, it automatically adds a /META-INF/context.xml file, which is a bit confusing.
My questions are:
1) Do I really need a context.xml file do deploy to /MyApp instead of /?
2) If answer to 1) is no, how to accomplish the same with web.xml only?
3) What is exactly context.xml to web.xml?
/META-INF/context.xml is a Tomcat-specific config file. It's used to configure how your app is deployed to Tomcat, including, among other things, the context path at which it exists. Other containers have similar files that can be included in a WAR for container configuration. To answer your questions:
No. The embedded context.xml is only one way to set the context path, and as I indicated, it'll only work in Tomcat. In Tomcat, default behavior is to deploy webapps to a context that has the name of the war file, without the ".war" extension.
You can't set a context path in web.xml. That's your application's deployment descriptor. It configures your application, and the context path is external to your app. It belongs to the server/container you're deploying the app to. Configuring a context path is always done in the container's configuration.
If by "config.xml", you meant "context.xml", then I think I've already answered that. If not, clarify your question.

How do I list files in web folder of a different java web application

I need to list files under a folder of a different web application. Is there a way to get this done without having to provide the actual path in a properties file?
Webapps
- WebApp1
-MyFolderOfInterest
- WebApp2
- WEB-INF
- Classes
- MyClasstoListFiles
TIA
Yes, in a servlet of yours:
getServletContext().getContext("/WebApp1").getResource("/MyFolderOfInterest")
The important things here is that you gain access to a ServletContext different than the one you are currently in. See the documentation of getContext()
And in order to make a context eligible for access from other contexts, for WebApp2 you need a context.xml (in META-INF, for example) that contains:
<Context crossContext="true" ... />

Categories