|
There is another trick - format font.
----- Original Message -----
Sent: Wednesday, October 02, 2002 8:11
AM
Subject: Re: Does the spec allow JNI in
EJB?
I keep forgetting I have to do a 'reply
all'
> Please also post to the
list, not just me. The rest inline
>
>
> Juan Pablo Lorandi
> Chief
Software Architect
> Code Foundry
Ltd.
> [EMAIL PROTECTED]
>
> Barberstown, Straffan, Co. Kildare,
Ireland.
> Tel: +353-1-6012050 Fax: +353-1-6012051
> Mobile:
+353-86-2157900
> www.codefoundry.com
>
>
Disclaimer:
>
> Opinions expressed are entirely personal and bear no relevance
to
> opinions held by my employer.
> Code Foundry Ltd.'s opinion is that I should get back to
work.
> -----Original Message-----
>
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday,
October 01, 2002 12:27 PM
> To: Juan Pablo Lorandi
> Subject: Re:
Does the spec allow JNI in EJB?
> I
cannot agree with you.
>
>
> > Perhaps we could
rephrase into(to match the spec): A container MAY load
> > a native
library. A container MAY choose, running on an exclusive JVM
> > and
implementing it's own SecurityManager, effectively prohibit the
> >
loading of native libraries. So at least this feature is
> >
Container/Server dependant. See the section Java 2 APIs Requirements
>
> (it's 24.2.1 in ejb2.0, maybe it is 25.2.1 in ejb2.1) Table 19. It
is
> > merely *recommended* that Containers deny such
priviledges.
> >
> It is not the Container but the App server
that MAY load Native
> Libraries. It MAY NOT however prohibit the
loading of native
> libraries, as of the J2EE spec. JCA is an
architecture defined to do
> just that. Using JCA these resources can
and should be managed by
> the App Server and provide these to the
Container.
> [JPL>] Well, the boundary of Container and Server is
quite unclear
> to me. It's the container's responsibility to make JDBC
APIs
> available. That means setting up DataSources too? It's not clear
to
> me. Maybe you can add up to this providing quotes to the
specs?
> > >
> > > 4.
An EJB can call a JNI method.
> >
> > Yes, it may, but I
wouldn't choose to do it directly. A simple wrapper
> > will suffice
to keep you on the safe side of things without
> > relinquishing JNI.
>
> I think using a wrapper you�re just kidding yourself. A
helper class
> runs inside the container. It�s just a workaround around
the spec.
> [JPL>] A wrapper may keep threading management away from
the EJB.
> You justify this in the paragraph below. I honestly don't
care where
> this wrapper executes, as long as it encapsulates the JNI
call. Not
> all wrappers are helper classes nor they must be colocated
with the
> EJB. Oracle's OCI driver for java is a wrapper to the native
driver.
> Same for DB2's drivers. They execute in the Server, if you
> wish(outside of the container) and they don't expose the threading
> issues to its clients.
>
> > In many scenarios JNI is
harmless and transparent to the Java App; in
> > others it
isn't(especially when threading is involved. A container
> > allowing
code to load native libraries relinquishes control over the
> >
resources it's supposed to manage, thus, It. Getting back to your
> >
question, no, it's not forcefully disallowed. It is what you want it
to
> > be: since it's not disallowed, you may assume it is allowed.
Since it's
> > not explicitly allowed nor encouraged, you may want to
steer clear from
> > it. Your choice.
>
> Exactly for
the reasons you mentioned above it is disallowed in the
> spec, and
therefore may not be portable to any app server. The safe
> way to do
this, which may IMHO even use threading, is using JCA
> which to the
container is similar to JDBC and may use JNI (that�s
> what it was made
for) and bring this native library inside the
> transactinal scope of
the container and make it possible for the
> container to manage the
resources.
>
> [JPL>] Presicely my point above. I
wouldn't code an EJB that
> directly calls JNI. If an EJB is directly
disallowed to create
> threads, I assume it won't be able to associate
external threads
> with the VM either. That's why I advocate for some
middleman that
> may spawn threads/associate threads with the VM and
still be
> transparent to its clients. JDBC and JCA fit that
>
purpose(transparent middleman) best and even provide extra
features.
|
