I'm trying to provide internationalization to SAXParseException messages in Java 11.
I found few solutions e.g. link that worked before introduction of JPMS in Java 9. Now (j11) those new bundles e.g. XMLSchemaMessages_pl.properties are not visible (loaded but skipped by ResourceBundle as they are not in java.xml module).
How can I provide internationalization to SAXParser in Java 11?
Related
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
Hibernate 5 and above supports Java8 DateTime Api through jar "hibernate-java8".But the MavenRepository shows a message Deprecated - use hibernate-core instead) alongside the title of the hibernate-java8 jar.Why is the hibernate-java8 jar called deprecated even though it is required to gain the hibernate support for java8?
You can see the Migration Guide for Hibernate. It specifies that
Hibernate 5.2 is built using Java 8 JDK and will require Java 8 JRE at
runtime (we are investigating whether Java 9 will also work). This has
a number of implications:
The hibernate-java8 module has been merged into hibernate-core and the
Java 8 date/time types are now natively supported.
(todo) support for Java 8 Optional
(todo) support for other Java 8 features?
The hibernate-java8 module has been removed; that functionality has been consolidated into hibernate-core.
For hibernate-java8 see this ticket for explanation,
As this relies on Java 8 and Hibernate still maintains compatibility
back to Java 6, a new module hibernate-java8 was added to isolate the
Java 8 compatibility to just these classes. We will fold the classes
from this module into hibernate-core once we baseline one Java 8.
Since hibernate no longer maintains the hibernate-java8 and you can see that hibernate-java8 is nothing more than an empty placeholder. Github & JIRA Detail.
So, As the functionality has been merged into hibernate-core; hibernate-java8 now is depreciated.
I hope this answer your queries.
When compiled with java 7u79, spring 3.1 app is all good. When compiled on java 7u80, we're encountering some injection issues.
Searching a solution i found that Spring 3 is not compatible with java8, as explained here (due to asm).
We can see here that javac modifications were backported to java 7u80 and java 7u85.
So, am I rigth to think that it's same compatibility problem than for java 8, and that spring 3 app will not work if compiled on java7u80 ?
Sharing my experience - yes, some spring versions have problems with java 8. For example in my project we've had to change spring from 3.2.4 to 3.2.9 to use java 8. I won't put here any particular example because I don't have one but I would advice you to give spring 3.2.9 a chance. We're using it successfully with Java 8.
I saw from the Spring IO Platform website (http://spring.io/blog/2014/06/26/introducing-the-spring-io-platform) and it states that Spring IO is certified to work with Java 1.7 and 1.8.
However, the production stack of my company is Java 1.6 only so may I know that does Spring IO Platform BOM support Java 1.6 as well?
We intensive use Spring, Spring Data, Spring Batch, Spring Integration, Spring Retry.
thanks in advance
No, Java 6 isn't supported by Spring IO Platform. That said, I'm not aware of anything in the projects that you have listed that require Java 7 so it may well work but it isn't something that we (Pivotal) have tested or support.
Is it possible to use classes that are in a websphere application server shared library from within an OSGi bundle?
I did some research and found this http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_v8/was/8.5/ProgrammingModel/WAS85_LP_Class_Loading.pdf which indicates that it ispossible to load OSGi classes from standard java, however, there is no indication whether the opposite is possible. Any help would be appreciated!
No, it is not possible to use a Java EE shared library from an OSGi application, but you can use a bundle repository to share binaries across OSGi applications.
The document you linked is primarily discussing Java EE applications in the Liberty Profile runtime:
The class loader configuration is only valid for Java EE applications.
If it is provided for an OSGi application, it is ignored.
...
Since OSGi allows applications to specify the versions of packages to
be imported, once again this coarser level of control is only needed
for Java EE applications.
Any mention of OSGi class loading is pointing out that Java EE applications have visibility to product classes that are loaded by an OSGi runtime. There is a brief mention of bundle repositories for OSGi applications:
Note that this library definition is for use by Java EE applications.
There is a separate facility known as the bundle repository for
configuring additional bundles to be used by OSGi applications.