Could you provide a little more detail? When you say implement this code as
a resource which executes outside the EJB container, are you talking about a
CORBA or RMI object?
Thanks,
Jeff
-----Original Message-----
From: Joel Crisp [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 15, 1999 4:46 AM
To: [EMAIL PROTECTED]
Subject: Re: EJB Programmer restrictions
Hi
The solution is to implement this code as a resource which executes outside
the
EJB container. Then you can queue requests over the EJB container boundary
and have them executed by a 'normal' thread outside the EJB container but
in the same VM.
Joel Crisp, Senior Java Architect, SUN PS Java Center,
Frank Sauer wrote:
>
> 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".
UK
===========================================================================
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".
