When packaging our app with mvn package everything works fine. Then when we start our app with java -jar target\quarkus-app\quarkus-run.jar the app silently crashes. While debugging we found that it crashes while parsing an xml InputStream. It happens while initialising some classes.
This is the stacktrace that we had to dig out ourselves:
Exception occurred in target VM: Provider for javax.xml.parsers.DocumentBuilderFactory cannot be found
javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.DocumentBuilderFactory cannot be found
at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
at org.optaplanner.core.impl.io.jaxb.GenericJaxbIO.parseXml(GenericJaxbIO.java:209)
at org.optaplanner.core.impl.io.jaxb.SolverConfigIO.read(SolverConfigIO.java:15)
at org.optaplanner.core.config.solver.SolverConfig.createFromXmlReader(SolverConfig.java:199)
at org.optaplanner.core.config.solver.SolverConfig.createFromXmlInputStream(SolverConfig.java:173)
at org.optaplanner.core.config.solver.SolverConfig.createFromXmlInputStream(SolverConfig.java:160)
When packaging the app in an uberjar this problem does not occur. Same when using dev.
We use graalvm-ce-java17-22.2.0, together with the 2.11.2.Final version of quarkus and the 8.29.0.Final version of optaplanner.
We tried to verify that there aren't any xml exclusion in the dependencies. Also we checked if quarkus and the quarkus maven-compiler-plugin are of the same version. Also we looked into the compiled jarfiles, if the xml we want to read is present. If it wouldn't be present, the code would crash even earlier. The class javax.xml.parsers.DocumentBuilderFactory is not listed in the quarkus-app-dependencies.txt
Adding the quarkus-optaplanner extension helped to identify the logger issue. So the problem with the silent crash is resolved. Adding quarkus-jaxp to the dependencies gets rid of the FactoryConfigurationError and everything works as expected.
Related
I try to migrate an eclipse plugin from Java8 to Java9. If I start a debug session (Run as Eclipse Application...) all works fine.
However, after installing my plugin I am not able to use it. If I use ss in the OSGI console I get following status for my plugin:
1102 STARTING org.treez.core_1.0.0.201712191435
and if I manually try to start it I get
osgi> start 1102
gogo: BundleException: Error loading bundle activator.
I tried to start a remote debug session, as suggested here:
Debugging Eclipse plug-ins
I set a break point in the constructor of my Activator but that break point is never reached.
=> How can I get additional information about why the loading of the bundle activator fails? Is there some log file? Can I somewhere set a logging level to TRACE?
I assume that the issue might be that a resource can be found while debugging the Eclipse Application but not when using the bundled jar. More info, e.g. the name of the resource that could not be found, would be very helpful.
Related questions:
Debugging Eclipse plug-ins
CQ5 OSGi bundle does not start:- Activator cannot be found
When plugins fail to start there is normally a message in the .log file in the workspace .metadata directory.
On Linux, Unix and macOS this file and directory are hidden so you may need to do something special to see them.
I'm working on a springboot 1.5.1 application that I'm trying to load a WSDL included in my resources directory in the wsdl directory. Depending on where my application executes I'm getting different results (command line, intellij, cloud foundry) and I can't seem to get all three to work at the same time.
I've tried several ways of locating the resource:
From prior to the migration to springboot we had this (worked in IntelliJ but not java -jar myboot.jar):
this.getClass().getResource("/wsdl/my.wsdl");
I switched it to the typically more correct version and got it to work in IntelliJ and java -jar but not Cloud Foundry:
this.getClass().getClassLoader().getResource("/wsdl/my.wsdl");
I switched it to use the Spring Resource Loader version and it worked in IntelliJ and CloudFoundry but not java -jar:
#Value("classpath:/wsdl/my.wsdl")
private Resource wsdlResource;
wsdlResource.getURL();
On the command line what I've noticed is that it seems to be thinking that BOOT-INF/classes is a JAR file (Note the ! after classes):
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: jar:file:/C:/dev/redacted/build/libs/redacted.jar!/BOOT-INF/classes!/wsdl/my.wsdl. It failed with:
JAR entry BOOT-INF/classes!/wsdl/my.wsdl not found in C:\dev\redacted\build\libs\redacted.jar.
From looking at IntelliJ's URL, it's referring to the actual source folder which explains why it seems to always work.
What is causing this and how might I universally load these class path resources successfully with springboot?
A question has already been posted here at Spring-boot jersey maven failed to run war file and its author has found a work around to get the Spring-boot app to run, but it's still an annoying bug.
Basically, when running a Spring-boot app with a Jersey configuration using ResourceConfig's public final ResourceConfig packages(final String... packages) with java -jar command or using Unix style ./app.jar start the following exception occurs:
java.io.FileNotFoundException:/path/app-1.0-SNAPSHOT.war!/WEB-INF/classes (No such file or directory)
Caused by: org.glassfish.jersey.server.internal.scanning.ResourceFinderException:
This does not occur when the app is ran with mvn spring-boor:run.
Not using packages("com.company.app.rest") is a work around, but it's a pain not to be able to have Jersey scan a base package.
Is this listed as a bug by the Spring-boot team?
I think it is but for some reason nobody complained hard enough. Can you please share your issue on #3413?
Following instructions at http://wiki.hl7.org/index.php?title=FHIR_Build_Process my FHIR build is failing. I modified the publish.bat to ensure it uses the correct JDK. Running it on Windows 7 64-bit machine with JDK 1.6 (also tried JDK 1.7) and both failing with same error.
Looks like some Saxon JAR hell somewhere. Any ideas?
...validate v2-tables 441sec 755MB
...validate v3-codesystems 443sec 889MB
Reference Platform Validation. 447sec 1067MB
...test adversereaction-example 447sec 1067MB
Exception in thread "main" java.lang.NoSuchMethodError: net.sf.saxon.Configuration.newConfiguration()Lnet/sf/saxon/Configuration
;
at net.sf.saxon.xpath.XPathFactoryImpl.<init>(XPathFactoryImpl.java:33)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.xml.xpath.XPathFactoryFinder.loadFromService(XPathFactoryFinder.java:401)
at javax.xml.xpath.XPathFactoryFinder._newFactory(XPathFactoryFinder.java:222)
at javax.xml.xpath.XPathFactoryFinder.newFactory(XPathFactoryFinder.java:143)
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:185)
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:99)
at org.hl7.fhir.tools.publisher.Publisher.testSearchParameters(Publisher.java:2796)
at org.hl7.fhir.tools.publisher.Publisher.testSearchParameters(Publisher.java:2785)
at org.hl7.fhir.tools.publisher.Publisher.validateRoundTrip(Publisher.java:2759)
at org.hl7.fhir.tools.publisher.Publisher.validateXml(Publisher.java:2656)
at org.hl7.fhir.tools.publisher.Publisher.execute(Publisher.java:378)
at org.hl7.fhir.tools.publisher.Publisher.main(Publisher.java:281)
A workaround... do a fresh build of the publisher tool jar from source.
Following instructions in the build/buildhowto.txt I was able to build the tool jar inside Eclipse, run the Publisher successfully from inside Eclipse and then export it as a fresh tool jar overwriting the one I pulled from SVN. The freshly build one then ran to completion from the command line.
Could be there's just a problem with the version of tools jar out there in SVN at the moment.
For the record I am working with Version 0.12-1953.
You have two classes net.sf.saxon.Configuration in your classpath. One containing the method newConfiguration() and one not.
The method is probably called from Saxon-HE 9.x, and the class net.sf.saxon.Configuration is found in saxon 8.x, while the class should have been found inside Saxon-HE 9.x, where it also is, and does have this method.
So, check your dependencies to see if saxon 8.x is called, and try replacing that with Saxon-HE 9.x, then your problem is solved
I am getting weird errors on Heroku cedar using hibernate-memcached 1.3:
Caught CNFE decoding 438 bytes of data java.lang.ClassNotFoundException: org.hibernate.cache.entry.CacheEntry
Somehow hibernate-memcached 1.3 is failing to work with spymemcached 2.8.1 and up.
It does not matter if i explicitly list spymemcached 2.7.3 in my pom.xml or i set spymemcached scope as provided - i always get CNFE
I was able to replicate this issue locally when i upgraded to spymemcached 2.8.1
Thanks.
If you are using webapp-runner.jar to run your app, then yes, you're right: spymemcached class files are contained in the jar file to support caching of session data.
According to webapp-runner this is true for version 7.0.29.1 or newer.
The most recent version that does not contain spymemcached classes I was able to find, though, is 7.0.22.1.
I suspect that you can work around your problem by downgrading webapp-runner to version 7.0.22.1.
At least that worked for me when I ran into similar problems, getting exceptions like this:
org.springframework.beans.factory.CannotLoadBeanClassException:
Error loading class [net.spy.memcached.spring.MemcachedClientFactoryBean]
for bean with name 'memcachedClient' defined in class path resource [memcached-context.xml]:
problem with class file or dependent class;
nested exception is java.lang.NoClassDefFoundError: org/springframework/beans/factory/FactoryBean
These problems only occurred when I ran my war file with webapp-runner.jar. Running it from within Eclipse or with a local plain vanilla Tomcat 7 worked just fine.