tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Lykke Christensen <>
Subject Re: Unit testing code containing DirContext resource injection
Date Thu, 09 Jul 2009 07:41:32 GMT
Thanks for the tips David. It has taken me ages getting back to the  
code where I was using OpenEJB for testing, hence the late response.

In terms of LDAP, I figured that there was no need to inject it via  
JNDI. DirContext is already connection pooled by default and adding it  
to the JNDI registry wouldn't really serve any purpose.

However, the RAR technique will come in handy as I'm trying to use the  
JackRabbit Content Repository Service. I've never had to work with RAR  
before, so I'll have to get my head around how it works before  
bothering you more.

I still got an issue relating to what I was doing initially with  
LDAP.   I've got some objects that are added to the JNDI registry at  
run-time. Hence,  I don't know their JNDI names at compile-time. I've  
got the following code in one of my EJBs to look up the objects:

public ContentService getRepository(String jndiName) throws  
NamingException {
         Context ctx = new InitialContext();
         ContentService cs = (ContentService) ctx.lookup(jndiName);
         return cs;

In my unit test I  bind some "ContentService" objects to the  

public void testGetRepository() {
     Properties p = new Properties();
     InitialContext initialContext = new InitialContext(p);
     initialContext.bind("cs/MyObject", new ContentService("Something  

     ContentFacadeLocal bean = (ContentFacadeLocal)  
     try {
         ContentService cs = bean.getRepository("cs/MyObject");
     } catch (NamingException ex) {

When I run the test a NamingException is thrown with the message  
"javax.naming.NoInitialContextException: Need to specify class name in  
environment or system property, or as an applet parameter, or in an  
application resource file:  java.naming.factory.initial"

While debugging the test I realised that the InitialContext created in  
the bean didn't have the Context.INITIAL_CONTEXT_FACTORY injected.  
Isn't this suppose to happen transparently?

Thanks again for your help! Woking on a series of blog entries focused  
on unit testing where OpenEJB is the cornerstone.

All the best,

On 19/06/2009, at 22.58, David Blevins wrote:

> On Jun 19, 2009, at 1:53 AM, Allan Lykke Christensen wrote:
>> Thanks for your response.
>> I'm starting to think that my LDAP integration is non-standard and  
>> should be done in another way. What you are suggesting is that  
>> there might be a JCA connector for LDAP?  In any case, there is  
>> nothing vendor-specific about my current integration. I'm using a  
>> vendor-neutral LdapConnectionFactory for obtaining a connection  
>> from a connection pool.  Perhaps I should bring the connection code  
>> into my application instead and forget about registering the JNDI  
>> name in GlassFish. Having a bit of difficulty finding the best  
>> practice for my use case as you can probably sense.
> If the LDAP support is coming from a JCA connector (which it sounds  
> like it is), then you have a picture perfect setup and I wouldn't  
> change a thing.
> To get this to work in OpenEJB/Maven land we just need to deploy  
> your .rar file that is providing the LDAP support.
> This is a bit of work to setup as we have to work around Maven --  
> Maven does not like rars.  We essentially need to "unwrap" that rar  
> as Maven is hardwired to ignore rar files and will not included them  
> in the classpath as it doesn't know how to include the jars *inside*  
> the rar in the classpath.
> So one basic technique I've used is to sort of convert the rar to a  
> maven module by making a new module named after the rar in some way  
> (any name is fine), copying the ra.xml file to src/main/resources/ 
> META-INF/ra.xml, and declaring maven dependencies on all the jars  
> the rar needs (i.e. the ones you normally find inside the rar file).
> The trick is that usually the jars inside the rar are not available  
> in any maven repos so you'll have to install them all into your  
> local repo.  If you're lazy like me, you can just make up groupId  
> and artifactIds for these jars and add them to the pom.xml as if  
> they were already in the repo, then just run a 'mvn clean install'  
> and maven will be kind enough to spit out all the 'install:install- 
> file' commands with the parameters already filled in.
> Once you have that "rar replacement module" you can simply depend on  
> it from your ejb module and OpenEJB will find and deploy the rar and  
> all the injection should work fine.
> An example exists, but unfortunately we can't include it in our  
> examples zip as it has LGPL'ed code in it which is not allowed for  
> us.  But here's the related email and JIRA issue:
> (http// 
> Anyway, hope that helps.
>> You are welcome regarding the tweet. I'm planning to write a blog  
>> entry about mixing OpenEJB, DBUnit, and Apache Derby for unit  
>> testing in the near future as well.
> That's great.  When you do, make sure and ping us and we'll post  
> about your entry in our blog.  You could likely do two posts if you  
> wanted, the one you mention and one about creating a rar module for  
> your LDAP connector.
> Let us know if you encounter any trouble.
> -David
>> On 19/06/2009, at 08.01, David Blevins wrote:
>>> Hi Allen,
>>> DirContext isn't one of the required java ee types such as  
>>> DataSource or UserTransaction, so I'm guessing that there must be  
>>> some sort of LDAP J2EE Connector for it.  If that's the case it  
>>> should be easy to hook up in OpenEJB as well.  If not then it's a  
>>> vendor specific feature, which we'd be more than happy to support  
>>> as well provided we can get enough information on how it should  
>>> work so we can code it up.
>>> Let us know.
>>> -David
>>> PS Thanks for the tweet!

View raw message