Re: [JBoss-user] Store large pdfs with JBoss
Search the jboss-user list from late last week. There was just a discussion about this. -- Luttrell, Peter escribió:: I'm using CMP entity beans. Particularly to achieve database transparency and to avoid writting all of the db access code. Do you know how to do it with CMP? -Original Message- From: David Ward [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 2:58 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Store large pdfs with JBoss I have been able to put CLOBs and BLOBs into Oracle 9i using JBoss 3.0.4, though admittedly after jumping through several hoops. ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
I'm using CMP entity beans. Particularly to achieve database transparency
and to avoid writting all of the db access code.
Do you know how to do it with CMP?
-Original Message-
From: David Ward [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 2:58 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Store large pdfs with JBoss
I have been able to put CLOBs and BLOBs into Oracle 9i using JBoss
3.0.4, though admittedly after jumping through several hoops.
1) yes, ejb's aren't supposed to do i/o - I do my work delegated from
the servlet level.
2) You have to have autocommit off. For some reason autocommit is on by
default in JBoss 3 (wasn't in 2.4) from Connections from DataSources.
Please someone tell me how to turn this off in a global config somewhere!
3) You have to first insert a row using an empty lob. For example,
insert into my_table (key, data) values ('1', empty_blob())
. You could have used empty_clob() if you were using CLOBS instead of
BLOBS.
4) You can then update the BLOB, hower you have to re-select *** using
select for update ***. If you don't use select for update, ** it won't
work **. For example,
select data from my_table where key = '1' for update
5) You then can update the BLOB from the ResultSet. Notice I said
oracle.sql.BLOB not java.sql.Blob. I had to use an Oracle-specific type
here. I couldn't get it to work any other way, and I spent hours (no,
setBinaryStream does not work)... For example,
BLOB blob = (BLOB)rs.getBlob(1);
BufferedOutputStream bos =
new BufferedOutputStream( blob.getBinaryOutputStream() );
// write to the output stream
// safely close everything up
6) Don't forget to commit the work you did. This will commit the insert
and the data your wrote to your BLOB.
7) I set the autocommit on the Connection back to what it was when I
first got it from the DataSource, before I close it (the Connection,
which returns it to the pool). Again, I'd like to see autocommit off
since I wrap everything in a UserTransaction and it should be committed
there instead...
Hope this will save you some of the painful time I had to go through if
you decide to go this route.
David
--
Luttrell, Peter escribió::
> 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.
>
--
-
David Ward
[EMAIL PROTECTED]
http://www.dotech.com
---
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
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 est
RE: [JBoss-user] Store large pdfs with JBoss
I'm using CMP entity beans, which means writing all that custom sql to handle BLOBs isn't possible. I switched to using MySQL and 10 minutes later everything worked perfectly. All i had to do was point my ejbs at MySQL and set the types for MySQLs type. -Original Message- From: Daniel Bruce Lynes [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 7:03 PM To: JBoss Users Subject: Re: [JBoss-user] Store large pdfs with JBoss On Saturday 04 January 2003 04:48, Pete Beck wrote: > I agree with Sun 100% on this. Using the file-system is bad news for > maintenance, scalability and as the article says security. > I've seen the chaos that using the filesystem can cause in clustered > environments and I would say avoid it if you can. > > Of course, the problem is Oracle seems to have totally pathetic support > for large objects from Java. However I am using Postgres and it works > like a charm. Postgres is more natural, yes. However, Oracle's support is still good. You just need to use a combination of the JDBC LOB support with the DBMS_LOB package. We use a combination of stored procedures that manipulate the LOB using DBMS_LOB.getlength(), DBMS_LOB.read(), DBMS_LOB.write(), and DBMS_LOB.copy(), in combination with the getBlob(), select, and select for update operations. Postgres is pretty much the same, but supports most of these operations directly from the JDBC driver, instead of through a database package for LOB operations. The only difference I can see from a usability standpoint, is Postgres lacks a copy operation. You would have to write a stored procedure in C I would imagine, to obtain this goal in Postgres. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user 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 SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
Darren Hartford [mailto:[EMAIL PROTECTED]] wrote: > Outside of JBoss, with Content Management Systems, the most > common problem is how to handle large amounts of data, That's what RDBMSs are designed to do well. There are plenty of databases out there that contain terabytes of data in tables. > The best approach to this is to have two keys in your > database - one that is the unique identifier of the file you > are looking for, the the second is the actual pointer to the > file. This way, if you HSM and move files to CD/DVD, you're > system still maintains integrity of the unique identifier for > lookups, but the pointer can change as-needed. That approach is exactly the one I described (and implemented, in blissful ignorance), and it has exactly the problems I pointed out. If your application crashes (or your network goes down, or whatever) after writing the database row, but before writing the file, your database will contain invalid data (a pointer to a nonexistent or outdated file). If it crashes after writing the file, but before writing the database row, you'll have lost a file (it will be there on disk, but there will be no pointer to it in the database). Worse yet, your application could crash while it's in the middle of writing a file, in which case you're left with a corrupt file. Database transactions are designed to handle exactly those situations. Filesystems aren't. In my experience, backing up a database that's designed in the way you suggest is a nightmare (see my previous message), while backing up a self-contained database is simple. In short, I think it's a mistake to think that you can beat databases at their own game. It's sensible to use them for what they're good at: quick access in huge data sets, and referential integrity guaranteed by the ACID properties of transactions. No filesystem can compete on those criteria. > There are a lot of content management/HSM products already > out there, but I personally have not found one within Open > Source world that would satisfy my requirements, maybe you'll > have better luck and share with us? :-) I haven't found a good general-purpose OpenSource CMS either; I've ended up writing ad-hoc systems for specialised purposes. Benjamin --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
> There are a lot of content management/HSM products already > out there, but I personally have not found one within Open > Source world that would satisfy my requirements, maybe you'll > have better luck and share with us? :-) No kidding! I spent 2 weeks researching OSS CMS systems, and found most of them think that CMS=blogging or slashdot! I ended up starting almost from scratch using Jakarta Slide (WebDAV, DeltaV versioning) and a rich client that supports WebDAV. It allows for interceptors to be plugging in, which will allow me to attach metadata about workflow and integrate a workflow component in for the customer. Anyone found anything OSS that fits this, preferably in Java as our team knows that more than PHP or other web languages? James --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
Just throwing in my two cents - Outside of JBoss, with Content Management Systems, the most common problem is how to handle large amounts of data, which is the case here. With databases, you have to scale your server up to handle it. With a Filesystem approach, you can take advantage of HSM - Hierarchial Storage Management - to manage the large amounts of data. You create/add files to your environment, and at some point they reach a state where the file will no longer change (maybe right after creation) and will not be requested frequently (ready to be archived). Usually you can figure out that in your environment a plan - for instance, after a file has been added it is less-frequently requested after 90 days. At this time, you can burn those files to CD or DVD and put them in a jukebox, migrating to a less expensive and less fast storage environment. After 3 years, store offline on tape. Just an example, your environment will be different. The best approach to this is to have two keys in your database - one that is the unique identifier of the file you are looking for, the the second is the actual pointer to the file. This way, if you HSM and move files to CD/DVD, you're system still maintains integrity of the unique identifier for lookups, but the pointer can change as-needed. You can also archive your files offline on tape and just have a pointer that will bring up a 'quickfind' page of the location, vault #, box #, tape #, and file to find the stored offline file. There are a lot of content management/HSM products already out there, but I personally have not found one within Open Source world that would satisfy my requirements, maybe you'll have better luck and share with us? :-) two cents, -D, CDIA+ - Guy Rouillier [mailto:[EMAIL PROTECTED]] wrote: > Just store areference to a location in the filesystem, and keep the > binary files in the filesystem. You can back up your filesystem > as easily as you can back up your Oracle logs. I tried this for a content management system I worked on once. We had terrible problems keeping the database and the filesystem in sync. For one thing, the database is transactional; the filesystem isn't. You can roll back an operation on the database, but not on the filesystem. Therefore, if your application crashes, you've lost all guarantees of referential integrity, which a database by itself can provide. If you have everything in the database, you can back it up by using the database's own replication facilities to create a mirror, without shutting down the application. But if you keep your PDFs in the filesystem, the only way to be sure of making a consistent backup is to shut down your application, because you need to make sure that (a) there are no files that containing data for uncommitted transactions, and (b) all the files for committed transactions have been written. Also, most filesystems are notoriously poor at storing huge numbers of files in a single directory. Even if you store files in subdirectories and sub-sub-directories, you'll be limited by the speed at which your filesystem can traverse directory hierarchies and match filenames. Different filesystems may or may not be optimised for that sort of access. Databases, on the other hand, are designed to quickly store and retrieve items in tables containing millions of rows. > Every time you do a full database backup, you are going to be > backing up that same, **unchanged** 20 GB of PDFs! In most databases, most of the data remains invariant most of the time. So this point applies to most databases, not just the ones that store PDFs. The answer is not to do full database backups; instead, use the database's own replication facility, which is designed to do this job efficiently. Benjamin --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
Guy Rouillier [mailto:[EMAIL PROTECTED]] wrote: > Just store areference to a location in the filesystem, and keep the > binary files in the filesystem. You can back up your filesystem > as easily as you can back up your Oracle logs. I tried this for a content management system I worked on once. We had terrible problems keeping the database and the filesystem in sync. For one thing, the database is transactional; the filesystem isn't. You can roll back an operation on the database, but not on the filesystem. Therefore, if your application crashes, you've lost all guarantees of referential integrity, which a database by itself can provide. If you have everything in the database, you can back it up by using the database's own replication facilities to create a mirror, without shutting down the application. But if you keep your PDFs in the filesystem, the only way to be sure of making a consistent backup is to shut down your application, because you need to make sure that (a) there are no files that containing data for uncommitted transactions, and (b) all the files for committed transactions have been written. Also, most filesystems are notoriously poor at storing huge numbers of files in a single directory. Even if you store files in subdirectories and sub-sub-directories, you'll be limited by the speed at which your filesystem can traverse directory hierarchies and match filenames. Different filesystems may or may not be optimised for that sort of access. Databases, on the other hand, are designed to quickly store and retrieve items in tables containing millions of rows. > Every time you do a full database backup, you are going to be > backing up that same, **unchanged** 20 GB of PDFs! In most databases, most of the data remains invariant most of the time. So this point applies to most databases, not just the ones that store PDFs. The answer is not to do full database backups; instead, use the database's own replication facility, which is designed to do this job efficiently. Benjamin --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Store large pdfs with JBoss
I've not read Sun's argument, but I've never understood the rationale for storing large invariant data in an RDBMS. Or course the RDBMS vendor wants you to do it - they want the whole world stored under their product. And the DASD vendors love it. But what does it buy you, the user who implements such a solution? Say in the example below you have 20 GB of PDFs. Every time you do a full database backup, you are going to be backing up that same, **unchanged** 20 GB of PDFs! What is the point in that? Just store a reference to a location in the filesystem, and keep the binary files in the filesystem. You can back up your filesystem as easily as you can back up your Oracle logs. - Original Message - From: "Daniel Bruce Lynes" <[EMAIL PROTECTED]> To: "JBoss Users" <[EMAIL PROTECTED]> Sent: Friday, January 10, 2003 8:03 PM Subject: Re: [JBoss-user] Store large pdfs with JBoss On Saturday 04 January 2003 04:48, Pete Beck wrote: > I agree with Sun 100% on this. Using the file-system is bad news for > maintenance, scalability and as the article says security. > I've seen the chaos that using the filesystem can cause in clustered > environments and I would say avoid it if you can. > > Of course, the problem is Oracle seems to have totally pathetic support > for large objects from Java. However I am using Postgres and it works > like a charm. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Store large pdfs with JBoss
On Saturday 04 January 2003 04:48, Pete Beck wrote: > I agree with Sun 100% on this. Using the file-system is bad news for > maintenance, scalability and as the article says security. > I've seen the chaos that using the filesystem can cause in clustered > environments and I would say avoid it if you can. > > Of course, the problem is Oracle seems to have totally pathetic support > for large objects from Java. However I am using Postgres and it works > like a charm. Postgres is more natural, yes. However, Oracle's support is still good. You just need to use a combination of the JDBC LOB support with the DBMS_LOB package. We use a combination of stored procedures that manipulate the LOB using DBMS_LOB.getlength(), DBMS_LOB.read(), DBMS_LOB.write(), and DBMS_LOB.copy(), in combination with the getBlob(), select, and select for update operations. Postgres is pretty much the same, but supports most of these operations directly from the JDBC driver, instead of through a database package for LOB operations. The only difference I can see from a usability standpoint, is Postgres lacks a copy operation. You would have to write a stored procedure in C I would imagine, to obtain this goal in Postgres. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
On Fri, 2003-01-03 at 19:37, 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: > > From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: [ snip ] I agree with Sun 100% on this. Using the file-system is bad news for maintenance, scalability and as the article says security. I've seen the chaos that using the filesystem can cause in clustered environments and I would say avoid it if you can. Of course, the problem is Oracle seems to have totally pathetic support for large objects from Java. However I am using Postgres and it works like a charm. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Store large pdfs with JBoss
Dain, OK. I see what you are saying. I agree. Thanks. Greg Dain Sundstrom wrote: Greg, 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 problem
Re: [JBoss-user] Store large pdfs with JBoss
Scott M Stark escribió:: > Write a JCA adaptor for a file based persistent store. -- You say that like it's so easy Scott... ;) Seriously, what is Oracle underneath all the "cool" stuff but a "file based persistent store." Anyway, if you are going to indeed write your own jca adapter, instead of starting from scratch here is a possible place to start. Granted, there is nothing in the code that has anything to do with the JCA spec, but it points out some stuff you will need to keep in mind when you implement one: http://www.onjava.com/pub/a/onjava/2001/11/07/atomic.html http://www.onjava.com/onjava/2001/11/07/examples/atomic.zip David --- 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
RE: [JBoss-user] Store large pdfs with JBoss
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
PMTo: [EMAIL PROTECTED]Subject: Re:
[JBoss-user] Store large pdfs with JBoss
Write a JCA adaptor for a file based persistent
store.
Scott StarkChief Technology
OfficerJBoss Group, LLC
- 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.
Re: [JBoss-user] Store large pdfs with JBoss
Greg, 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 d
RE: [JBoss-user] Store large pdfs with JBoss
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
PMTo: [EMAIL PROTECTED]Subject: Re:
[JBoss-user] Store large pdfs with JBoss
Write a JCA adaptor for a file based persistent
store.
Scott StarkChief Technology
OfficerJBoss Group, LLC
- 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.
Re: [JBoss-user] Store large pdfs with JBoss
I have been able to put CLOBs and BLOBs into Oracle 9i using JBoss
3.0.4, though admittedly after jumping through several hoops.
1) yes, ejb's aren't supposed to do i/o - I do my work delegated from
the servlet level.
2) You have to have autocommit off. For some reason autocommit is on by
default in JBoss 3 (wasn't in 2.4) from Connections from DataSources.
Please someone tell me how to turn this off in a global config somewhere!
3) You have to first insert a row using an empty lob. For example,
insert into my_table (key, data) values ('1', empty_blob())
. You could have used empty_clob() if you were using CLOBS instead of
BLOBS.
4) You can then update the BLOB, hower you have to re-select *** using
select for update ***. If you don't use select for update, ** it won't
work **. For example,
select data from my_table where key = '1' for update
5) You then can update the BLOB from the ResultSet. Notice I said
oracle.sql.BLOB not java.sql.Blob. I had to use an Oracle-specific type
here. I couldn't get it to work any other way, and I spent hours (no,
setBinaryStream does not work)... For example,
BLOB blob = (BLOB)rs.getBlob(1);
BufferedOutputStream bos =
new BufferedOutputStream( blob.getBinaryOutputStream() );
// write to the output stream
// safely close everything up
6) Don't forget to commit the work you did. This will commit the insert
and the data your wrote to your BLOB.
7) I set the autocommit on the Connection back to what it was when I
first got it from the DataSource, before I close it (the Connection,
which returns it to the pool). Again, I'd like to see autocommit off
since I wrap everything in a UserTransaction and it should be committed
there instead...
Hope this will save you some of the painful time I had to go through if
you decide to go this route.
David
--
Luttrell, Peter escribió::
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.
--
-
David Ward
[EMAIL PROTECTED]
http://www.dotech.com
---
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
Re: [JBoss-user] Store large pdfs with JBoss
write a jca adpter for cvs and use this in a cvs appropriate manner ... bax > > Write a JCA adaptor for a file based persistent store. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - 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 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
Re: [JBoss-user] Store large pdfs with JBoss
Write a JCA adaptor for a file based persistent store. Scott StarkChief Technology OfficerJBoss Group, LLC - 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.
Re: [JBoss-user] Store large pdfs with JBoss
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:
From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html:
Why can't
EJBs readand write files and directories in the filesystem? And why can't
they accessfile descriptors?
Enterprise beans aren't allowed to access files primarily
because files are not transactional resources. Allowing EJBs to access
filesor directories in the filesystem, or to use file descriptors, would
compromisecomponent distributability, and would be a security hazard.
Another reason is deployability. The EJB container
canchoose 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 aretherefore outside of the EJB container's control. File systems,
directories,files, and especially file descriptors tend to be machine-local
resources. Ifan enterprise bean running in a JVM on a particular machine
is using orholding an open file descriptor to a file in the filesystem,
that enterprisebean cannot easily be moved from one JVM or machine to
another, without losingits reference to the file.
Furthermore, giving EJBs access to the filesystem
is asecurity hazard, since the enterprise bean could potentially read
andbroadcast the contents of sensitive files, or even upload and overwrite
theJVM runtime binary for malicious purposes.
Files are not an appropriate mechanism for storing
businessdata for use by components, because they tend to be unstructured,
are notunder the control of the server environment, and typically don't
providedistributed transactional access or fine-grained locking. Business
data isbetter 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:37PM
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 URLsto the correct PDF for a particular document number. We can
reach those URLson 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 localdisk 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 awebapp 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, January03, 2003 09:14
To:[EMAIL PROTECTED]
Subject: [JBoss-user] Storelarge pdfs with JBoss
Has anyone had
experiencestoring large pdfs with jboss, say ~5mbs each?
I would like
to do itwith Oracle and BLOBs, but i've read that there's problems
with thedrivers and jboss and it doesn't look like it will be
possible.
Has anyone done
with withany other database?
Does anyone
have ideas onhow else to store these files, m
RE: [JBoss-user] Store large pdfs with JBoss
Title: Message Agreed.. Jakarta's Slide is another option, as it is an OSS WebDAV-compliant server that will let you configure namespaces for using the filesystem, a DB, or any pluggable store (e.g. /files is for the filestore, while /office_docs is targeted to a DB). It also supports the DeltaV versioning, and comes with a nice client library to talk to the system (over HTTP though, but you may be able to talk directly to it for what you want to do as well.. That API is still under dev AFAIK). http://jakarta.apache.org/slide HTH, James -Original Message-From: Sasidharan, Manoj [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 1:14 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-user] Store large pdfs with JBoss Hello All, I would recommend using some document management system like Plexus IFO or archival storage system like Plexus OSM... advantages: faster, efficient, supports version, backups, searching... regards MS -Original Message-From: Nelson, Tracy [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 10:08 AMTo: '[EMAIL PROTECTED]'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:14To: [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.
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.
-Original
Message-From: James Cleary
[mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 12:37
PMTo: [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:14To:
[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
RE: [JBoss-user] Store large pdfs with JBoss
Hello All, I would recommend using some document management system like Plexus IFO or archival storage system like Plexus OSM... advantages: faster, efficient, supports version, backups, searching... regards MS -Original Message-From: Nelson, Tracy [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 10:08 AMTo: '[EMAIL PROTECTED]'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:14To: [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.
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:14To: [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.
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:14To: [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.
