tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <>
Subject Re: RARs, LocalClients and JNDI naming
Date Wed, 17 Feb 2010 22:06:31 GMT
Well, the long thread I followed suggests that the only way to get my
connection factory from a @LocalClient is to access it under
java:openejb/Resource/classes.  There isn't any other name I can give it,
and there isn't any other name I can look it up under.  I am thrilled if
there is in fact another possibility, but to my knowledge this and only this

  private MyConnectionFactoryImpl connectionFactory;

...and there is no other configuration located anywhere else (in XML, in
properties, in code).

Now that I have it working, I can see that the connection factory is
correctly injected.  Hooray!

However, when I call its method that gets me a new user connection, I'm
getting an AssertionError in the middle of the Geronimo connection
management infrastructure.  The stack is at the end of my message.  Perhaps
David Jencks is lurking on this list?  I can provide any and all information
as necessary.



(You'll note that I'm doing a JCA implementation for Drools 5.0.1; my
KnowledgeBase implementation serves as my connection factory; the user
connection to the Drools instance is represented by the
StatelessKnowledgeSession interface.)

On Wed, Feb 17, 2010 at 4:35 PM, Stephen Connolly <> wrote:

> markmail is not iPod friendly, so I'm not sure if your like makes the
> following redundant.
> in general, I find openejb just wires things up for you, so if you are
> looking for a MyConnectionFactory at java:eis/mcf even though you gave not
> told openejb to bind it to that jndi name, openejb will see that it has
> classesRA which provides MyConnectionFactory, and just wire it up... which
> makes testing easier as you don't have to try and replicate jboss jndi
> bindings in your openejb tests
> Sent from my [rhymes with tryPod] ;-)
> On 17 Feb 2010, at 21:04, Laird Nelson <> wrote:
>  Ah, found
>> That did the trick (though of course it is somewhat non-obvious! :-)).
>> Best,
>> Laird
>> On Wed, Feb 17, 2010 at 2:42 PM, Laird Nelson <> wrote:
>>  I am sure that I am missing something obvious, but perhaps not, as I
>>> cannot
>>> find any information on this subject.
>>> I am writing a resource adapter.  For its unit tests, I am attempting to
>>> deploy it, unpackaged, into an instance of OpenEJB 3.1.3-SNAPSHOT.  A
>>> patch
>>> that was committed in January somewhere seems to let OpenEJB
>>> 3.1.3-SNAPSHOT
>>> auto-discover @LocalClients, such as my unit test, in projects that have
>>> an
>>> META-INF/ra.xml file present.  This is great--I can tell from some of the
>>> logging messages that OpenEJB is at least attempting to instantiate my
>>> ResourceAdapter implementation.
>>> I've used @LocalClient before, too, and so I have the InitialContext all
>>> set up, and I can tell that indeed, OpenEJB is firing up.  So far so
>>> good.
>>> Now the obvious/stupid part.  I've built this resource adapter
>>> implementation, I have the ra.xml...but where...where do I indicate what
>>> JNDI name I would like it to have?  Obviously this information shouldn't
>>> be
>>> part of the final resource adapter hairball, since by definition you're
>>> supposed to be able to pick a .rar file up, put it in an app server, and
>>> have it install itself.
>>> In JBoss, I believe I'd accomplish this with some sort of .xml file a la
>>> *-ds.xml; either its name or some element within that file would
>>> designate
>>> the JNDI name.  I'm not terribly familiar with JBoss.
>>> In Glassfish, I believe I'd have to do this with the Glassfish command
>>> line
>>> tools; something like asadmin deploy myrar.rar.
>>> What do I do in OpenEJB in an in-memory unit testing scenario?
>>> My ultimate goal is to have my @LocalClient simply do:
>>>  @Resource(name="...") // whatever the name is
>>>  private MyConnectionFactoryImplementation myConnector;
>>> and have it "just work".
>>> Any pointers in any direction are gratefully accepted.
>>> Best,
>>> Laird

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message