Loading data source for @DataSourceDefinition from application in Liberty

Question

For usage with @DataSourceDefinition I'd like to have the DataSource class loaded from the application that uses this @DataSourceDefinition annotation (or equivalent data-source element in a deployment descriptor).

This works for basically every server as per the test I added in the Java EE 7 samples project.

For example, considering this data source definition in web.xml:

<data-source>
    <name>java:app/MyApp/MyDS</name>
    <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
    <url>jdbc:h2:mem:test</url>
</data-source>

The jar containing org.h2.jdbcx.JdbcDataSource would reside in WEB-INF/lib.

This is very convenient in CI testing when testing against a server that's automatically downloaded, and where the name of the deployed .war is unknown in advance (since controlled by say Arquillian).

While nearly every server supports this, Liberty 16.0.2 throws the following exception for either java:app/MyApp/MyDS or java:global/MyDS:

CWNEN0011E: The injection engine failed to process bindings for the metadata due to the following error: java.sql.SQLNonTransientException: J2CA8022E: Application xyz23-zvf does not have any shared libraries that provide org.h2.jdbcx.JdbcDataSource for dataSource java:global/MyDS.

The IBM instructions refer to setting up a shared library that lives on the local file system, but for several classes of data sources (e.g. those that only have internal meaning to the application), as well as for the mentioned CI testing this is not practical.

Is there any way to let Liberty load the data source from the application like most other Java EE servers do?

Prudy

I don't think this is possible. Your best option might be to open an RFE... – Puffer

@BrettKail thanks for the reply Brett, I'll open that RFE then. An alternative intermediate solution would be to have a global driver in server.xml (without having to put a class loader in the app element, since that is not really under my control when using Arquillian). Unfortunately that also doesn't seem to work. Any idea if that can be made possible? – Prudy

the only other way I can think of is if you specify a <library id="global"> ... in your server.xml, or put the jar in ${shared.config.dir}/lib/global or ${server.config.dir}/lib/global (which are the default locations for the global library). If you use the global library approach, a nested classloader should not need to be specified. That being said, it doesn't work with @DSD, which is a defect. We'll get an issue opened internally to track fixing that. – Impanel

What do you mean by "global driver"? Do you mean a global shared library? Well, I suppose another alternative would be to send a pull request to Arquillian to support what you're trying to do :-). – Puffer

Well, never mind my global shared library suggestion per @aguibert's comment :-). – Puffer

@aquibert Indeed, @DSD/data-source doesn't work with global shared library. Thanks in advance for fixing it ;) – Prudy

@BrettKail >"send a pull request to Arquillian to support what you're trying to do" - Good idea, I put this on my TODO list ;) A few select entries being added by Arquillian to server.xml like the class loader and setting specific features should be doable. – Prudy

@BrettKail with some delay, but here's the link to the RFE: ibm.com/developerworks/rfe/… – Prudy