|
Actually i'm considering
writing a little jmx service that manages the filesystem store. my ejbs would
store the key that the jmx service requires. the service would then
enforce/handle all such rules.
I just read this however, which
articulates some of the concerns with any filesystem
approach:
Why can't EJBs read
and write files and directories in the filesystem? And why can't they access
file descriptors?
Enterprise beans aren't allowed to access files primarily
because files are not transactional resources. Allowing EJBs to access files
or directories in the filesystem, or to use file descriptors, would compromise
component distributability, and would be a security hazard.
Another reason is deployability. The EJB container can
choose to place an enterprise bean in any JVM, on any machine in a cluster.
Yet the contents of a filesystem are not part of a deployment, and are
therefore outside of the EJB container's control. File systems, directories,
files, and especially file descriptors tend to be machine-local resources. If
an enterprise bean running in a JVM on a particular machine is using or
holding an open file descriptor to a file in the filesystem, that enterprise
bean cannot easily be moved from one JVM or machine to another, without losing
its reference to the file.
Furthermore, giving EJBs access to the filesystem is a
security hazard, since the enterprise bean could potentially read and
broadcast the contents of sensitive files, or even upload and overwrite the
JVM runtime binary for malicious purposes.
Files are not an appropriate mechanism for storing business
data for use by components, because they tend to be unstructured, are not
under the control of the server environment, and typically don't provide
distributed transactional access or fine-grained locking. Business data is
better managed using a persistence interface such as JDBC, whose
implementations usually provide these benefits. Read-only data can, however,
be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class.
Our Product Data Manager system does the same.
Just stores the files on disk with encrypted names. The database has the URLs
to the correct PDF for a particular document number. We can reach those URLs
on our Apache web server. If trying the JBoss route you could modify your
$JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your local
disk drive. Not very portable then but depends on the application/environment.
Not sure how you'd reference the PDFs though. Maybe placing your files under a
webapp directory?
----- Original Message -----
Sent: Friday, January 03, 2003 1:07
PM
Subject: RE: [JBoss-user] Store large
pdfs with JBoss
I've always done it with the filesystem. The
database just stores the path to the file. Typically you establish
some rules for the filesystem store (retention time, max space, maybe use
quotas) and have it owned by whatever user the app server runs
as.
Has anyone had experience
storing large pdfs with jboss, say ~5mbs each?
I would like to do it
with Oracle and BLOBs, but i've read that there's problems with the
drivers and jboss and it doesn't look like it will be
possible.
Has anyone done with with
any other database?
Does anyone have ideas on
how else to store these files, maybe without a database? I've always
thought the filesystem was pretty much off limits from the
appserver.
thanks.
.peter
This transmission contains information solely
for intended recipient and may be privileged, confidential and/or
otherwise protect from disclosure. If you are not the intended recipient,
please contact the sender and delete all copies of this transmission. This
message and/or the materials contained herein are not an offer to sell, or
a solicitation of an offer to buy, any securities or other instruments.
The information has been obtained or derived from sources believed by us
to be reliable, but we do not represent that it is accurate or complete.
Any opinions or estimates contained in this information constitute our
judgment as of this date and are subject to change without notice. Any
information you share with us will be used in the operation of our
business, and we do not request and do not want any material, nonpublic
information. Absent an express prior written agreement, we are not
agreeing to treat any information confidentially and will use any and all
information and reserve the right to publish or disclose any information
you share with
us.
This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and
will use any and all information and reserve the right to publish or disclose any information you share with us.
|
