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!
