Topics

Eclipselink Cache Coherence: Recommendations and Support

daniel.platz@...
 

Hi,
Liberty comes with Eclipselink as the default persistence provider for Java EE 7 apps.
I would like to use EclipseLink's Cache-Coherence feature:
https://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination
In specific, i would like to use the synchronization via JGroups. So, I added the following to my persistence.xml:
   <property name="eclipselink.cache.coordination.protocol" value="jgroups" />

On startup of Liberty, i got errors along the lines of:
Exception Description: ClassNotFound: [org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager] specified in [eclipselink.cache.coordination.protocol] property.

Some research identified the JGroups support beeing part of an EclipseLink extenion. Namely, org.eclipse.persistence:org.eclipse.persistence.extension that is not coming with Liberty it seems.
So here my questions:
- How to get Cache Coherence with JGroups working? I noticed here that one option might be to package a complete own JPA implemennation as a library (using the Jpa-conatiner feature) and that could include the extension?
- If i would do this, how can i be sure that i use the exact same EclipseLink version that packages by default with Liberty? I assume the EclipseLink version packaged with Liberty is in no way special? Using my own EclipseLink version as a library would be exactly the same assuming i have the same version?
- Or what i would prefer: Is there a way to just add the exension to Liberty to "enrich" the existing JPA provider?
- Or could this extension become part of the vanilla jpa-2.1 feature coming with Liberty?
- In general, is there any recommended Cache Coherence setting that is know to work nicely with Liberty and where someone has experience with? I.e. there is RMI and JMS and both come with core Eclipselink it seems. Any experience here on what is needed to get it running?

Thanks in advance,
Daniel


wadazey@...
 

Hello!

You are definitely on the right track and the research you have done so far seems to all be correct.

> How to get Cache Coherence with JGroups working? I noticed here that one option might be to package a complete own JPA implemennation as a library (using the Jpa-conatiner feature) and that could include the extension?
> If i would do this, how can i be sure that i use the exact same EclipseLink version that packages by default with Liberty? I assume the EclipseLink version packaged with Liberty is in no way special? Using my own EclipseLink version as a library would be exactly the same assuming i have the same version?

As you already found, on Liberty, we have the jpaContainer-2.1 feature that is meant for applications to provide their own JPA provider implementation. The jpaContainer-2.1 feature provides the Java Persistence API 2.1 specification interfaces, and container-managed JPA integration. This means that you can provide your own EclipseLink implementation (including the extension bundle) as described in the document you linked to here. If you go this route, you will not be dependent on the EclipseLink implementation we ship with Liberty and therefore do not need to be at the same level. The only consideration you need to make is in regards to EclipseLink's JPA specification support. EclipseLink 2.6 supports the JPA 2.1 specification, which is what you will get with the jpaContainer-2.1 feature. The newer EclipseLink 2.7 supports the JPA 2.2 specification and will cause some issues when the jpaContainer-2.1 feature provides the wrong specification level API bundles. For this reason, I would recommend you using EclipseLink 2.6 version bundles if you go with this approach.

> Or what i would prefer: Is there a way to just add the exension to Liberty to "enrich" the existing JPA provider?
For THIS approach, you would need your org.eclipse.persistence.extension bundle to be built at the same level as the EclipseLink version we provide with Liberty. It is recommended that you use the jpaContainer-2.1 feature.

> Or could this extension become part of the vanilla jpa-2.1 feature coming with Liberty?
For EclipseLink on Liberty, we made the decision to only include the EclipseLink implementation that is in support of the JPA specification (org.eclipse.persistence.antlr, org.eclipse.persistence.asm, org.eclipse.persistence.core, org.eclipse.persistence.jpa, org.eclipse.persistence.jpa.jpql, & org.eclipse.persistence.jpa.modelgen.processor). The EclipseLink project is comprised of a couple modules that go beyond just the JPA specifications (for instance, Moxy is a JAXB implementation). The extension bundle has a dependency on the JGroup API that we do not ship as a part of Liberty and is not a part of the JPA specification. Unfortunately, this means we are very unlikely to adopt this bundle into the EclipseLink implementation we currently provide.

>In general, is there any recommended Cache Coherence setting that is know to work nicely with Liberty and where someone has experience with? I.e. there is RMI and JMS and both come with core Eclipselink it seems. Any experience here on what is needed to get it running?
Unfortunately, I do not have any experience using EclipseLink's Cache Coordination. There is some EclipseLink documentation that describes using cache coordination using WebSphere, but I have never used this myself. If anyone has experience getting this working and would like to chime in, I'd appreciate it!

Thanks,
Will Dazey

daniel.platz@...
 

Thanks for the very detailed reply! I really appreciate it.
To bad the decision was made to not include these extensions into the core of liberty. I feel a little uncomfortable to configure "my own" eclipse-link version as this will create my own "liberty-snowflake-solution"; and if possible I would like to stay away from that. That's why I at least would like to make sure to use exactly the same version of eclipse-link as is coming with Liberty.
But as a very first step I just would like to get it running, so i tried to follow along the guide found here:
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_dep_jpa.html

I downloaded the "EclipseLink 2.6.5 Installer Zip" from here:
http://www.eclipse.org/eclipselink/downloads/index.php#26

Following along the guide, it confused me that the name and structure of the jars seems to be different than what is mentioned in the guide. In the end, i now only added two jars as part of the library because i could not find the other jars. So, my server.xml looks like this currently:

<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">
 
    <!-- Enable features -->
    <featureManager>
        <feature>javaee-7.0</feature>
        <feature>jpaContainer-2.1</feature>
    <feature>bells-1.0</feature>
    </featureManager>
 
 
    <basicRegistry id="basic" realm="BasicRealm"> 
    </basicRegistry>
    
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
                  
    <applicationManager autoExpand="true"/>
 
    <bell libraryRef="eclipselink"/>
<library id="eclipselink">
    <file name="${server.config.dir}/lib/eclipselink.jar"/>
    <file name="${server.config.dir}/lib/org.eclipse.persistence.extension_2.6.5.v20170607-b3d05bd.jar"/>
</library>
 
<application location="cacher.war">
    <classloader commonLibraryRef="eclipselink"/>
</application>
 
</server>

When i start the server with the application, i see the following classcast-exception:

Launching defaultServer (Open Liberty 18.0.0.2/wlp-1.0.21.20180525-1300) on OpenJDK 64-Bit Server VM, version 1.8.0_171-b10 (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /home/daniel/junk/wlp/usr/servers/defaultServer/configDropins/defaults/postgres-jdbc.xml
[WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT   ] CWPKI0820A: The default keystore has been created using the 'keystore_password' environment variable.
[AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
[WARNING ] CWWJP9991W: Exception [EclipseLink-7308] (Eclipse Persistence Services - 2.6.5.WAS-v20180104-90e991c): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The specified value [org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager] for for the persistence property [eclipselink.cache.coordination.protocol] is invalid - [java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager].
Internal Exception: java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager
[ERROR   ] CWWJP9992E: Exception [EclipseLink-7308] (Eclipse Persistence Services - 2.6.5.WAS-v20180104-90e991c): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The specified value [org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager] for for the persistence property [eclipselink.cache.coordination.protocol] is invalid - [java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager].
Internal Exception: java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager
[ERROR   ] CWWJP0015E: An error occurred in the org.eclipse.persistence.jpa.PersistenceProvider persistence provider when it attempted to create the container entity manager factory for the DefaultPU persistence unit. The following error occurred: Exception [EclipseLink-7308] (Eclipse Persistence Services - 2.6.5.WAS-v20180104-90e991c): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The specified value [org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager] for for the persistence property [eclipselink.cache.coordination.protocol] is invalid - [java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager].
Internal Exception: java.lang.ClassCastException: org.eclipse.persistence.sessions.coordination.jgroups.JGroupsTransportManager cannot be cast to org.eclipse.persistence.sessions.coordination.TransportManager
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/cacher/
[AUDIT   ] CWWKZ0001I: Application cacher started in 3.152 seconds.
[AUDIT   ] CWWKF0012I: The server installed the following features: [servlet-3.1, beanValidation-1.1, ssl-1.0, jndi-1.0, jca-1.7, jms-2.0, ejbPersistentTimer-3.2, appSecurity-2.0, j2eeManagement-1.1, jdbc-4.1, wasJmsServer-1.0, jaxrs-2.0, javaMail-1.5, cdi-1.2, webProfile-7.0, jcaInboundSecurity-1.0, jpa-2.1, jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, ejbHome-3.2, jaxws-2.2, bells-1.0, jsonp-1.0, el-3.0, jaxrsClient-2.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, javaee-7.0, jaxb-2.2, mdb-3.2, jacc-1.5, batch-1.0, ejb-3.2, json-1.0, jaspic-1.1, jpaContainer-2.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
[AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

I assuming i did not do anything wrong with my library-definition in general (which I am not sure about), I thought maybe the problem is related to still seeing  jpa-2.1 and jpaContainer-2.1 in the list of features on Liberty-startup.
Now I was wondering if there is a way to exclude the jpa-2.1 feature but still be able to use <feature>javaee-7.0</feature> as this is very convenient... assuming this is the problem. To just double-check, i instead listed all the features explicitly, but removed jpa:

    <featureManager>
<feature>servlet-3.1</feature>
<feature>beanValidation-1.1</feature>
<feature>ssl-1.0</feature>
<feature>jndi-1.0</feature>
<feature>jca-1.7</feature>
<feature>jms-2.0</feature>
<feature>ejbPersistentTimer-3.2</feature>
<feature>appSecurity-2.0</feature>
<feature>j2eeManagement-1.1</feature>
<feature>jdbc-4.1</feature>
<feature>wasJmsServer-1.0</feature>
<feature>jaxrs-2.0</feature>
<feature>javaMail-1.5</feature>
<feature>cdi-1.2</feature>
<feature>webProfile-7.0</feature>
<feature>jcaInboundSecurity-1.0</feature>
<feature>jsp-2.3</feature>
<feature>ejbLite-3.2</feature>
<feature>managedBeans-1.0</feature>
<feature>jsf-2.2</feature>
<feature>ejbHome-3.2</feature>
<feature>jaxws-2.2</feature>
<feature>bells-1.0</feature>
<feature>jsonp-1.0</feature>
<feature>el-3.0</feature>
<feature>jaxrsClient-2.0</feature>
<feature>concurrent-1.0</feature>
<feature>appClientSupport-1.0</feature>
<feature>ejbRemote-3.2</feature>
<feature>javaee-7.0</feature>
<feature>jaxb-2.2</feature>
<feature>mdb-3.2</feature>
<feature>jacc-1.5</feature>
<feature>batch-1.0</feature>
<feature>ejb-3.2</feature>
<feature>json-1.0</feature>
<feature>jaspic-1.1</feature>
<feature>jpaContainer-2.1</feature>
<feature>distributedMap-1.0</feature>
<feature>websocket-1.1</feature>
<feature>wasJmsSecurity-1.0</feature>
<feature>wasJmsClient-2.0</feature>
    </featureManager>

If i start Liberty again, it seems nothing has changed an jpa is still included:

[AUDIT   ] CWWKF0012I: The server installed the following features: [servlet-3.1, beanValidation-1.1, ssl-1.0, jndi-1.0, jca-1.7, jms-2.0, ejbPersistentTimer-3.2, appSecurity-2.0, j2eeManagement-1.1, jdbc-4.1, wasJmsServer-1.0, jaxrs-2.0, javaMail-1.5, cdi-1.2, webProfile-7.0, jcaInboundSecurity-1.0, jpa-2.1, jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, ejbHome-3.2, jaxws-2.2, bells-1.0, jsonp-1.0, el-3.0, jaxrsClient-2.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, javaee-7.0, jaxb-2.2, mdb-3.2, jacc-1.5, batch-1.0, ejb-3.2, json-1.0, jaspic-1.1, jpaContainer-2.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
[AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

I also now tried to remove webProfile as i assumed it is maybe pulled in transitively somehow? Anyway, it did not make a difference. jpa-2.1 is still there.

I also assumed that yaybe in the end i also need to add the jar for the JPA-classes itself to the library. The eclipse-link.zip contained "javax.persistence_2.1.1.v201509150925.jar". So, i also aded it to the library; but the error remains the same.

Any suggestions what I might be doing wrong?

Thanks,
Daniel 

daniel.platz@...
 

Ok, my mistake. I still had "javaee-7.0" in the feature but i did not see it at first. Now removed it and also webProfile. Getting the following error now:
Caused by: java.lang.ClassNotFoundException: org.jgroups.JChannel
at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonLibraryClassLoaders(AppClassLoader.java:504)
at com.ibm.ws.classloading.internal.AppClassLoader.findClass(AppClassLoader.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at com.ibm.ws.classloading.internal.AppClassLoader.findOrDelegateLoadClass(AppClassLoader.java:482)
at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppClassLoader.java:443)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 
I am not sure what jgroups version is the correct one but i looked the version up from here for a first try:
https://github.com/eclipse-ee4j/eclipselink/blob/339316cb45b2999ea0979c06677699b034d812ff/foundation/org.eclipse.persistence.extension/pom.xml
So, downloaded this one: https://sourceforge.net/projects/javagroups/files/JGroups/3.4.5.Final/
and it seems to work as far as I can tell right now. At least the application starts up and i see some movement from the jgroups...
server.xml is now:
<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">
 
    <!-- Enable features -->
    <featureManager>
<feature>servlet-3.1</feature>
<feature>beanValidation-1.1</feature>
<feature>ssl-1.0</feature>
<feature>jndi-1.0</feature>
<feature>jca-1.7</feature>
<feature>jms-2.0</feature>
<feature>ejbPersistentTimer-3.2</feature>
<feature>appSecurity-2.0</feature>
<feature>j2eeManagement-1.1</feature>
<feature>jdbc-4.1</feature>
<feature>wasJmsServer-1.0</feature>
<feature>jaxrs-2.0</feature>
<feature>javaMail-1.5</feature>
<feature>cdi-1.2</feature>
<feature>jcaInboundSecurity-1.0</feature>
<feature>jsp-2.3</feature>
<feature>ejbLite-3.2</feature>
<feature>managedBeans-1.0</feature>
<feature>jsf-2.2</feature>
<feature>ejbHome-3.2</feature>
<feature>jaxws-2.2</feature>
<feature>bells-1.0</feature>
<feature>jsonp-1.0</feature>
<feature>el-3.0</feature>
<feature>jaxrsClient-2.0</feature>
<feature>concurrent-1.0</feature>
<feature>appClientSupport-1.0</feature>
<feature>ejbRemote-3.2</feature>
<feature>jaxb-2.2</feature>
<feature>mdb-3.2</feature>
<feature>jacc-1.5</feature>
<feature>batch-1.0</feature>
<feature>ejb-3.2</feature>
<feature>json-1.0</feature>
<feature>jaspic-1.1</feature>
<feature>jpaContainer-2.1</feature>
<feature>distributedMap-1.0</feature>
<feature>websocket-1.1</feature>
<feature>wasJmsSecurity-1.0</feature>
<feature>wasJmsClient-2.0</feature>
    </featureManager>
 
 
    <basicRegistry id="basic" realm="BasicRealm"> 
    </basicRegistry>
    
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
                  
    <applicationManager autoExpand="true"/>
 
    <bell libraryRef="eclipselink"/>
<library id="eclipselink">
    <file name="${server.config.dir}/lib/eclipselink.jar"/>
    <!--file name="${server.config.dir}/lib/javax.persistence_2.1.1.v201509150925.jar"/-->
    <file name="${server.config.dir}/lib/org.eclipse.persistence.extension_2.6.5.v20170607-b3d05bd.jar"/>
    <file name="${server.config.dir}/lib/jgroups-3.4.5.Final.jar"/>
</library>
 
<application location="cacher.war">
    <classloader commonLibraryRef="eclipselink"/>
</application>
 
</server>

The one thing that i would like to get rid of is listing all the javaee-7.0 features (minus jpa). If anyone know about an approach to get rid of this, please let me know. Maybe there is a mechansim like a <featureExclude>jpa-2.1</featureExclude>?


Thanks,

Daniel

wadazey@...
 

Hello!

> I downloaded the "EclipseLink 2.6.5 Installer Zip" from here:
> http://www.eclipse.org/eclipselink/downloads/index.php#26
>Following along the guide, it confused me that the name and structure of the jars seems to be different than what is mentioned in the guide. In the end, i now only added two jars as part of the library because i could not find the other jars

One thing I want to point out is that EclipseLink is comprised of several, smaller Eclipse projects: org.eclipse.persistence.jpa, org.eclipse.persistence.core, org.eclipse.persistence.jpa.jpql, org.eclipse.persistence.nosql, org.eclipse.persistence.oracle, ect. You can see their individual, built OSGI bundles here. One weird bundle they create though is called "eclipselink.jar". This bundle is just a collection of those smaller bundles rolled into one (though it isn't actually an OSGI bundle and is meant more for SE environments). I forget just how many projects are thrown in there, but I believe at least core, jpa, jpql, oracle, asm, antlr, sdo, & moxy are all included. Also, as you may have noticed, the JPA persistence API classes are also bundled with this jar! That is going to cause some classloading conflicts with the persistence provided by the jpaContainer-2.1 feature!
EclipseLink builds the individually consumable OSGI bundles that are more easily consumable in an EE environment. I would recommend you download EclipseLink 2.6.5 OSGi Bundles Zip . In this zip, you should find bundles with names that align with the guide much better.

> I assuming i did not do anything wrong with my library-definition in general (which I am not sure about), I thought maybe the problem is related to still seeing  jpa-2.1 and jpaContainer-2.1 in the list of features on Liberty-startup.
Now I was wondering if there is a way to exclude the jpa-2.1 feature but still be able to use <feature>javaee-7.0</feature> as this is very convenient... assuming this is the problem

Yes, the javaee-7.0 convenience feature includes the webProfile-7.0 convenience feature, which includes the jpa-2.1 feature. With the jpa-2.1 feature, you get the Liberty shipped EclipseLink bundles! Which are going to collide with the EclipseLink implementation you want to provide yourself. This is going to cause issues.

> If i start Liberty again, it seems nothing has changed an jpa is still included:
 Unfortunately, webProfile-7.0 is still there and is providing the jpa-2.1 feature

> I also now tried to remove webProfile as i assumed it is maybe pulled in transitively somehow? Anyway, it did not make a difference. jpa-2.1 is still there.
Yep, this is what I would have thought. I see in your second server.xml that both javaee-7.0 and webProfile-7.0 are there. If you removed webProfile-7.0, is javaee-7.0 still there? These two convenience features come to mind as pulling in jpa-2.1 so I think you should make sure they are not in your server.xml.

> I also assumed that yaybe in the end i also need to add the jar for the JPA-classes itself to the library. The eclipse-link.zip contained "javax.persistence_2.1.1.v201509150925.jar". So, i also aded it to the library; but the error remains the same.
Ya, as I mentioned above, you shouldn't provide your own JPA persistence API bundle (javax.persistence). The jpaContainer-2.1 feature provides that for you. All you need to provide is the JPA provider implementation. One issue, as you saw with the eclipselink.jar, is that some JPA providers bundle their own JPA persistence bundles with their product (Hibernate does this too)! They do this mostly so that SE environment users have a much easier time adding their JPA provider bundles to the classpath and NOT needing to go download java.persistence APIs themselves. In an EE environment tho, it causes some classloading issues.

Let me know if any of this was helpful and if you were able to make some progress! :)

Thanks,
Will Dazey

wadazey@...
 

Hello!

> Ok, my mistake. I still had "javaee-7.0" in the feature but i did not see it at first. Now removed it and also webProfile
Ah, glad to hear that fixed that issue. I suppose I should have read your second post first!

> Getting the following error now:
> Caused by: java.lang.ClassNotFoundException: org.jgroups.JChannel
Try what I suggested in my previous reply (using EclipseLink 2.6.5 OSGi Bundles Zip) and removing the JPA Persistence API bundles (javax.persistence). See if you still get this CNFE then.

> The one thing that i would like to get rid of is listing all the javaee-7.0 features (minus jpa). If anyone know about an approach to get rid of this, please let me know. Maybe there is a mechansim like a <featureExclude>jpa-2.1</featureExclude>?

I completely agree with you. I asked around and I couldn't figure out myself how to make the list any easier. The one thing I will offer is that it is entirely possible you are pulling in more features than you actually need! I am not sure all of what your application needs, but there may be many features from javaee-7.0 that you don't need to include. Maybe take a closer look at your list and start cutting out some features you are not using?

Hope this helps!

Thanks,
Will Dazey


daniel.platz@...
 

Hi,
> Getting the following error now:
> Caused by: java.lang.ClassNotFoundException: org.jgroups.JChannel
Try what I suggested in my previous reply (using EclipseLink 2.6.5 OSGi Bundles Zip) and removing the JPA Persistence API bundles (javax.persistence). See if you still get this CNFE then.
I now switched to using the OSGI bundles. The CNFE still happens when i not also explictly get the jgroups.jar. But i assume this is expected because I dont think jgroups is packaged in the eclipselink jar. So my finall library now looks like this:

<library id="eclipselink">
<file name="${server.config.dir}/jpa/org.eclipse.persistence.asm.jar"/>
<file name="${server.config.dir}/jpa/org.eclipse.persistence.core.jar"/>
<file name="${server.config.dir}/jpa/org.eclipse.persistence.jpa.jar"/>
<file name="${server.config.dir}/jpa/org.eclipse.persistence.antlr.jar"/>
<file name="${server.config.dir}/jpa/org.eclipse.persistence.jpa.jpql.jar"/>
<file name="${server.config.dir}/jpa/org.eclipse.persistence.jpa.modelgen.jar"/>
 
<file name="${server.config.dir}/jpa/org.eclipse.persistence.extension.jar"/>
<file name="${server.config.dir}/jpa/jgroups.jar"/>
</library>

So, basically what is in the official guide + org.eclipse.persistence.extension.jar + jgroups.jar.

Actually, the final approach i have taken is to place the jars in the lib/global folder to reduce the amount on configuration needed in the server.xml.
One disadvantage i could also solve with this was that it will alsp work with applications in the dropins folder. Because the explicit library in the server.xml requires to reference it from each individual application like so it seems:

<application location="myapp.war">
    <classloader commonLibraryRef="eclipselink"/>
</application>



> The one thing that i would like to get rid of is listing all the javaee-7.0 features (minus jpa). If anyone know about an approach to get rid of this, please let me know. Maybe there is a mechansim like a <featureExclude>jpa-2.1</featureExclude>?

I completely agree with you. I asked around and I couldn't figure out myself how to make the list any easier. The one thing I will offer is that it is entirely possible you are pulling in more features than you actually need! I am not sure all of what your application needs, but there may be many features from javaee-7.0 that you don't need to include. Maybe take a closer look at your list and start cutting out some features you are not using?
For sure I am not using all javaee-7.0 features currently/always; so you are right that in theory i could strip down the list be removing indivial featurs. But for me the advantage of Java EE is that I always get the full package and dont have to worry what I will use of the spec. I can always assume i can use everything.
If i could dream up a solution, I would prefer something like this:
<featureManager>
  <feature>javaee-7.0</feature>
  <featureExclude>jpa-2.1</featureExclude>
  <feature>jpaContainer-2.1</feature>
<featureManager>

Thanks for the help,
Daniel

mcmanus.tom@...
 

By chance are you using the WebSphere Developer tools?   If you were, when you “Run on Server”, it should populate you feature list for you.   

daniel.platz@...
 

Hi mcmanus,
No, i am not. Also not sure what that means. I am just talking about the plain server.xml. Obviously i can list the features manually or let the list be generated by some IDE/tool. But I would like to have the featurelist in the server.xml as simple as possible. Usually that means, just having javaee-7.0 as the only feature. Now, I need to list a lot of features. If an IDE can generate the list for me is not my concern.

Cheers,

Daniel

mcmanus.tom@...
 

If you “deploy” or “run on server” from the IDE, it looks at what features you are using and adds them to the server.xml.   You can also package from the free IDE.  

You can add you library as well.   

The IDE is eclipse based set of plugins.   It can be found at WASDev.net. Look under downloads.

daniel.platz@...
 

Hi,
I understand now. I used the Eclipse-integration in the past. But I would prefer a solution that is indenpendent of any IDE and just works on the level of the server.xml.
After thinking about it for some time: Is there every any reason why the features"jpaContainer" and "jpa" should ever be running in conjunction?
If not, would it not make sense to build some logic in liberty to automatically disable/remove the "jpa" module when the "jpaContainer" module is in the featurelist? This would allow me to write the following feature:

<featureManager>
  <feature>javaee-7.0</feature>
  <feature>jpaContainer-2.1</feature>
<featureManager>

This would be a very friendly way of configuring an alternative persistence provider. Just a though; and maybe worth a change-request?

Also, I have tried to sum up all the steps to get EclipseLinks's cache-coordination working with JGroups on Liberty: http://dplatz.de/blog/2018/wlp-eclipselink-cache-coordination.html

Thanks,

Daniel

wadazey@...
 

Hello!
I now switched to using the OSGI bundles. The CNFE still happens when i not also explictly get the jgroups.jar. But i assume this is expected because I dont think jgroups is packaged in the eclipselink jar.
Yep, that is expected. JGroups is not packaged in EclipseLink. This is actually one of the reasons we can't ship these extension packages with our EclipseLink version in Liberty. Since JGroups is not shipped with Liberty, we would have a dependency on application libraries (for instance, jgroup.jar). We can't have these hard dependencies on outside bundles and since we don't provide the bundle internally, there isn't much we can do atm.

After thinking about it for some time: Is there ever any reason why the features "jpaContainer[-2.1]" and "jpa[-2.1]" should ever be running in conjunction?If not, would it not make sense to build some logic in liberty to automatically disable/remove the "jpa" module when the "jpaContainer" module is in the featurelist?
Actually, take a look at the com.ibm.websphere.appserver.jpa-2.1.feature. The jpaContainer-2.1 feature is meant to just provide the Java Persistence API 2.1 specification interfaces (javax.persistence.*), and container-managed JPA integration. The jpa-2.1 feature provides EclipseLink as the JPA provider implementation, but also includes the jpaContainer-2.1 feature so that we can link up to the spec and container integration! In essence, this looks like:

jpaContainer-2.1 = JPA 2.1 spec + container integration
jpa-2.1 = jpaContainer-2.1 + EclipseLink impl

This means that even if your using the jpa-2.1 feature, you have the jpaContainer-2.1 feature being loaded by association... As far as the "<featureExclude>" option, this might be a good enhancement suggestion!

Also, I have tried to sum up all the steps to get EclipseLinks's cache-coordination working with JGroups on Liberty: http://dplatz.de/blog/2018/wlp-eclipselink-cache-coordination.html
Wow! Good work compiling this all together and testing this out! If you don't mind, I'll be saving this link as a reference to any further questions regarding EclipseLink's cache coordination on Liberty.

Thanks,
Will Dazey