Laird Nelson wrote:
>
> Assaf Arkin wrote:
> > You may use input/output streams, reader/writer etc. You just
> > can't use FileReader/FileInputStream and their like. You can use sockets
> > either, though you can obtain a URL or even a file through the URL
> > factory.
>
> I guess what I'm trying to figure out is the nature of the prohibition.
> Is the prohibition really as harsh as it reads for technical reasons?
> Or does it exist to protect idiot programmers from keeping a filehandle
> open when their bean is passivated?
Contracts.
EJB allows the certain things to happen that will not happen in a
typical application. Objects can be killed by the server,
passivated/activates, threads can be terminated, objects can be moved
from one machine to another, multiple threads may be used in any order
and priority, security will be enforced, etc.
The EJB specs defines a strict contract between the container and bean
that tells the bean which features not to use, or the EJB server will
not be allowed to give all, or any combination, of these features to its
users.
> That is, I can't see any technical reason why I can't read from a file
> provided I open and close the FileReader (let's say) within the
> currently executing method. I obviously understand why I shouldn't
Security. Your bean is not going to have any persmission to do that. You
should use some resource manager that interacts with a security manager
based on roles, which is something not supported in 1.1.
Concurrency. Multiple instances may be activated try to access the same
file. Your bean cannot synchronize or use static members so it cannot
guarantee concurrent access.
Life cycle. The EJB server may decide between method invocations to
passivate your bean and activate it on some other server. Can you
guarantee the file (or directory structure) will remain the same in that
server.
Portability. The only thing an EJB bean is allows to access is available
from the environment or it's own JAR. Nothing else is known to exist.
Move the bean to a different server and your file is no longer there.
BTW if all you are interesting in is reading files, you should use URLs.
The EJB specs defines a URL factory which allows you to read information
in a location-independent manner (i.e using URL), in a controlled
mannger (a resource manager), and server independent manner (you get the
URL factory from the JNDI ENC).
arkin
> stash a reference to a FileReader in a member field somewhere and expect
> it to keep state between activations and passivations. But it seems to
> me that as long as I open and close the stream during the method
> execution I should be OK in all EJB servers.
>
> Is there something I'm missing (there usually is)?
>
> Cheers,
> Laird
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
