<vendor>
With Ejipt you can write your services or even a full-fledged custom server
in straight Java and simply instantiate Ejipt inside as a regular class.
Your services can be written with no EJB or other J2EE restrictions and no
configuration files or proprietary syntax is needed to specify them. You
will have access to the deployed ejbeans from your "wrapper" services just
as any other client would (the calls would all be local calls, of course).
As an added bonus, your services will also have access to the Ejipt
resident, XA-compliant 2PC transaction manager through the
javax.transaction.TransactionManager interface. Among other things, this can
help you write transacted, flat file-based stores by simply providing an
implementation to the javax.transaction.xa.XAResource interface.
</vendor>
Imre Kifor
Valto Systems
-----Original Message-----
From: Joel Crisp <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, October 15, 1999 9:41 AM
Subject: Re: EJB Programmer restrictions
>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".
>
>
===========================================================================
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".
