I can also understand the portability issue, but people that use
Runtime.exec() in any application today knows they are limiting their
portability. Do you have the sense that most ejb vendors allow additional
permissions to be granted?
-----Original Message-----
From: Vlada Matena [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 14, 1999 1:13 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB Programmer restrictions
The issue is application portability. There is no problem with products
supporting additional
permissions so that the Deployer can enable these permissions for
applications that need
these permissions. However, these applications are unlikely to be portable.
For example,
we cannot require that ALL products support Runtime.exec() in the same way
as the
process model varies across OSes.
----- Original Message -----
From: Bailey, Jeff <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 1999 9:55 AM
Subject: EJB Programmer restrictions
> 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".
>
>
===========================================================================
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".
