Here's a real world example I implemented today and simply ignored
the restrictions, since we HAVE to do it. We have to read flat file
data feeds from legacy and populate database tables from them with
sqlldr from Oracle. The client has to specify the type of content for
each file since that cannot be derived from the content itself. So,
first the client needs a tree view of a part of the server filesystem,
select files and submit them back to the server with associated types.
With that information I have to generate and execute a script to do the
database loading.
This would have been impossible under the mentioned restrictions
but was extremely simple to implement ignoring them, so sue me :-)
I thought about using stored procedures to do this, but our DBA tells me
this can't be done.... Deadlines didn't allow me to look into writing a
CORBA service i.s.o. an EJB to do this.
>From my experience today I can say that luckily Gemstone doesn't enforce
them :-)
Frank
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Bailey, Jeff
Sent: Thursday, October 14, 1999 12:56 PM
To: [EMAIL PROTECTED]
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".
