We Keep Coding

DependencyException: Failed to find provider with satisfied dependency set for interface org.ehcache.core.spi.store.Store

I have an app that uses EHCache, it worked when using Payara Application server version 1.0.5 but after upgrading to 1.1.0 it started breaking.
Here's a snippet of the code:
persistentEntityStoreCacheManager
= CacheManagerBuilder.newCacheManagerBuilder().withCache("defaultPersistentEntityStoreCache",
CacheConfigurationBuilder.newCacheConfigurationBuilder(String.class, PersistentEntityStore.class, ResourcePoolsBuilder.heap(100)).build()).build(true);
And it is throwing this error:
java.lang.IllegalStateException: org.ehcache.core.spi.ServiceLocator$DependencyException: Failed to find provider with satisfied dependency set for interface org.ehcache.core.spi.store.Store$Provider [ca
ndidates []]
at org.ehcache.core.spi.ServiceLocator$DependencySet.build(ServiceLocator.java:350)
at org.ehcache.core.EhcacheManager.resolveServices(EhcacheManager.java:154)
at org.ehcache.core.EhcacheManager.<init>(EhcacheManager.java:125)
at org.ehcache.core.EhcacheManager.<init>(EhcacheManager.java:115)
at org.ehcache.core.EhcacheManager.<init>(EhcacheManager.java:111)
at org.ehcache.config.builders.CacheManagerBuilder.newCacheManager(CacheManagerBuilder.java:117)
at org.ehcache.config.builders.CacheManagerBuilder.build(CacheManagerBuilder.java:73)
What's this EHCache and and what could be missing here?

In my case, there are multiple EhCache imported by different modules.After useing the same version of EhCache. The problem solved.

J2EE Mybatis webapp on Java 8 - java.lang.RuntimeException: XPathFactory#newInstance

Our J2EE/Spring/Mybatis web application has been running fine for some time on Java 7 (on Centos), but recently we tried updating our JVM to Java 8, and now we get the following stack-trace on start up:
java.lang.RuntimeException: XPathFactory#newInstance()
failed to create an XPathFactory for the default object model:
http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException:
java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory:jar:file:/usr/local/tomcats
/test/webapps/tms/WEB-INF/lib/saxon-xpath-8.7.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102)
at org.apache.ibatis.parsing.XPathParser.commonConstructor(XPathParser.java:261)
at org.apache.ibatis.parsing.XPathParser.<init>(XPathParser.java:121)
at org.apache.ibatis.builder.xml.XMLMapperBuilder.<init>(XMLMapperBuilder.java:75)
at org.apache.ibatis.builder.xml.XMLMapperBuilder.<init>(XMLMapperBuilder.java:70)
at org.apache.ibatis.builder.annotation.MapperAnnotationBuilder.loadXmlResource(MapperAnnotationBuilder.java:158)
at org.apache.ibatis.builder.annotation.MapperAnnotationBuilder.parse(MapperAnnotationBuilder.java:113)
at org.apache.ibatis.binding.MapperRegistry.addMapper(MapperRegistry.java:66)
at org.apache.ibatis.session.Configuration.addMapper(Configuration.java:651)
at org.mybatis.spring.mapper.MapperFactoryBean.checkDaoConfig(MapperFactoryBean.java:97)
our Saxon9.jar version = 9.1.0.8 (latest).
There are many different jars/dependencies involved in parsing xml/xslt in our application, and I don't want to try guessing what changes to make by trial and error. Does anyone know what could be causing this, or where to look first?

This problem is described here.
If you want to use Saxon with Java 8 you need to upgrade Saxon to a version >= 9.5.1.5

Oracle JDK Update 5 (1.7.0_05) not working on SUSE Linux Enterprise Server 11. EOFException while connecting to Javaspace Blackboard (JINI)

We are trying to run a process (broker) from a SUSE Linux Enterprise Server 11 (java-1_7_0-ibm) which connects to a Javaspace Blackboard (JINI) deployed on another linux machine. (CentOs with Open JDK "1.7.0_05-icedtea" version)
Stack Trace :
INFO: Starting broker
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.initialize(J9VMInternals.java:259)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:653)
at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
at com.sun.jini.reggie.$Proxy0.lookup(Unknown Source)
at com.sun.jini.reggie.RegistrarProxy.lookup(RegistrarProxy.java:128)
at edu.vt.ndssl.blackboard.JiniSpaceService.findSpace(JiniSpaceService.java:372)
at edu.vt.ndssl.blackboard.JiniSpaceService.<init>(JiniSpaceService.java:74)
at edu.vt.ndssl.blackboard.JavaSpaceBlackboard.<init>(JavaSpaceBlackboard.java:31)
at edu.vt.ndssl.blackboard.BlackboardFactory.make(BlackboardFactory.java:28)
at edu.vt.ndssl.broker.Broker.<init>(Broker.java:53)
at edu.vt.ndssl.broker.Broker.main(Broker.java:231)
Caused by: java.lang.RuntimeException: Unexpected exception
at com.sun.jini.logging.Levels.createLevel(Levels.java:142)
at com.sun.jini.logging.Levels.<clinit>(Levels.java:52)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:237)
... 10 more
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1387)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2059)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1984)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1867)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1419)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:420)
at com.sun.jini.logging.Levels.createLevel(Levels.java:138)
... 13 more
Same code works fine with Java 1.6 version upto 26.
I am looking for a correct version of Java to be installed on the SUSE Linux Enterprise Server which will be compatible with this OS and also equivalent to the Oracle JDK Update 5 or Open JDK Version 1.7.0_05 (icedtea).

Apparently, the root cause of the problem is that Oracle has made an incompatible change to the serialization format of the com.sun.jini.logging.Levels class. The change reportedly happened in Oracle JDK 1.6.0_38 and JDK 1.7.0_13, and has presumably made it into recent OpenJDK versions as well.
This problem has manifested in a variety of projects that use JINI. Examples:
https://issues.apache.org/jira/browse/RIVER-415 + https://issues.apache.org/jira/browse/RIVER-416.
https://cloudifysource.zendesk.com/entries/23079726-bootstrap-localcloud-not-working-Could-not-initialize-class-com-sun-jini-logging-Levels
More examples can be found by searching for "com.sun.jini.logging.Levels EOFException".
I can't say what the solution is / would be for you, but I have a couple of ideas:
Avoidance: I think you can avoid the problem if you don't mix pre and post-change JVM versions in your application network.
If you need to upgrade your application JVMs, I suggest that you upgrade them all, and then do a complete shutdown/restart of your JINI applications and services.
Fix your applications: It appears that the Apache River project fixed the problem by modifying the JINI code. As the issue ticket says:
The com.sun.jini.logging.Levels class produces a RuntimeException with the latest version of Java (both 1.6 and 1.7). The issue surrounds creation of custom java.util.logging.Level. The current implementation uses a ClassReplacingObjectOutputStream and the LevelData approach. By removing this approach and creating a subclass of java.util.logging.Level the issue gets resolved.
The issue ticket has a lot of discussion on the best way to do this, proposed patches and links to the checkin where they actually implemented the fix.

WAS 8.0(beta version) | unable to parse the MBean descriptor file

Getting this exception unable to find the reason why? Has anybody seen this before? I am running my application in WAS 8.0(beta version).
com.ibm.websphere.management.exception.DescriptorParseException: ADMN0001W: The service is unable to parse the MBean descriptor file
com/ahold/ers/dcr/common/jmx/mbeans/impl\SpringContextMBean.xml. at
com.ibm.ws.management.descriptor.MBeanDescriptorManager.loadDescriptorFile(MBeanDescriptorManager.java:411)
at
com.ibm.ws.management.descriptor.MBeanDescriptorManager.getDescriptor(MBeanDescriptorManager.java:190)
at
com.ibm.ws.management.MBeanFactoryImpl.activateMBean(MBeanFactoryImpl.java:458)
Caused by: java.io.FileNotFoundException: mbeans\AlertHibernateManagerMBean.xml
The forums on the net say i would need to change the JDK and point it to the one provided with WAS 8.0(beta version). Didn't understand this either. I am trying to migrate JavaEE 5 compliant code to WAS 8.0(beta version) (Java EE6). It should happen smoothly i guess as JVM is backward compatible. I hope i wouldn't need to recompile my code with Java EE6 just to make it work with WAS8. Is my understanding correct?

Apache Camel web console's scalate servlet fails in WebLogic

I've found a similar issue described in detail in the scala mailing list (also here). It seems to be related to this change in classpath management when creating scala interpretation environments.
In my case both scala-library and scala-compiler are included in the war being deployed to WebLogic 10.3 (camel version: 2.8.0, jvm: oracle 1.6).
The exception is shown below:
com.sun.jersey.api.container.ContainerException: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeToUsingServletTemplateEngine(ScalateTemplateProcessor.scala:190)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:136)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:44)
at com.sun.jersey.spi.template.ResolvedViewable.writeTo(ResolvedViewable.java:103)
at com.sun.jersey.server.impl.template.ViewableMessageBodyWriter.writeTo(ViewableMessageBodyWriter.java:83)
Truncated. see log file for complete stacktrace
Caused By: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:784)
at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:643)
at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:374)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:368)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:426)
Truncated. see log file for complete stacktrace
Caused By: scala.tools.nsc.MissingRequirementError: object scala not found.
at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:653)
at scala.tools.nsc.symtab.Definitions$definitions$.getModule(Definitions.scala:603)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackage(Definitions.scala:145)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackageClass(Definitions.scala:146)
at scala.tools.nsc.symtab.Definitions$definitions$.AnyClass(Definitions.scala:176)
The question: is it possible to make camel web-console work in this environment?

No its a problem with WebLogic. Scalaete needs to add special support for WebLogic, as WebLogic does classloading a bit differently, than the usual practice.