Hi
The type of code I'm talking about is started with the Appserver in the same
VM. Weblogic allows you to do this easily in the Weblogic configuration file.
This code is then executing 'in parallel' with the EJB container and can
use functions forbidden to EJB threads. In all respects it is just normal
Java code - not necessarily RMI or CORBA, although quite often it will
access the EJB's as if it were a normal client.
Joel
"Bailey, Jeff" wrote:
>
> 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".
===========================================================================
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".
