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.
Related
I have listed a section of text files using my apache tomcat service.
I had enabled the directory listings in web.xml and I tried to edit one of the text files in my notepad++, but it was read only and hence I could not edit.
Is there a way that I can make these files write-able where I can just use the links and write or edit them either using notepad++ or geneos.
I tried giving the files "777", but still it did not work. Can someone please help here?
You have enabled directory listing. Which does exactly what you experience: It lists a directory's content.
You're asking for upload capabilities, which are not part of the directory listing feature. In fact, doing so would open a can of worms: What's up with concurrent changes to a file by two different people? Who'd win? Do you need locks? What kind of access control? Surely you don't want publicly writable content (as you indicate by chmod 777)
In other words: No, you can't achieve what you expect by enabling directory listing. How to do that is way beyond the scope of a stackoverflow question, and frankly, I'd recommend installing software that provides the capability. There are solutions that provide this feature and run on tomcat, but also some that run without.
And no, I won't recommend any of them, as I don't know your constraints and it'd be off topic on stackoverflow.
I'm using JCS 2.0 in order to create a cache system for my web application.
Since this application will run in different servers, which may have different home paths, I'd like to know if there's a method to programmatically change the disk path for the cache, or the only solution is to create a different cache.ccf file for each installation.
I've found only these 2 question regarding the argument:
this one refers to the 1.3 version, and I don't know if can be used in my case
this one seems the same question as mine, but has no answer.
Thanks in advance
I want my servlet to receive files in some folder under the application directory tree. The server accepts files in multipart/form-data format. I've understood that #MultipartConfig is the right attribute to mark the servlet code, to allow the server to create files. However, not every location is considered as safe, hence two questions:
Which are the limitations, when specifying the locations for file-upload servlets
Can the paths be relative to application path or they should be absolute?
The files must be downloadable afterwards, so in general, which is a best place on the server to keep the files it (under the application tree, out of the tree, out of Tomcat tree etc?)
Since annotation seems to be a very 'static' way to allow servlet download things, can the same be specified in web.xml, for example?
Thanks!
1: Which are the limitations, when specifying the locations for file-upload servlets
It needs to be readable and writable. It also needs to be an existing location, the servletcontainer won't precreate it for you in case of absence.
2: Can the paths be relative to application path or they should be absolute?
Both are allowed, as long as 1) is confirmed. The container will under the covers use java.io.File to denote the location. So using relative paths is definitely a bad idea.
3: The files must be downloadable afterwards, so in general, which is a best place on the server to keep the files it (under the application tree, out of the tree, out of Tomcat tree etc?)
Putting in webapp folder will cause them all get lost whenever you redeploy the webapp. It also won't work on some server configs since extraction of the WAR file is an optional configuration setting. So it's really better to put them on a fixed path outside the webapp folder. To download them again, just add a new <Context> to Tomcat or create a servlet which gets a FileInputStream from it and writes to OutputStream of the response. Examples can be found in this answer.
4: Since annotation seems to be a very 'static' way to allow servlet download things, can the same be specified in web.xml, for example?
Yes, you can just ignore the location attribute of the annotation altogether and use Part#getInputStream() to write it to the desired location. You can then specify the location as <init-param> of the servlet and initialize it in init() method.
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.
My problem is one that you would think is quite common, but I haven't so far managed to find a solution.
Building a Java web app under Tomcat 5.5 (although a requirement is that it can be deployed anywhere, like under a WebLogic environment, hence the loading resources as streams requirement). Good practice dictates that resource files are placed under WEB-INF/classes and loaded using the ClassLoader's getResourceAsStream() method. All well and good when you know the name of the resource you want to load.
My problem is that I need to load everything (including recursively in non-empty sub-directories) that lives in a subdirectory of classes.
So, for example, if I have the following under WEB-INF/classes:
folderX/folderY
folderX/folderY/fileA.properties
folderX/fileB.properties
I need the fileA.properties and fileB.properties classes to be loaded, without actually knowing their names before the application is started (ie I need the ability to arbitrarily load resources from any directory under WEB-INF/classes).
What is the most elegant way to do this? What object could I interrogate to find the information I need (the resource paths to each of the required resources)? A non-servlet specific solution would be best (keeping it all within the class loading framework if possible).
Thanks in advance!
As far as I am aware, there is no such ability, since the classloader only attempts to load things it is asked for. It doesn't pre-fetch all items on the classpath, or treat them as a directory structure.
The way I would solve the problem is create a directory listing in a text file of all relevant resources at build time and include that in the war, and then walk it through that way.
You can do that with some tricks :)
Get the resource as URL, extract the protocol :
file protocol - get the URL path and you have a folder, scan for files.
jar/zip protocol - extract the jar/zip path and use JarFile to browse the files and extract everything under your path/package.