Attachments in Play! Framework on dotcloud - java

I uploaded files to the server using BLOB db type on play framework. In the application.conf file I have
attachments.path=home/dotcloud/uploads
But I couldn't find the files on the server.
The issue is that if I restart my www service, then I lose all my files, I only have the db records.

I believe that there are two issues in here. First your path lack a initial '/' to be a full path (I'm assuming that was your intention):
attachments.path=/home/dotcloud/uploads
Second, I'm not sure that your Play server will have rights to write to that folder, as it's outside the application context path. Default folder is local to the application and Play can write it, not so sure about other folders though. You should double check that.

Related

Servlet external config file requires full path

I've looked at a number of related cases here on stackoverflow related to this, but mostly deal with the situation of deciding where to put external files and access them, which is quite clear.
In my situation, I have a Java EE application that needs to use a third party library that reads an external config file to determine the location of another file. I am using Eclipse and Tomcat.
The external config file has a line that reads like: FILENAME=[path], where path is expected to be the full path name to the file.
I have no way of knowing how they access the file, save to say that specifying /WEB-INF/classes/file or just file does not work, the library can't find it. However when I put the full name /Users/.../file on my local machine, it can find it.
As this is intended to be deployed on production server in the cloud, is my only solution to put the needed file in cloud storage, then set the config file to point to this absolute location ?

Why can't acess .properties file when running on Apache Tomcat Server?

So I have a problem: I have a Java project that connects to a DB and has some logic then answers via a RESTful Webservice request.
The thing is the connection do my DB was fixed (only connected to one DB) and hard to change because in the end I create a .war file, so for someone to use the .war it had to use the same DB connection settings and names.
Therefore I created a .properties file inside WebContent/WEB-INF/ (so the path is WebContent/WEB-INF/config.properties). When I run the project locally it works fine, the minute I run it on the Apache Tomcat Server it says he can't find the path specified, thus the NullPointerException.
Would appreciate if someone could shed some light on the issue. Thanks to all.
PS: Sorry for mispelling and bad formatting.
When you create a WAR the path of all the files are set relative to the context root (though in actual file system you can still figure it out in tomcat/jboss etc. it is not recommended to access files that way). The files can be got hold of through standard getResourceAsStream with relative path to the files /WEB-INF/config.properies

How make working directory files available to WebStart application?

We have to make a Java application demo available on Internet using JWS. It goes pretty well; all that's missing is making working directory files available for the application.
We know about the getResource() way... The problem is that we have different plugins for the same application and each one require different files (and often different versions of the same files) in their working directory to work properly. So we just change the working directory when we want the application to have a different behavior.
Currently, the demo is packaged in a signed jar file and it loads correctly until it requires a file from the working directory. Obviously, the Internet users of this demo don't have the files ready. We need a way to make these files available to the WebStart application (read/write access) in its working directory.
We've thought of some things, like having the application download the files itself when it starts, or package them in the jar and extract them on startup.
Looking for advices and/or new ideas. I'll continue working on this... I'll update if I ever find something reliable.
Thank you very much!
I said I would share what I found in my research for something that would fit my needs. Here's what I have so far.
I have found that the concept of current working directory (CWD) does not really make sense in the context of a Java Web Start (JWS) application. This had for effect that I stopped trying to find the CWD of a JWS and started looking for other options.
I have found that (no, I didn't know that) you can refer (using getResource()) to a file in the root directory of a JAR file by simply adding a '/' in front of its name. ("/log4j.properties", for example.) The impact of this is that I can now take any file which is only referred to in a read-only manner in the root of that JAR file (which is really only a ZIP file). You can refer to any file in the root of the JAR file using AnyClass.class.getResourceAsStream. That rules out the problem with read-only files required to run the application, at the cost of a switch in the code telling whether the application is run from a valid CWD or from a JWS context. (You can very simply set a property in the JNLP file of the JWS application and check if that property is set or not to know where to look for the file.)
For write-only files (log files in my case), I used the property , adding a directory with the name of the application: <user.home>/.appname and added log files to it.
Read/write files (which I don't have in my case) would probably simply go at the same place than write-only files. The software could deal with uploading them somewhere if needed, once modified, I guess.
That's the way I deal with the problem for now.
Note there is a service you can explicitly ask for, to get file access to the computer (unless you go all the way and ask for full access (which requires signed jar files)).
Then you need to determine where these files need to go - basically you have no idea what is where and whether you may actually write anywhere. You can create tmp-files but those go away.
Would a file system abstraction talking to the JNLP-server do so you store the users data on the server?

problem with storing data in datastore

I am facing a problem with file upload.I have used Apache Commons
servlet file upload for uploading the file. Though the file is getting
uploaded and the data is getting stored on the local server(http://
127.0.0.1:8888/_ah/admin/datastore) but it is not going to the Google
App Engine datastore.
What I am doing is loading
the file as a stream and immediately parsing the stream and creating
datastore entities with the data. I am not actually trying to save the
file. In the local server it works. It even works when I try to access
the local server from another machine. However it does not work when I
deploy it to Appengine using the Google Pluggin for Eclipse. My parsing
code depends on resource files which are under the web-inf directory.
Is it possible these resource files are not getting uploaded and is
there a way to check what files are uploaded on Appengine?
Whatever's in your .war is going up into AppEngine. I don't see how parts of it will be selectively excluded. What's more likely is that your application is depending on stuff that is lurking SOMEwhere on your PC but not included in that .war file.
However, shouldn't your application be checking for those resources and throwing exceptions if they are not found? If it's failing silently, I'd consider that a design flaw.
Logging a lot may help you debug the problem. You can look at your program's logs via the AppEngine console. I recommend more error checking and logging.
Something else to check for is to not be running the version of your software you think you are. There's a kind of versioning mechanism that allows you to deploy different concurrent versions of your and only one will be actually accessible. One of the things you should be logging and/or making otherwise accessible is some version information (perhaps even including a build timestamp) for your app's build.
The files in the .war folder are executed in the app engine and the others are uploaded. What you need to verify is the path you have set and the path of you source java file and the file you are reading. You cannot use the local file system path in app engine. You need to include the file in your project

War-file deployment with shared resources

Consider the following example structure
- Project
- www
- files
+ documents
+ html
+ images
+ scripts
- WEB-INF
* web.xml
The documents folder needs to be a symlink or in some other way external from the war file because users will add and remove documents (through a mapped network drive).
I'd like to deploy the webapp as a war-file but I don't know how to do that and take the above into account. Could you give some pointers?
/Adam
If it's static content, maybe you'd be better off fronting your app server with a web server and putting the static content there. You relieve the app server of having to serve up static data and save a network roundtrip to boot.
I agree with #duffymo.myopenid.com that fronting your app server with a web server that serves static content for certain URL prefixes is a good, clean solution.
If this isn't feasible in your environment or if you decide that you'd rather handle it in the web application itself, you could write a servlet that effectively does the same thing. For example, create a servlet that is mapped to the URL pattern /documents/*. This servlet could parse the URL (/documents/some/file.png) to determine a relative filename (some/file.png). It could then read and return the corresponding contents found in an external directory (/staticDocs/some/file.png).
Why not store the documents etc. in a database, then have the web-app access the database and allow users to pull files that way? Does it have to be a mapped network drive?
Otherwise if it's a matter of knowing what is there, you could always construct the jnlp file dynamically and pass file lists, etc. in as arguments (if they are server side).
Guess we need to know a little more about what you are trying to accomplish.
Basically, it's a webapp that aggregates information from various sources and generates documents. It's a requirement that users have the ability to create and upload documents manually from the network without being logged in to the webapp.
Putting the document location path as a context variable is definately doable. I guess it's the easiest way. /Adam
Unfortunately, for you .war files are .zip files at heart and .zip files do not support symbolic links. If you are ONLY deploying to a windows machine you may have luck using a shortcut file. However, I'm not sure if the app-server will like that (... probably not.)
I would recommend adding a configuration parameter to the application that allows the document folder's full path to be specified there. The default path should be relative ("./www/files/documents") so that the app works out of the box without additional configuration.
Many java web servers support "exploded war files" where you just unzip your .war file into the deployment directory. With tomcat you copy this to $CATALINA_HOME/webapps and you're done.
This should work for you.
What about creating an environment variable on your server that points to the directory the files are stored in? The environment variable may work better than a setting inside your WAR file because you could deploy your application in a new environment (maybe moving from DEV to PROD) without changing your WAR file.
From your java code, you can reference this environment setting with:
String docPath= System.getProperty("DOC_PATH");
In Apache Tomcat it may sometimes be appropriate to achieve reuse via the tomcat RewriteValve like this:
META-INF/context.xml:
<Context>
<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />
</Context>
WEB-INF/rewrite.config:
RewriteRule (.*)/login(/.*\.)(png|jpg|js|css) $1$2$3
Now the /appContext/login/ path will use the same images/js/css as /appContext/
Of course as with all regular expression based solutions to ANY problem, keeping the complexity of the expression low is important for performance.
Sounds like you need a web Content Management System (CMS).

Categories

Resources