I can understand why most of the various programmer restrictions exist
(e.g., no threads, file.io, Runtime.exec()). However, there are times when
solving real world problems that you need to do some of these things. As
long as you know the impacts of your actions and the container can still
manager your EJB, I don't see why they're not allowable. For example,
what's the problem with a calling Runtime.exec() on some command that
generates a temporary file and then reading the file all within the same
method? I know I can have the EJB call a rmi or CORBA object, but having to
write an rmi or CORBA service to do the dirty work defeats a lot of the
benefit that EJB provides in the first place.
The EJB spec (18.2.1.1) states that some containers may allow the deployer
to grant more or fewer permissions to and EJB. I'm wondering if the major
EJB vendors out there provide this capability or even enforce these
restrictions at all?
I'd like to see EJB become a dominant distributed component architecture,
but I'm concerned that developers might be handcuffed by these restrictions
when trying to apply EJB to a good percentage of real world problems. How do
others feel on this issue?
Jeff Bailey ([EMAIL PROTECTED])
Sr. Software Engineer
NetGenics, Inc.
===========================================================================
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".
