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

[Luttrell, Peter]

Admittedly i don't know much about JCA.   Does anyone have skeleton code or a sample they care to share?   thanks. .peter -----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. 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.