RE: [JBoss-user] Store large pdfs with JBoss

[Callies, Peter]

A WebDAV adapter would be another option.   Peter Callies McKesson Information Solutions Transaction Solutions Hub mailto:[EMAIL PROTECTED] Phone: (952) 814-7163 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -----Original Message----- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 2:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Store large pdfs with JBoss Write a JCA adaptor for a file based persistent store.   xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: Luttrell, Peter To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 11:37 AM Subject: RE: [JBoss-user] Store large pdfs with JBoss 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:   From http://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.