Nice idea!
However haven't you broken the spirit of the spec if not the actual letter
of the spec. You have effectively extended the server and made your EJBs
dependent on that extension. If you wanted to move your EJBs to another
server, but the new server wouldn't let you add your extension then you
couldn't deploy to that servers container. Therefore (at least from a
component developers point of view) this only a bit less bad than explicitly
breaking the spec and hoping the server lets you access the file system.
One other way I have used with Oracle is to use stored procedures with
BFILEs. That way you are moving the file handling out of EJB completely but
are not breaking the spec. This means your EJBs can be deployed to any
server. It does of course tie you into Oracle. Also it doesn't guarantee the
transaction integrity that is the root cause of the exclusion of file access
in the spec. Oracle does not offer transactional integrity for BFILES (as
far as I remember).
I do not know if other databases offer similar features.
Cheers
Lawrence
> ----------
> From: Ian McCallion[SMTP:[EMAIL PROTECTED]]
> Reply To: A mailing list for Enterprise JavaBeans development
> Sent: 04 April 2001 15:19
> To: [EMAIL PROTECTED]
> Subject: Re: File access, etc.
>
> Steve Gardell wrote:
> >
> > We have an application that deals with a large
> > quantity of multi-media data associated with a
> > relational database. The multi-media files are stored
> > directly on the file system. Conceptually they are
> > columns in a database schema; however the reality
> > is that relational databases are not really "up the task"
> > of managing this data, so the relational database
> > contains pathnames.
> >
> > We would like to manage these associated files via
> > EJB. Basically this means creating, deleting, and
> > returning pathnames. The EJB server would (at
> > least typically) never be concerned with the contents
> > of the files.
> >
> > We understand that the spec prohibits this but are
> > at a loss to understand why. They are really just an
> > element of our persistent store... We are hesitant to
> > just cheat since we understand that access to file
> > system might be "yanked" at any time.
>
> One way round this problem is to write yourself some helper classes to
> access
> the file system, then instruct your application server to load these
> classes
> using the server's own class loader. This will ensure that it is not
> subject to
> the same restrictions as an EJB. It is server-specific how to this - read
> your
> server documentation.
>
> What you must NOT do is package this class in the ejb jar, as this makes
> the
> class, in effect, part of the EJB.
>
>
> Ian McCallion
> Alexis Systems Limited
> Romsey, UK
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
Visit us at http://www.clearstream.com
Check out current job vacancies at http://www.clearstream.com/public/english/e_vacs.htm
IMPORTANT MESSAGE
Internet communications are not secure and therefore Clearstream International does not
accept legal responsibility for the contents of this message.
The information contained in this e-mail is confidential and may be legally
privileged. It is
intended solely for the addressee. If you are not the intended recipient, any
disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. Any views expressed in this e-mail are those of the
individual sender, except where the sender specifically states them to be the views of
Clearstream International or of any of its affiliates or subsidiaries.
END OF DISCLAIMER
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
