Develop Reference

Reference properties files in WAS v8.5

We've purchased a thirdparty servlet that references a properties files from web.xml (i.e. d:\projects\MyProp.Properties) . Since moving to Websphere v8.5, we can no longer have the properties file on a logical drive and have to place it inside our app's project. However, we do not have access to the code to the servlet that open/references the properties file. I've tried changing the properties reference to \WEB-INF\MyProp.properties but it's not found during server startup.
Is there a project reference I can use in web.xml allowing the servlet to open the file?

Here's my solution - because we have a NAS location where we place all the .jars that our WAS v8.5 compatible applications can access, I placed the properties file there, updated the path to the file in web.xml and viola, the servlet was able to access/open/read the properties file!
\is2-cifs.domainname.com\sbl_prod$\propertiesfolder\MyProp.Properties

Creating A File Resource Using Tomcat JNDI

I need to read an application.properties file from a servlet application using Tomcat container. The file can not be included in my war so it can't be under webapps or Tomcat root folder in any ways. The file has to be somewhere in the folder. I also can not use FileInputStream to read the properties file. Only option I have is to define a JNDI name for a folder / directory and look that JNDI properties during runtime to find the folder location to read the file. Is thee any working example out there?

I have chalked out a solution for myself reading the following similar posts and articles.
The Context Container
Reading a global variable from tomcat with JNDI. Example not working
java:comp/env is not bound
I have defined a Environment inside my Context for my web application under
\conf\Catalina\localhost\mywebapp.xml as follows....
<Environment name="propertiesfilelocation" value="E:\\tmp\\application.properties"
type="java.lang.String" override="false"/>
Then accessed my properties file using a JNDI lookup to get the file name.
Context ctx = new InitialContext();
Context envCtx = (Context)ctx.lookup("java:comp/env");
String propertiesFileLocation = (String) envCtx.lookup("propertiesfilelocation");
LOGGER.info("String property === " + propertiesFileLocation);
properties.load(new FileInputStream(propertiesFileLocation));
#home : Yes you are right it involved FileInputStream. However, I am happy with the solution because I am no longer hard coding my folder location inside my Java code which makes my app more portable.

I have a slightly different approach to a similar problem. I also toyed with the idea of JNDI but I found this a bit of overkill.
I found another article by BalusC. It allows you to specify folder relative to your tomcat installation and deploy all your properties files there. So you keep configuration external to your application but you don't require seperate configuration for every properties file for every app.
Here it the link:
Where to place and how to read configuration resource files in servlet based application?
and the preferred choice is as follows:
Put it in the classpath, so that you can load it by
ClassLoader#getResourceAsStream() with a classpath-relative path:
Properties properties = new Properties();
properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("filename.properties"));
Here filename.properties is supposed to be placed in one of the roots
which are covered by the default classpath of a webapp, e.g.
webapp/WEB-INF/lib, webapp/WEB-INF/classes, appserver/lib or JRE/lib.
If the properties file is webapp-specific, best is to place it in
WEB-INF/classes. If you're developing a project in an IDE, you can
also drop it in src folder (the project's source folder).
You can alternatively also put it somewhere outside the default
classpath and add its path to the classpath of the appserver. In for
example Tomcat you can configure it as shared.loader property of
tomcat/conf/catalina.properties.
I hope this helps.
Allan

Tomcat: Get short URL for Jersey based Rest Service

I have a Jersey based Rest service running on a tomcat server. There is no UI, just a server that offers some rest services. Now, to access this service the URL that i have to type in is pretty long. Something like localhost:8080/MyApp/url_pattern/classPath/method where MyApp is the webapp that i deployed, url_pattern is the pattern that i defined in the servlet-mapping in web.xml, classPath and method being the #Path annotations for the Class and method respectively. Is it possible to shorten it such that I get rid of the MyApp and url_pattern part of this URL. Something like localhost:8080/classPath/method.
PS: There is just one webApp running on this server, so no point having the MyApp part

I don't think you can remove all what you desire from the url but you can definitely remove the MyApp part by making it the root application for tomcat.
Answer on this related link describes it pretty well, how to set your application as the root application. So you can access your REST services without having the app name in url:
Setting default application in tomcat 7
Content copied from the above link:
First Method:
first shutdown your tomcat [from the bin directory (sh shutdown.sh)]
then you must delete all the content of your tomcat webapps folder (rm
-fr *) then rename your WAR file to ROOT.war finally start your tomcat [from the bin directory (sh startup.sh)]
Second Method:
leave your war file in CATALINA_BASE/webapps, under its original name
- turn off autoDeploy and deployOnStartup in your Host element in the server.xml file. explicitly define all application Contexts in
server.xml, specifying both path and docBase. You must do this,
because you have disabled all the Tomcat auto-deploy mechanisms, and
Tomcat will not deploy your applications anymore unless it finds their
Context in the server.xml.
Note:
that this last method also implies that in order to make any change to
any application, you will have to stop and restart Tomcat.
Third Method:
Place your war file outside of CATALINA_BASE/webapps (it must be
outside to prevent double deployment). - Place a context file named
ROOT.xml in CATALINA_BASE/conf//. The single element in this context
file MUST have a docBase attribute pointing to the location of your
war file. The path element should not be set - it is derived from the
name of the .xml file, in this case ROOT.xml. See the Context
Container above for details.

In Tomcat 7 do you need to copy context.xml into conf/Catalina/locahost for it to take effect

Just moved from Tomcat 6 to Tomcat 7 and noticed that when you deploy a webapp called widget the META-INF/context.xml no longer get copied to conf/Catalina/localhost/widget.xml.
What Im unclear about is whether it needs to be, will the settings in context.xml be used if left in META-INF or do they only have effect if moved to conf/Catalina/localhost/widget.xml
Im using a vanilla tomcat 7 installation

See the documentation (my emphasis):
Individual Context elements may be explicitly defined:
In an individual file at /META-INF/context.xml inside the application
files. Optionally (based on the Host's copyXML attribute) this may be
copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
application's base file name plus a ".xml" extension.
The documentation for Host has this to say on copyXML:
Set to true if you want a context XML descriptor embedded inside the
application (located at /META-INF/context.xml) to be copied to xmlBase
when the application is deployed. On subsequent starts, the copied
context XML descriptor will be used in preference to any context XML
descriptor embedded inside the application even if the descriptor
embedded inside the application is more recent. The flag's value
defaults to false. Note if deployXML is false, this attribute will
have no effect.

As I understand it, the context.xml in META-INF is used unless the element deployXML is set to false. Note from the Tomcat 7 docs, the default is true unless a security manager is enabled!
However, from the docs, I was under the impression that setting the copyXML attribute in the context.xml itself (without touching server.xml) would cause the file to be copied to conf:
<Context antiJARLocking="true" path="/widget" copyXML="true" />
However, using Tomcat 7, it seems that the file doesn't get copied to conf unless the copyXML is set to true on the as Frank answered above.

customize web application root context in apache

I have web application abc.war and I want to deploy it on Apache Tomcat.
The problem is that, by default, the path to this application is http://<server-name>/abc
but I want to access it as http://<server-name>/xyz.
I put into WAR's META-INF folder the file context.xml that is :
<Context path="/xyz" docBase="abc" override="true" />
The application WAR abc.war is located under %CATALINA_HOME%\webapps and it is extracted to %CATALINA_HOME%\webapps\abc folder.
Also, while deployment, the file context.xml from abc/META-INF is copied to %CATALINA_HOME%\conf\Catalina\localhost as abc.xml
It seems that this should work, but I still can't access my application through http://<server-name>/xyz, but only through http://<server-name>/abc
In addition, I still see in apache log the following line while deployment of abc.war :
context path = /abc
Could anybody, please, help while this doesn't work, or tell if there is any way of deploying of web application on apache such that application could be accessed by customized path (that does not relate to war-file name) ?
Thanks in advance.

Take a look at the docs:
The context path of this web application, which is matched against the beginning of each request URI to select the appropriate web application for processing. All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are defining the default web application for this Host, which will process all requests not assigned to other Contexts.
The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file or the docBase.