request : allow client to choose jndi.properties location

[BR-Nicholas-Prado]

We use birt as our reporting framework in a non-servlet application. We would like to use jndi to supply the connection. We used JndiKit to serve this. However, we were unable to convince birt to consume our properties file to reach the datasource, because it does not look in an amenable place for it.

Specifically, JndiDataSource.getDriverJndiPropertyFile() uses OdaJdbcDriver.getDriverDirectory() which uses ManifestExplorer.getInstance().getDriverLocation() . Because we use gradle to depend on the birt runtime and the mysql jdbc driver, this points to the jar in my gradle cache. : file:/opt/workspace/gradle/caches/modules-2/files-2.1/com.innoventsolutions.birt.runtime/org.eclipse.birt.runtime_4.8.0-20180626/4.8.0/5fbd2fa6b165bb5b5493b2acdd6832257b97f5de/org.eclipse.birt.runtime_4.8.0-20180626-4.8.0.jar!/drivers . Changing the birt home of the engine config to the working directory prefixes that directory to the previous filepath. I wasn't able to work around this issue by creating a folder of the same name as the jar, as I can not have a file and folder of the same name in a folder. Hence, I can't copy my jndi properties file without zipping it into the birt runtime jar itself until #625 works.

It would help for my use case - which I recognize is the minority - to allow programmatic configuration of some aspect of the birt engine, such that JndiDataSource can look for a jndi.properties file in an arbitrary location of the same filesystem.

It would also be nice if the complaint about jndi explained where it failed to find the properties file (with FINEST logging), given that it does check and lets InitialContext mistakenly suggest an environment variable.

[hvbtup]

I am really a Gradle (and Maven) noob, but to me it it seems hazardous to depend on libraries in some cache directory at runtime. Is that common practice when using Gradle?

[BR-Nicholas-Prado]

That's what intellij uses for a project with dependencies defined through gradle. I presume eclipse does something analagous. I don't know the driver directory used for an instance run with java.exe. I'll see if I can use jdb to answer that question.

[ruspl-afed]

I assume your request is mostly about allowing to configure the location of jndi.properties and has nothing about build technology. What way of configuration do you have in mind?

[BR-Nicholas-Prado]

For my use case, I recommend allowing a configuration before starting the platform, perhaps in EngineConfig.

I acknowledge that I am not familiar with Eclipse / Birt conventions. It looks like the closest they approach is AbstractDataEngine.prepare() receives appContext which contains "EngineTask" which contains engine which contains config. Prepare defines a dataset which gets a data set and then defines it. Defining a data set in ModelDteApiAdapter gets a data source and then defines it. If it were to add (relevant) information from the engine config to the datasource's properties, those will propagate down to JndiDataSource where get getDriverJndiPropertyFile() can check for a folder path, or fall back to the driver location, given that works for other use cases.

As long as I can add it programmatically, I don't have a strong opinion about how to define a jndi.properties filepath. I could give it to the runner just as easily as to the engine.