Use Tomcat to serve a directory? - java

I have a directory on a linux box that I want to make publicly readable using Tomcat (5.5). I think this is easy to set up but can't find the appropriate documentation. Is there a simple way to accomplish this?

It is possible by defining that directory as an web application, but it's not really what Tomcat is designed to do, other servers are far better at serving static content.
The way to define a directory as a webapp is to either
put it into $TOMCAT_HOME/webapps,
configure it in $TOMCAT_HOME/conf/server.xml or
provide a context .xml file and put it in $TOMCAT_HOME/conf/Catalina/localhost (by default, depends on your configuration).

You can just link it to a folder under webapps as a new "web application".
ln -s /path-to-real-folder /path-to-tomcat/webapps/publicfoldername
If I remember correctly, directory listing is enabled by default in tomcat, so the dir would be reachable. If not, this can be fixed in web.xml

Although Tomcat is a good web server, it's not particularly made to list directories.
You might want to look at a web server like the Apache web server instead, it's more designed for this type of thing.

Related

Given a JAR file, allegedly contains web server, how do I deploy it?

I've been handed a JAR file, told it contains a web application, and instructed to deploy it. I'm familiar with java as a language, but I have next to no experience with its web ecosystem. Trying to run it as an executable, I find out it has no main class, so I take a look at the contents, and find that it has a META-INF/web-fragment.xml file, along with a couple of Servlet classes and some config files referenced in the xml. It looks like there is basically everything here for a complete application, but I have no idea how to actually deploy it, and google only yields tutorials on how to build these things from scratch with IDEs and deploy using maven plugins and goals.
Assuming that building from source is out of the question and I only have standard unix and java CLI tools available, based on the information provided (And I can provide more if necessary), what is the simplest way to get this up and running?
A web applicaton should be in a WAR file, not a JAR file, and you should only need to just drop it into the webapp directory of your Tomcat, or follow the instructions for whatever other container you're using.
If it's only a fragment, as appears from the XML, (a) it isn't a webapp, only part of one, and (b) you personally can't deploy it at all. You need the whole thing.
Send the assignment back for clarification.

Use custom paths to store config files in Tomcat

In embedded-tomcat can we use our custom web.xml, server.xmlandcontext.xml files? If it is possible, can we use a custom location to store them and point that location?
It would be great if someone can point an example
I'm using Tomcat version 8.0.20.
My understanding is that these configuration files are not directly supported for an embedded Tomcat implementation. The answer to https://stackoverflow.com/questions/32958412/passing-a-custom-server-xml-file-to-standalone-tomcat-embedded-tomcat has more detail.

Real path to a virtual directory

I setup a mapping to my images directory in Weblogic.xml by using the virtual-directory-mapping tag. How can I read the value of the real path so that my application can access that virtual directory for write access?
JMX seems to be of no help here since the WebServerMBean (or any other MBean) doesn't seem to provide access to the virtual-directory-mapping property.
Java Servlet API also has not yielded result since calling getRealPath() is only appending the url-pattern to the deployment directory of the application and not giving the correct path.
<virtual-directory-mapping>
<local-path>/home/wlsadm/images</local-path>
<url-pattern>help/specimens/*</url-pattern>
<url-pattern>*.xml</url-pattern>
</virtual-directory-mapping>
I've done a fair amount of research on this, reading vendor documentation, reading blogs, forums, etc. As the OP indicated, JMX use to be an approach to get this information, but this is no longer an option in current Weblogic versions.
The only solution I think you're left with is to create a utility that reads the information from the weblogic.xml file on the classpath. Something like an application listener that reads it on application startup and makes it available as a servlet attribute, etc.
Would love to hear how you solved it, though.

How to convert EAR as executable file?

I have no idea about converting EAR file into exe(Executable file), Where are i am working with jboss and i developing webservices. I want to give my product as executable file . Can anybody has idea about this.
Thank you
Gobi, you've already posted a question regarding this on 15th March, to which you've got no response. I guess you've just rephrased that same question here.
Might I suggest asking your customer/client how she would like the web service 'ear' delivered? I'm also guessing you might have database scripts, properties/config files etc. I'd put my money on 'a zip containing the ear, database scripts (if any) with related documentation'
There is no way a customer would want to 'double click' your ear and have it installed directly onto a server. If you read your Java EE spec correctly, you'd find a 'deployer' role in there. Its not there for fun. Its a very serious role whose responsibilities include 'configuring' your application.
Think about it.
You mean you want customers/users/whatever to just be able to double-click on your file, and there's a web server up and running? While that would be possible, it's not really the way most people want to run web services. They're very likely to want to run your web service within an existing container, configuring it alongside other services.
An EAR file is already designed to be pretty much droppable within a container, so that's fine. You could also supply a zip file (or an installer) with a sample container setup using any of the free container implementations - either preconfigured with some reasonable default values (e.g. for the port) or running through an installer wizard. I wouldn't spend too much time on it though - I'd assume that most people who want to run a web service will already have some experience of setting up a container, or will have specific requirements you couldn't easily capture in a wizard without a lot of work.
I don't know about making EAR as executable.
There is a editor which converts your project into setup file or installer for windows .
Hope this helps.
I used NSIS editor and recommend it and it only creates installer for windows.
HM NSIS Editor.
you may also have look at izpack

Where/how to store persistent data with tomcat?

Where should I store persistent files in a Tomcat web app ?
javax.servlet.context.tempdir is not feasible, it's erased when the app is redeployed/removed
Don't want to use an absolute path in e.g. servlet init parameters
Storing the files in a database is not an option
Our team does this a lot. A general rule we follow is outside the web app and outside Tomcat.
Our sysadmin set up a directory on our server that the tomcat user has rw permissions to (e.g. /var/tomcat/persist). We have a built a directory structure under this that tomcat uses to store files, read app-specific init files, etc.
If you don't want to use an absolute path in your init-params for your servlet, consider setting a system property when tomcat is started up. The good thing about that is every application running under tomcat will have access to it. The bad thing about that is every application running under tomcat will have access to it. You could set a property named base.persist.dir and build subdirectories for each application underneath it. We set system properties in the setenv.sh script in the bin/ directory under the CATALINA_OPTS environment variable.
Answering the title of the question, what about using a database, a DataSource and JDNI? Even in a web only context, writing to files using java.io is not really recommended because of concurrency, threading, security, clustering, portability issues. Some of these problems can be "workarounded" but still, this is not really a best practice. The standard approach is to use a database and I'd suggest to reconsider this option, throwing "file-based" lightweight database like HSQLBD or JavaDB into the mix.
(EDIT: For an unknown reason, database is not an option. Using JNDI or context parameters or init parameters to pass an absolute path - which are the less worse options IMHO - is excluded too. For a relative path, maybe look at user.home or user.dir then - or any other system property that you could pass on the command line. I don't like it, I wouldn't do it, and this doesn't solve the issues previously mentioned, but it's your choice after all.)
Storing the files in a webapp directory under the home directory of the user running Tomcat is a good and convenient option. It is outside of Tomcat, which means it will survive redeployment, and it is usually a writable directory (because it is created under the users' home dir).
But it is always a good idea to allow overriding the location of such directory via system property.
Generally, this would go to the database. But since the OP insists on not using a database, I'd try a different approach:
Filesystem path which is known: ${user.home}/.myapp. Applications sometimes use this for e.g. search indices which can be recalculated based on data in the database. Might be okay for your use case to use the user's home.
Store the configurable filesystem path in a configuration repository such as the database or perhaps Java Preferences (if you don't like to use servlet init params). Commercial applications such as Atlassian JIRA use a configurable (but absolute) filesystem path where they store issue attachments. If they don't know a better way, i don't know who does :)
I generally would suggest to use a database to store persistent data and expose it via a DataSource.
If you don't want to do that, I guess you could consider using the "user.home" system property (I have seen this used in a few circumstances). But... there are no guarantees that your servlet will be run with permission to write access unless you configure that yourself.

Categories