Hi,
My question to the spec designers is also along the same lines.
Why is reading and writing to files so bad so as to prohibit them ? I
can understand discouraging people to store data in files.
I also have the same problem. I have applications written using TP
monitors that read/write to files, to obtain properties, to perform
batch operations to the mainframe etc. etc.
All these operations are done within the context of a transaction
inside a service. Now, translating these apps to EJB's is going to be
a pain as a major redesign is necessary.
Is this restriction a hard rule or is it only advice ?
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bailey, Jeff
> Sent: Friday, 8 October 1999 21:01
> To: [EMAIL PROTECTED]
> Subject: was RE: Question entity bean
>
>
> No, I don't know of any transactional filesystem API's.
> I'm somewhat
> puzzled by this restriction and would like to under it
> better and the
> rationale behind it.
> The rationale given in the spec is along the lines of "it's not good
> practice to
> store data in files" not the typical rationale for EJB
> restrictions which is
> more like "the container can't manage your bean's lifecycle
> if you do this".
> Is all java.io access to files prohibited, or just access
> that stores an
> entity state in a file? I can understand why storing
> entity state in a file
> is a bad idea (without a transaction filesystem API), but I
> can't understand
> why simply reading the contents of a file is prohibited.
>
> In our CORBA services today, a number of them are
> value-added wrappers for
> other executables (perl scripts or exes). The CORBA service will
> Runtime.exec() the program and the program will save its output
> to a temporary file. The CORBA service will them read the
> file, parse the
> results, and
> create a CORBA result object to return. All this happens
> within one method.
>
> I'd like to be able to start writing these types of
> services using Session
> Beans, but if I read the spec correctly I would not be able
> to since we need
> to read a file.
>
> Am I correct in this assumption? If so, what is the
> problem with my EJB
> instance reading from it's own temporary file that is
> "owned" by that
> instance.
>
> Also, the spec does mention if calling Runtime.exec() is
> allowed, is it?
>
> I assume all these restrictions apply not only to the EJB
> itself, but also
> to any other java object used by the EJB? For example, I
> would assume that
> having the EJB instantiate a helper class to do the file io
> would also be
> restricted.
>
> Thanks,
> Jeff Bailey
> Sr. Systems Engineer
> NetGenics, Inc.
>
>
>
> -----Original Message-----
> From: Tom Valesky [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 07, 1999 8:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Question entity bean
>
>
> Quote from spec, section 18.1.2
> An enterprise bean must not use the java.io package to
> attempt to access
> files and directo-ries
> in the file system.
> 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, to store data.
> <end quote>
>
> Presumably you could access a file system through a transactional
> filesystem API, but I don't know of any such things off the
> top of my
> head. Anyone?
>
> Tom
>
> ============================================================
> ===============
> 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".
>
>
===========================================================================
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".
