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
InitialContext
@Test
public void testGetRepository() {
Properties p = new Properties();
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
InitialContext initialContext = new InitialContext(p);
initialContext.bind("cs/MyObject", new ContentService("Something
something"));
ContentFacadeLocal bean = (ContentFacadeLocal)
getInitialContext().lookup(BEAN_INTERFACE);
try {
ContentService cs = bean.getRepository("cs/MyObject");
assertNotNull(cs);
} catch (NamingException ex) {
fail(ex.getMessage());
}
}
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,
Allan
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://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18783086.html
(http//issues.apache.org/jira/secure/attachment/12387373/quartz-
app.zip)
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!
