All of this tip-toeing around the spec is getting a
little silly.
Limiting the discussion to the 1.1 spec:
Section 18.1.2 and it says:
"This section describes the programming restrictions
that a Bean Provider must follow to ensure that the
enterprise bean is portable and can be deployed in any
compliant EJB Container."
So what this means is not that you are totally hosing
yourself if you don't follow it, but rather that it
may very well work for you on platform, but not
another, so by complying with the restrictions, you
get superior portability.
The spec also says:
"The file system APIs are not well-suited for business
components to access data. Business components
should use a resource manager API, such as JDBC API,
to store data."
Fair enough, but none of the containers I have used
have explicitly PREVENTED java.io use (yes, I tested
it). In my opinion, if java.io works in your
case,(say, an occasional file write etc.) and you do
not have any platform portability issues, there is no
point in yanking your own chain by devising some other
outlandish scheme because someone at Sun said your
file system API is not suitable for data access.
Secondly, the spec clearly states as follows:
"An enterprise bean must not use the java.io package
to attempt to access files and directo-ries
in the file system."
Alrightee, that means that any of the following are
acceptable:
JNDI file system adapter (javax...)
Resource Bundles (java.util)
Just my 2c.
//Nicholas
--- Lawrence Marsh <[EMAIL PROTECTED]> wrote:
> 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".
>
=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (973) 615 9646
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
===========================================================================
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".
