I completely disagree; this is not a problem with CMP but the implementations. The problem with every app server available including JBoss is the CMP engine is a black box. In 4.0, I plan on opening this up so anyone can fairly easily write a physical persistence store manager. This would mean that for this case, Peter could have all the data for a the entity in a JDBC data store except for the file which would be stored via a filesystem physical store manager. Entity beans provide a good interface to an abstract store system. Also with the aspect stuff you will be able to use the same abstract store system from an even easier interface.
-dain
On Friday, January 3, 2003, at 02:34 PM, Greg Turner wrote:
IMHO, this is a prime example of business data that does not fit the EJB model. �And you shouldn't try and shoe horn it in. �Its been my understanding that doing the file system access via an MBean is a perfectly permissible way to get around the prohibitions described in the Sun article. � Another option is to find or write a JCA wrapper for the Filesystem.
Luttrell, Peter wrote:
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:
�
Fromhttp://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html:
�
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.
�
�
�-----Original Message-----
From: James Cleary [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 12:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Store large pdfs with JBoss
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 -----
From: Nelson, Tracy
To: '[EMAIL PROTECTED]'
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.
-----Original Message-----
From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 09:14
To: [EMAIL PROTECTED]
Subject: [JBoss-user] Store large pdfs with JBoss
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.
--
Greg Turner, JBoss Authorized Consultant
Tiburon Enterprise Systems
http://www.tiburon-e-systems.com
Box 1171
Tiburon, CA 94920
415-927-2543
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
