Recent changes to patches

Allow building with SDK 1.4 (add JDBC3 methods)

Anonymous — Fri, 10 Sep 2004 08:30:55 -0000

This patch allow building Tyrex 1.0.1 with Java 1.4 by
adding the missing JDBC3 methods. They mostly return
an Exception ("Unimplemented").

JNDI Reference handling during lookup behavior

kris wehner — Thu, 02 Sep 2004 19:41:16 -0000

I recently have been working with Tyrex's MemoryContext
as a stub JNDI provider in my application, and have
found that it doesn't follow the behavior of the Tomcat
JNDI provider (quite probably other JNDI providers as
well).

What is happening is, on every lookup of a DataSource
that is bound in JNDI via a Reference, the data source
is created, returned to the caller and then immediately
discarded. The DataSource then gets garbage collected,
and closes its resources in the finalizer, which closes
the open connections that the application code is using
aburptly and asynchronously.

In order to implement a connection pool, the pool must
stay referenced in memory across JNDI invocations. The
way tomcat does this is on the first lookup, it
clobbers the Reference entry it has stored and replaces
it with the object that it referred to. This keeps the
pool alive for the duration of the life of the JNDI
provider.

The attached patch does this to the Tyrex
MemoryContext. The diff is against the head of CVS, and
has been tested fairly extensively and shown to work
correctly.

Handling of References broken?

Holger Engels — Wed, 12 Jun 2002 06:09:20 -0000

1. I tried to incorporate the tyrex JNDI Provider into my Client
Container
and found some bug(s) in the MemoryContext regarding
ReferenceHandling.
I'm using my own ThreadLocalContextFactory and my own
(read/write)
JavaContext and javaURLContextFactory ..

RefAddr refAddr = new StringRefAddr("nns", "ENC");
Reference envRef = new Reference("javax.naming.Context",
refAddr,
ThreadLocalContextFactory.class.getName(),
null);
Context context = (Context)new InitialContext().lookup("java:");
context.bind("comp", envRef);

Thus "java:comp" is a dynamic reference to a thread local context.

The following code is working:

Context subcontext = (Context)context.lookup("comp");
subcontext.bind("test", "value");

is working. However, the following results in a
NotContextException: "comp
is not a subcontext":

context.bind("comp/test", "value");

.. well, he's right, but it's a Reference to a subcontext!!

The problem is, that References are only followed during lookups. If
bind/rebind/list/.. are called with a name that traverses a Reference,
the
reference is not followed.

The attached patch fixes this (at least for me). But I'm not sure, if it
fixes all places, where references have to be followed. Also LinkRefs
are
not handled.

2. another suggestion (also part of the patch): Please make the
constructor:

MemoryContext( MemoryBinding bindings, Hashtable env )

public or at least protected to make the MemoryContext more
accessible and
useful for different applications.

3. Please separate the JNDI provider from the rest of the tyrex jar.
The
class dependencies "leak":

javaURLContextFactory depends on JavaContext
JavaContext depends on EnvContext
EnvContext depends on tyrex.tm.impl.ThreadContext
ThreadContext depends on tyrex.tm.RuntimeContext
RuntimeContext depends on everything else

This means, that the java url context factory can only be used in
conjunction with the whole tyrex functionality.

A possible solution would be to use a provider mechanism: a
configurable
ObjectFactory implementation, that populates the EnvContext.