Chris
Since the spec any way allows people to write client sockets, I can
always pass a java reference to another server that does the damage for
me.
Actually, I really dont understand what is happening here. If an EJB
can communicate with another server using sockets, why cant it create a
process?
Thanks for all your help. For me, this is the single most defining
requirement, if I cant create a process from an EJB, I probably wont be
able to use EJB, and that is pretty sad.
- anand
"Bono, Chris" wrote:
>
> Anand,
>
> I think that the security hole would be passing a reference from Java to a native
>program such as C which could then
> manipulate the memory and such. I don't completely understand the security hole, but
>this is what I believe they may be
> talking of.
>
> What I did was have a servlet that did the exec. I am not sure if this will fix your
>situation.
>
> Chris
>
> -----Original Message-----
> From: Anand Sankaran [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 10, 2000 6:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Maintaining Non - DB transactions
>
> Chris,
>
> Well again, I went to the spec and this is what it says,
>
> "The enterprise bean must not attempt to load a native library."
>
> I am not sure if Runtime.getRuntime().exec() falls into this category.
>
> If it falls, well then one can not create a process.
>
> Again, I still do not understand the 'security hole' that loading a
> native library creates, IMHO, my app server is in an environment I
> protect and trust, so why should I not be able to load a native library
> on my app server?
>
> Isn't this a big drawback in coding with EJB?
>
> - anand
>
> "Bono, Chris" wrote:
> >
> > Anand,
> > I suppose that is where I was getting my reasoning from. Isn't a process a native
>call?
> >
> > Chris
> >
> > -----Original Message-----
> > From: Anand Sankaran [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 10, 2000 5:19 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Maintaining Non - DB transactions
> >
> > There is something very intersting happening here.
> >
> > The spec says that EJBs can not call native methods as 'it would be a
> > security hole'.
> >
> > Calling a native process is 'as big a hole' if not bigger ;-)
> >
> > Is there a justification for allowing a process to be created and not a
> > native method to be called?
> >
> > - anand
> >
> > "Bono, Chris" wrote:
> > >
> > > Anand,
> > > Thanks for the info. I guess I need to pull that spec off of the shelf before I
>post. ;-)
> > >
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Anand Sankaran [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 10, 2000 4:47 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Maintaining Non - DB transactions
> > >
> > > Chris,
> > >
> > > After this mail, I read the EJB1.1 specification again.
> > >
> > > It contains a section called Programming Restrictions (Section 18.1.2)
> > > in the PDF document, page # 272 in the document.
> > >
> > > This document does not say anything against creating processes.
> > >
> > > If this is the case, then I think it is legal to create processes from
> > > within an EJB.
> > >
> > > Also, regarding doing socket programming, this is what the spec says.
> > >
> > > "The EJB architecture allows an enterprise bean instance to be a network
> > > socket client, but it does not allow it to be a network server. Allowing
> > > the instance to become a network server would conflict with the basic
> > > function of the enterprise bean-- to serve the EJB clients."
> > >
> > > Then, it is legal for a EJB to open a socket and talk with a server.
> > >
> > > - anand
> > >
> > > "Bono, Chris" wrote:
> > > >
> > > > Anand,
> > > > I believe the spec disallows exec'ing a process from a bean. We had to do this
>so we did it in a servlet.
> > > > I am curious to hear replies on this.
> > > >
> > > > Chris
> > > >
> > > > -----Original Message-----
> > > > From: Anand Sankaran [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, August 10, 2000 1:51 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Maintaining Non - DB transactions
> > > >
> > > > Hi all
> > > >
> > > > In my Session bean, I need to do the following things:
> > > >
> > > > * Update DB
> > > > * Create a UNIX process that does a few things
> > > > * Update DB
> > > > * Create a UNIX process ....
> > > >
> > > > In such a case, what sort of Transaction Processing support does EJB /
> > > > App Server provide me?
> > > >
> > > > Does it provide only the DB transaction processing help. If this is the
> > > > case, what sort of technology / approach should I be handling to do
> > > > transaction processing for all the UNIX processes I create? (For
> > > > instance, kill them - rollback?)
> > > >
> > > > - anand
> > > >
> > > > ===========================================================================
> > > > 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".
> > >
> > > ===========================================================================
> > > 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".
>
> ===========================================================================
> 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".
