I have the following situation when migrating and compiling in native mode a quarkus service from version 2.5 to 2.6 and it is the following:
We have a JAR which contains the definition of traversal objects used by several services, within these are the validation messages used in the javax.validation.constraints annotations defined in a file called ValidationMessages.properties
Until version 2.5 I could include this jar as part of the service dependencies, it performed the native compilation of the service and managed to load these messages through the context without any additional configuration.
Now when migrating to version 2.6 it is not able to locate the default file but always looks for one depending on the region of the system:
The specific message is the following:
java.util.MissingResourceException: Can't find bundle for base name ValidationMessages, locale es_MX
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2055)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1689)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1593)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:1284)```
After upgrading to quarkus version 2.7.3 I no longer have this issue.
Related
I'm trying to set a custom log Handler in my Spring Boot (version 2.6.3) application. The result is a ClassNotFound as described in this other question
Can't override java.util.logging.LogManager in a Spring Boot web application: Getting java.lang.ClassNotFoundException on already loaded class
Based on the answer to that question, it seems I need my Handler and all its dependencies to be placed into the root of the executable jar.
Is there a direct way to accomplish this during the Maven build, i.e. not by extracting and repackaging the jar myself post-build?
This issue is a result of BOOT-INF fat jar structure introduced by Spring Boot 1.4.
There is currently no straightforward solution, and it appears some of the Spring Boot maintainers do not agree there is a problem, so it could be a long time before the situation changes:
Issue #6626: Make it easier to package certain content in the root of a fat jar
Issue #12659: Starting executable war with -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager produces a ClassNotFoundException
WORKAROUND #1
I had to do two things to get my application working again with a custom log handler. 1) use Maven Shade to package up the log handler with all its dependencies, and 2) launch the app with using the PropertiesLauncher class in the command line instead of using java -jar:
java -cp executable.jar:logger-shaded.jar -Dloader.main=mypackage.myapp org.springframework.boot.loader.PropertiesLauncher
The executable.jar, logger-shaded.jar, and mypackage.myapp are placeholders specific to my project, so adjust accordingly.
WORKAROUND #2
If the handler is loaded from code in a config class or from main() instead of being specified in the file loaded via java.util.logging.config.file, as discussed in the comments to the answer in this other question, then everything works as expected. I actually prefer this over Workaround #1 as it results in a smaller deployment, but it does require writing a few more lines of code.
I encountered big trouble when trying to migration a web application from Java 8 to Java 11.
The web application:
The web application provides SOAP web services (using Spring WS), is written in Java 8 and runs on Tomcat 9. Spring 4.3 is used for database access, OXM, MVC and dependency injection.
To build the web services, multiple XSD files are used to auto-generate the class files and WSDL document for the web service interface using the xjc tool from the JDK.
My goal:
Migrate the application to Java 11, Tomcat 10 and JakartaEE.
What I have done so far:
In the first step, the compiled web application is migrated using Apache migration tool (version 1.0.0) to get it running on Tomcat 10. There is no problem.
Java migration:
The next step is, to migrate the source code from Java 8 to 11.
Java 11 does not longer include the tools and libraries for XML binding, which makes it necessary to include the XML bind library from JakartaEE.
Rebuilding the auto-generated class files from the XSD files with xjc, that comes with the library, creates source code, which imports from jakarta.xml.bind instead of javax.xml.bind. (Which should be the correct package).
Using JakartaEEs library also requires some minor changes in the code (changing imports to use jakarta.xml.bind instead of javax.xml.bind)
That's the point, where the trouble begins...
The IDE shows no errors and the code is compiled with no errors. Running the web application shows me the error, that javax.xml.bind.JAXBException was not found.
Since there is no source file, that refers to javax.xml.bind I assume, that a library is the cause. I found many references to that package in the Spring OXM library. But: In the master branch of that library, that these references are still there.
I tries to run JEE XML bind and JakartaEE XML bind at same time, but then Spring WS complains about multiple object factories of same type in same name space (which is not true by the way. Both object factories are generated by xjc for different name spaces and reside in different packages...)
My questions:
How can one use JakartaEE, when it is not supported by libraries like Spring?
Did I miss something?
Can someone give me some hints how to migrate the code?
Best regards,
Markus
We're using Camel's File component to receive files that are placed into a directory. The URI for this is similar to:
file:///some/directory/inbox?delay=30000&delete=true&include=DSINV.*%5C.OUT&preSort=true&readLock=changed&readLockCheckInterval=5000&readLockMinLength=0
previously we did not have the 'preSort=true' parameter, and files were being received in a random order.
We added this parameter, but we are now getting the following error in the logs:
There are 1 parameters that couldn't be set on the endpoint.
Check the uri if the parameters are spelt correctly and that they are properties of the endpoint.
Unknown parameters=[\{preSort=true}]
The version of Camel we are using is 2.15.4. The documentation for the 2.x version of the File component states that this is a valid parameter.
This has been added in 2.21.0
https://camel.apache.org/releases/release-2.21.0/
See the related jira here
https://issues.apache.org/jira/browse/CAMEL-11656
So it is not available in 2.15.4 you have to at least update to 2.21.0 in order to work.
I don't know about the latest but is seems even the most resent Camel versions still support java 8
https://camel.apache.org/manual/latest/index.html#_jdk_requirements
Camel 2.x supports JDK 8
Camel 3.0 - 3.4 supports JDK 8 and 11
I get this error message
Error starting application: Error creating query engine Drools. Exception: java.lang.NoSuchMethodError. Message: 'void org.semanticweb.owlapi.util.PriorityCollection.add(java.io.Serializable)'
I am using SWRL API for Java to run SQWRL queries on OWL ontologies. So, I built edu.stanford.swrl swrlapi-example from Maven updating in the pom file the default swrl API and swrlapi-drools-engine from versions 1.0.3 to 2.0.9 and the owl API from default 4.2.3 to 5.1.17. I am runnig this code in the executable main :
OWLOntologyManager ontologyManager = OWLManager.createOWLOntologyManager();
File file = new File("C:\\Users\\Hugo\\Desktop\\Universidad\\SUPAERO\\S4\\SWRLapiTEST\\Prueba.owl");
OWLOntology ontology = ontologyManager.loadOntologyFromOntologyDocument(file);
ontologyManager.createOntology();
SQWRLQueryEngine queryEngine = SWRLAPIFactory.createSQWRLQueryEngine(ontology);
The program stops at the last command. I don't know what I am doing wrong. If I use the version 1.0.3 of swrl api and swrlapi-drools-engine it works, bu I wanted to use some commands incuded in the tbox and abox libraries that are not implemented in that ancient version.
The exception you're seeing is a symptom of multiple incompatible OWLAPI versions in your classpath. Make sure you only have one version in use (5.1.17 from what you say). If you cannot find the problem, please add details on how you're setting your classpath (you can print the java.class.path environment variable at the beginning of your code to get the exact classpath being used).
I am trying to deploy EAR file on Websphere Application Server but while deploying it's showing an error.
ERROR CODE:
SEVERER: Exception org.exolab.castor.xml.ValidationException was not added to the list of sorted types.
The project was not built since its build path is incomplete. Cannot find the class file for org.exolab.castor.xml.ValidationException. Fix the build path then try building this project.
I am using Castor in my project but it's there in classpath which i am setting through Shellscript.
Thanks for help in advance.
Your dependencies need to be expressed to the application server runtime, not added to some shell variable or standalone java invocation. Either package them in your application or create an isolated shared library and associate it with your dependent application.