7

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?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • I don't think this is possible. Your best option might be to open an RFE... – Brett Kail Sep 01 '16 at 07:30
  • @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? – Arjan Tijms Sep 01 '16 at 08:30
  • 1
    the only other way I can think of is if you specify a ` ...` 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. – Andy Guibert Sep 01 '16 at 14:20
  • 1
    What do you mean by "global driver"? Do you mean a [global shared library](http://www.ibm.com/support/knowledgecenter/en/SSAW57_liberty/com.ibm.websphere.wlp.nd.doc/ae/twlp_classloader_global_libs.html)? Well, I suppose another alternative would be to send a pull request to Arquillian to support what you're trying to do :-). – Brett Kail Sep 01 '16 at 14:20
  • Well, never mind my global shared library suggestion per @aguibert's comment :-). – Brett Kail Sep 01 '16 at 14:21
  • @aquibert Indeed, @DSD/data-source doesn't work with global shared library. Thanks in advance for fixing it ;) – Arjan Tijms Sep 01 '16 at 15:58
  • @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. – Arjan Tijms Sep 01 '16 at 16:04
  • 1
    @BrettKail with some delay, but here's the link to the RFE: https://ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=96074 – Arjan Tijms Oct 19 '16 at 17:42

0 Answers0