Where should i store uploaded files? SEAM,JBOSS AS

[microcz]

Hi everybody, i'm experiencing problem with my web photo gallery application, i don't know where should i store photos after users will upload (if i don't want to put them in DB)

On localhost there is no problem, because i have writing rights everywhere so i'm using  System.getProperty(jboss.server.home.dir), which points to .../jboss-4.2.3.GA/server/default directory
But what if i wanna use some java hosting, where am i allowed to store uploaded files?
Could you help me please?

[nickarls]

Any special reason you don't want them in a DB?

[ericjava.eric.chiralsoftware.net]

It would be nice if there were some API to access a file system storage facility from within an EAR, but there isn't.  Note that the files themselves would not be stored within the EAR.

The best you can do is have a configuration setting within the EAR to point to some other directory on the server.

Or drop it all into the DB.

[jnusaira]

Not that i am this OP .... but i generally hate the idea of storing photos in the db. Tends to make the database artificially larger, that and I just dont think its the proper place unless you are having to version the files in your code ... or need to preserve file names.

Also the files can be incredibly large.

To the OP .... my answer would be one of two.

It depends first of all do you want these files directly linked on your site or do oyu want them to go through a middle man app.

If you are going directly and you have apache in the front end i'd just create a director like /myimages .... and tell apache NOT to forward to jboss that directory.

If you want redirection (ie have some code serve them up) Just put them anywhere and make sure that directory has read/write (no execution) permission for whatever you are running the app server as.

[luxspes]

Eric H wrote on Oct 27, 2008 21:37:


It would be nice if there were some API to access a file system storage facility from within an EAR, but there isn't.  Note that the files themselves would not be stored within the EAR.

Yes, if we only had something like java.io in java... wait! ;-)

The best you can do is have a configuration setting within the EAR to point to some other directory on the server.

Or drop it all into the DB.

[luxspes]

Joseph Nusairat wrote on Oct 27, 2008 21:57:



Not that i am this OP .... but i generally hate the idea of storing photos in the db. Tends to make the database artificially larger, that and I just dont think its the proper place unless you are having to version the files in your code ... or need to preserve file names.

I think it is better to put user uploaded images on the db, that way if you need a backup you only have to backup the database and you have saved all you data. I have seen to many cases where all uploaded files (images or other stuff) just get lost because nobody backups them.

Also the files can be incredibly large.

AFAIK they do not get any bigger because they are in the db. I agree that backup files can get a lot bigger, but in that case it can be a good idea to keep all you images in a separate Schema/Database, in that way keep the backups of you main tables small, and still leave the responsibility of backuping the user's data to the DBA.

[luxspes]

Maybe getRealPath can help you?:

@In
FacesContext facesContext;

javax.servlet.ServletContext servletContext = (ServletContext) facesContext
                    .getExternalContext().getContext();
String ruta = servletContext.getRealPath("");

[jnusaira]

I was speaking more generally about the files being large.

The files we are uploading for our system can be anywhere from 500MB to 4GB.

Again though largely depends on context IMHO .... i've done it both ways .... also how close the images are tied to the actual data being stored.

[jnusaira]

Why would you be needing the path to the EAR.

IMHO if you are going to store on the file system store it in a location outside of the jboss deploy or anywhere near taht directory.

Then just set it as a system.property or as a configurable variable when you deploy like in the components.property file.

[dro_k]

I keep seeing these posts about people storing files in a database. I think it's really bad design... even borderline insane for the following reasons:

1. 1 Databases aren't really designed for this.


2. 2 Databases are a LOT less reliable than file systems.


3. 3 Databases are a LOT less scalable than a simple NFS style file system.


4. 4 Databases suck when it comes to streaming binary data out of columns.


5. 5 You can't query these BLOBs, so what's the added value of the database here over NFS?

I don't see ANY advantage to storing large binary data in a database. I think the only reason databases added support for BLOBs and like was because of the good ol if you only have a hammer all the problems look like nails problem of the developers and the DB vendors saw a good opportunity to add an extra feature to their products.

That being said, the database IS THE MOST unsalable part of any large scale software product. So you always want to delegate only the absolutely necessary tasks to it.

cheers,
DK

[nickarls]

Well, direct access to the FS is faster etc (less moving parts) but as the OP stated, when using hosting this is not always available (appserver running as separate user without home dir or limited disk access due to security reason).

But since you started ;-)

You can store metadata and query that. And with proper(tm) blob handling, they shouldn't be much more than a thin layer over the stuff on disk performance-wise. When you have a nail, a rock is better than nothing at all.

[fernando_jmt]

You can take advantage of the JBoss property service.

• Open the file /jboss/server/default/deploy/properties-service.xml, and add the following code within the SystemPropertiesService mbean:

<attribute name="URLList">
      ./conf/myapp-configuration.properties
</attribute>

• Put the myapp-configuration.properties within /jboss/server/default/conf


• In the myapp-configuration.properties you can add any application specific configuration property, like this:

myapp.folder= /anyfolder/myappdata/

• Such properties are added to the system properties, so from your application you can get them like this:

String path = System.getProperty("myapp.folder");

Of course you can change the paths listed above as your convenience.

HTH.

[obfuscator]

I can recommend using a transactional file store or avoid name collisions as much as possible if you want to keep your sanity when volumes increase.

[matsreinsby]

Hi all,
I've uploaded an image file to the server, but I can't seem to get access to it afterwards. I've tried two different approaches:
1. Files saved directly under jboss deploy folder
  - The file is only possible to use in a h:graphicImage... after the server has been restarted (or at least the app)
2. Files saved on the HD outside of jboss
  - Can't figure out how to refer to the image in the value or src attribute

So, uploading works fine, but I can't access the file (preview) after it's been uploaded.

Any hints?

[luxspes]

Drew Kutcharian wrote on Oct 28, 2008 07:52:


I keep seeing these posts about people storing files in a database. I think it's really bad design... even borderline insane for the following reasons:

Databases aren't really designed for this.

Yes, those BLOB and CLOB types should be there just for you amusement ;-)

Databases are a LOT less reliable than file systems.

Such a general statement is plain is ridiculous. What databases agaist what filesystems? xBase files vs NTFS? NTFS wins, but ext2 vs Postgresql? Postgresql wins, xBase vs MySQL, they are both crap...  it all depends on the case, but filesystems tend to get a lot more contamited by virus, garbage temp files, etc, etc. And it is really uncommon to have someone in charge of keeping them backed up, unlike databases where the it is the dba job to keep the database safe.

Databases are a LOT less scalable than a simple NFS style file system.

Again, under what conditions, comparing what database with what NFS running over what Unix? because UFS is a pice fragility crap worse that old xBase files.

Databases suck when it comes to streaming binary data out of columns.

Care to present some evidence of that please?

You can't query these BLOBs, so what's the added value of the database here over NFS?

Single point of backup, portability of the database across OSes, transactional and journaled and audited access to those BLOBs, etc, etc

I don't see ANY advantage to storing large binary data in a database.

If you can not see the sun because you are blind, that doesn't mean the sun doesn't exist ;-)

I think the only reason databases added support for BLOBs and like was because of the good ol if you only have a hammer all the problems look like nails problem of the developers and the DB vendors saw a good opportunity to add an extra feature to their products.

Yeap, whou would even think of storing binary data on database that is crazy!

That being said, the database IS THE MOST unsalable part of any large scale software product. So you always want to delegate only the absolutely necessary tasks to it.

Yes, like storing data in to it... I wonder where I got that idea.. storing data in the database... I must be crazy!