There have been a few mentions of using a JNDI datasource with Lucee. I’m wondering if anyone has gotten this to work. Essentially, I want to define the datasource on the container and simply reference the name in the application with the expectation that it’s there. This also allowed me to build and deploy additional servlets along side Lucee. I was able to do this with ACF, but it doesn’t look like Lucee will look at the JNDI space for supplied datasources. Would there be a way to perform that lookup and create in the application.cfc? Can anyone advise?
I wrote the code for this years ago.
My original repo
Was merged into JDBC Extension factory Nov 2016
With JIRA (still unresolved?)
https://luceeserver.atlassian.net/browse/LDEV-892
And open github issue
Because it doesn’t appear the extension is actually released or available anywhere? Without manually creating your own lex from the repo? I’m not sure what determines which files get released and which ones don’t.
So you’d have to
-
cd JDBC-extension-factory
-
ant
-
Deploy the dist/JNDIDriver-JDBC-1.0.13.lex extension
-
Have fun
You may need ant extensions, ant-contrib, other tools on your machine to do this.
Since I just went through that process… I don’t have access to the lucee repo but I can post it on mine.
Download the lex and install the extension and then create a JNDI Datasource.
Thanks @joe.gooch, I found your code in my searches, and I also voted for the JIRA issue. I, too, am confused to see the accepted merge request, but not find any JNDI functionality in Lucee. I was also confused to see the JDBC Extension Factory project is deprecated, but there’s no link to a replacement. I’m pretty disappointed; I thought Lucee had a lot more energy and attention being paid.
Thanks for the release artifact - I’ll give that a shot.
I believe the deprecation notice in JDBC Extension Factory is just specific drivers:
##Deprecated MySQL, MSSQL, TeraData and Postgres SQL drivers are moved to independent projects. Look for [https://github.com/lucee/extension-jdbc-*](https://github.com/lucee/extension-jdbc-*) Soon all drivers will be moved to independent projects.
Mysql, MSSQL, TeraData and Postgres are in other repos.
But H2, Oracle, Derby, JNDI etc should still come from this repo.
Now, just so I’m clear - I’d drop the .lex file into the lucee-server/deploy directory, but I’d still need to create a new datasource in for the site through the admin? I can’t simply <cfquery datasource="name"> and have that name be found through JNDI?
My use-case for this setup achieves two objectives: first, I’m deploying servlets along with my CF and this lets me refer to the same datasource outside of lucee; second, it ensures there’s no misconfiguration by pointing to the wrong database. It also allows me to keep the credentials and database environment isolated from my application.
Correct. Just like ACF
Just an observation here. Not to persuade you from pursuing your JNDI solutions, but if all you want is to ensure consistent data source connections between apps, this seems like it could be solved with a bit of automation and release engineering with much less complication. For instance, we use a combination of CFConfig and environment variables to setup datasource connections across all our app deploys and it allows us to both share credentials and such across more than one app as well as extract all of that logic from the source code as well. There are a lot of options to externalize the details of your DB connections without needing to wander off in the land of JNDI.
Or alternatively, configure it in CF only, and reuse from Java. Instead of doing JNDI in our case (on ACF), we just enable J2EE sessions, and save the actual java.sql.Datasource in the session so java can access it.
Ok, so this could be getting a bit beyond my original thread. But I looked into CFConfig, and it appears that it all hinges on knowing the location of the WEB-INF/lucee/lucee-web.xml.cfm file, correct?
CFConfig works directly with the XML and properties files that configure the CF engine so yes, it does need to know where on the hard drive the CF engine is installed to.