I am trying to get Jersey to use EclipseLink as its context factory, however, the file jaxb.properties is not being read. The docs say the file needs to be in the folder with the domain classes being mapped and I have verified that. I'm certain it is not being read because I have fubar'd the class name
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactoryXXX
No need to use jaxb.properties. Add a dependency to "jersey-media-moxy" using Maven. Jersey will automatically pick up MoxyXmlFeature (contained in the JAR) and then configure and use MoxyContextResolver to build new JAXB instances.
You may need to add an exclusion to the jersey-media-moxy dependency to avoid pulling in an unwanted version of the org.eclipse.persistence.moxy artifact.
Related
I’m trying to use JAXB 2.2.11 in an osgi environment (Liferay DXP). I am having issues creating a JAXBContext. Based on some other sources found while researching like this and this, I have determined that in an osgi container I need to provide the correct classloader for JAXB to instantiate the context. So I have code like this:
ClassLoader cl package.with.jaxb.objects.ObjectFactory.class.getClassLoader();
JAXBContext jc = JAXBContext.newInstance("package.with.jaxb.objects ", cl);
This code causes a null pointer exception with the following stack trace:
Caused by: java.lang.NullPointerException
at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:129)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:201)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:146)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:371)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:446)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:409)
Looking at the source for ContextFinder I can see that context must be null on line 129:
throw handleClassCastException(context.getClass(), JAXBContext.class);
I thought perhaps the problem was that my module has a dependency on jaxb-api 2.2.11 but the jaxb-impl classes are provided by rt.jar at runtime and are probably newer than 2.2.11 because Liferay DXP runs on JDK 1.8. To get around this issue, I have tried including jaxb-impl.jar 2.2.11 as a dependency in my osgi module, thinking then the jaxb-api & jaxb-impl versions would match. After that, trying to create a JAXBContent using the same code as above results in the following error:
ClassCastException: attempting to cast jar:file:/C:/Program%20Files/Java/jdk1.8.0_144/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class to bundleresource://623.fwk616113009:13/javax/xml/bind/JAXBContext.class. Please make sure that you are specifying the proper ClassLoader.
By the looks of this message, the JAXBContext that is getting instantiated is from the version of JAXBContext that is loaded via rt.jar. This is very confusing to me because I would expect the version of JAXBContext loaded by my module’s classloader to be used since I’ve included jaxb-impl.jar in my module and I’ve specified my module’s classloader is the one to be used in my call to JAXBContext.newInstance. Can anyone shed some light on how I can get jaxb 2.2.11 to work in an osgi container?
*Please note that I can’t upgrade the version of jaxb-api used by my module because the JAXB code is actually in a 3rd party jar that requires jaxb 2.2.11 (I have just eliminated the 3rd party jar from the equation for now by writing some test JAXB code).
After extensive research I found the following solution. Since it seemed like passing the bundle class loader as suggested by the accepted answer in this post had to be correct, I followed the path of figuring out why I was getting a NullPointerException when I tried that. After carefully looking over the source code for jaxb-api to follow the stack trace of the NullPointerException, I could see that the jaxb-api code does things like
classLoader.loadClass("com.sun.xml.internal.bind.v2.ContextFactory")
where classLoader is my bundle's class loader (since that's what I passed in) and ContextFactory is actually a class in jaxb-impl which is loaded by the bootstrap class loader. This is where the problem lies because my
bundle's classloader isn't going to be able to see classes loaded by the bootstrap class loader. This threw me for a while because I'm not used to how class loaders work in osgi. I incorrectly was thinking the classes loaded by the bootstrap class loader would be visible because I'm used to web app class loading where there is delegation. In osgi class loaders
are completely isolated from each other, things are only visible if they are exported. To get around the issue I found some helpful posts talking about similiar issues. It turns out there is a concept
called boot delegation in osgi where you can specify a list of classes/packages to always be loaded via the bootstrap classloader. So the end result is two steps:
1) Switch the thread's class loader to your bundle class loader before calling the code to get the JAXBContext:
ClassLoader currentClassLoader = Thread.currentThread().getContextClassLoader();
try {
// ObjectFactory here is in the same package as my classes to be marshalled
ClassLoader objectFactoryClassLoader = ObjectFactory.class.getClassLoader();
Thread.currentThread().setContextClassLoader(objectFactoryClassLoader);
// JAXB code goes here
} finally {
Thread.currentThread().setContextClassLoader(currentClassLoader);
}
2) Specify packages to be loaded using the boot delegation mechanism. This list needs to include the transitive dependencies of the classes you need loaded. In my case, I'm using Liferay so the list
is specific to Liferay and it goes in portal-ext.properties configuration file. Luckily I found this post where someone had done most of the work for me:
module.framework.properties.org.osgi.framework.bootdelegation=\
__redirected,\
com.liferay.aspectj,\
com.liferay.aspectj.*,\
com.liferay.portal.servlet.delegate,\
com.liferay.portal.servlet.delegate*,\
com.sun.ccpp,\
com.sun.ccpp.*,\
com.sun.crypto.*,\
com.sun.image.*,\
com.sun.jmx.*,\
com.sun.jna,\
com.sun.jndi.*,\
com.sun.mail.*,\
com.sun.management.*,\
com.sun.media.*,\
com.sun.msv.*,\
com.sun.org.*,\
com.sun.syndication,\
com.sun.tools.*,\
com.sun.xml.*,\
com.yourkit.*,\
org.eclipse.persistence.internal.jaxb,\
org.eclipse.persistence.internal.jaxb.*,\
javax.xml.*,\
sun.*
Helpful links:
Why can't JAXB find my jaxb.index when running inside Apache Felix?
What is the difference between bootdelegation and DynamicImport-Package in osgi
https://web.liferay.com/web/user.26526/blog/-/blogs/liferay-dxp-and-weblogic-
https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/bundle-classloading-flow
http://apache-felix.18485.x6.nabble.com/Classloading-for-JAXB-td4834670.html
Here is the workaround that worked for me using JDK 11, Liferay DXP/7.2, OSGI, with a sample Jax-RS web service created from Dev Studio. The error I was getting was as follows when trying to access the web service:
JAXBException occurred : Implementation of JAXB-API has not been found
on module path or classpath..
com.sun.xml.internal.bind.v2.ContextFactory cannot be found by
org.apache.aries.jax.rs.whiteboard_1.0.4.
What worked for me was to define the context factory at the system level to override the predefined context factory. Add the following system variable to your system
javax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
For example you can add this in your setenv.sh/bat file in Tomcat, or in eclipse you can access your server Launch Configuration, Arguments tab, under VM arguments
-Djavax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
This worked without adding any extra libraries since Liferay already has those libraries included.
How does this work? Refer to the javadoc for JaxBContext and read the Discovery of JAXB implementation Section. Using the /META-INF/services/javax.xml.bind.JAXBContext file did not work for me.
I hope this helps someone.
One final note for DXP users, if you get a permission denied on your service then you need to read about Service Access Policies
The best place to see how it should be done is Apache Karaf. It doesn't install any JAXB-API bundle - instead it uses org.apache.servicemix.specs.jaxb-api-2.2-2.7.0.jar inside lib/endorsed directory.
This way you won't use JAXB-API provided by rt.jar.
For implementation - it's best to use ServiceMix version of JAXB bundles:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-impl:2.2.11_1
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-xjc:2.2.11_1
I like to prototype a JEE environment with Wildfly 10.1 and Hazelcast 3.8. Until now I only have experience with ancient JBoss 4.2.3.GA.
I already found existing resource adapter implementation based on older hazelcast 3.6 under https://github.com/hazelcast/hazelcast-ra. Unfortunately I couldn't deploy it as-is on Wildfly 10.1 since IronJacamar complained about missing equals/hashCode methods (which isn't true since they are explictly overwritten in the source code. deploying a self-built snapshot of git master had the same issue).
I ended up with migrating the ra.xml configuration code to proper javax.resource.spi annotations (#Connector, #ConfigProperty, #ConnectionDefinition) and adding javax.resource.Referenceable interface implementation (don't know whether this is necessary). The step to hazelcast 3.8 was much easier - just adding missing interface methods to HazelcastConnectionImpl.
I still struggle with deployment/configuration, so here are my questions:
How should the deployment structure for an JCA adapter look like? I tested the following approaches:
All-in-one: RAR file containing all of cache-api-1.0.0.jar, hazelcast-3.8.jar, hazelcast-client-3.8.jar, my-hazelcast-ra-impl.jar and deployment descriptors.
By-Library: Added new modules javax.cache.api (cache-api-1.0.0.jar) and com.hazelcast.hazelcast (hazelcast-3.8.jar, hazelcast-client-3.8.jar) to ${WILDFLY_HOME}/modules/ and declared appropriate module dependencies in jboss-deployment-structure.xml. RAR file contains my-hazelcast-ra-impl.jar, hazelcast.xml and deployment descriptors.
By-Adapter: Added a new module my.hazelcast.ra (cache-api-1.0.0.jar, my-hazelcast-ra-impl.jar) to ${WILDFLY_HOME}/modules/ and declared appropriate module dependency in jboss-deployment-structure.xml. RAR file contains hazelcast-3.8.jar, hazelcast-client-3.8.jar, hazelcast.xml and deployment descriptors.
Where is the proper place to deploy a hazelcast.xml configuration file into Wildfly 10.1? It seems that I need to pack it next to ResourceAdapterImpl class (my-hazelcast-ra-impl.jar) so that the class loader finds it and prefers it over hazelcast-default.xml. It contains only global configuration options like group/network. No cache definitions since caches should be configured/created on-demand via CDI.
Is there something like a conf folder where I can deploy hazelcast.xml file separate from binary RAR contents? It would be nice if it could be hot-deployed (for prototyping) but that is not mandatory.
Should it be placed somehow inside subsystem configurations within standalone.xml? I found similar cache-container configurations for infinispan subsystem but don't know how to adapt this to hazelcast (since it's not an own subsystem).
In Wildfly Management webinterface I can find the deployed RAR under Depoyments and in the JNDI view, but it is not listed under Configuration -> Subsystems -> Resource Adapters. I can create a new entry there but don't find any advantage. What is the meaning of this configuration option?
Thank you in advance
Because of some reason, I want to use my current java entity classes to generate all entity related files, which are generated with yo jhipster:entity book. I need the liqibase configuration files, repository files, rest resources, and the sample files of html and js files.
So is there any way I can do that?
I don't think there's a way to do that at the moment. But with JHipster 2 you could manually create a .jhipster/{entityname}.json file based on your class, and that would generate those files (and also recreate the class object) you're looking for.
it's been a while now and still there are several things that are not clear to me.
Lets start with the basics: what I need to do.
I'm building a web application that manipulate some data, do some computation and give the user an output. There will be also a standalone version, with some simplifications.
So I thought this is the right time to use EAR packaging structure and EJB. I've created with netbeans a basic j2ee ear project with maven support:
All of them have their own pom.xml.
For what i understand, the first one is just a wrapper, the second one is the "real" project that doesn't contain source code, but encapsulate the other two.
In the web project I put all of the web stuff plus jsf backing beans. In the ejb one I was planning to put my data model with all the required annotations, and that comprehend also JPA and JAXB. There should be also some additional classes: a facade class, or session bean, that allow me basic data manipulation with the database, and some classes that contain my business logic strictly related to my data.
Question: is it correct to put all this things into an EJB project? Why not a simple project that the web module depends on?
Moving forward: the web project. First things is, netbeans doesn't put the EJB project dependency into its pom. So I can't see my beans from here. Is that correct or I have to manually add the SRA-ejb into the pom as a dependency?
Secondly, using some netbeans macro, like the ones that generate session beans from entity, or CRUD jsf pages from entities, it looks like he try to generate and put session beans here, in the web project. I think they fits better in the ejb one. What do you think?
One last question: in my stand alone application I was planning to use just the ejb module. But I think I have to carry with me an EJB container, am I right?
it's been a while now and still there are several things that are not
clear to me.
I know that feeling for sure :D
All of them have their own pom.xml. For what i understand, the first
one is just a wrapper, the second one is the "real" project that
doesn't contain source code, but encapsulate the other two.
Correct, it doesn't contain any sourcecode but can contain XML files for declarations and a common lib folder which contains shared libraries of the web and EJB projects.
In the web project I put all of the web stuff plus jsf backing beans.
In the ejb one I was planning to put my data model with all the
required annotations, and that comprehend also JPA and JAXB. There
should be also some additional classes: a facade class, or session
bean, that allow me basic data manipulation with the database, and
some classes that contain my business logic strictly related to my
data.
Question: is it correct to put all this things into an EJB project?
Why not a simple project that the web module depends on?
I don't know what you mean with a "simple project", if you mean just a plain JAR file with classes: an EJB module is nearly the same plus a deployment descriptor which invokes scanning of the annotations.
Moving forward: the web project. First things is, netbeans doesn't put
the EJB project dependency into its pom. So I can't see my beans from
here. Is that correct or I have to manually add the SRA-ejb into the
pom as a dependency?
Yes, in your case you need this dependency. You web project depends on your "service".
Secondly, using some netbeans macro, like the ones that generate
session beans from entity, or CRUD jsf pages from entities, it looks
like he try to generate and put session beans here, in the web
project. I think they fits better in the ejb one. What do you think?
I think it makes more sense to put them in the EJB project because they come from the javax.ejb.* package and belong to the EJB layer. You can put them in the we project, but then you don't really need an EAR and you can use a normal web project like you did before.
One last question: in my stand alone application I was planning to use
just the ejb module. But I think I have to carry with me an EJB
container, am I right?
No, you don't need an EJB container. You can lookup your EJBs via JNDI but you'll need an EJB with a remote interface and a copy of this interface in your standalone client.
You can find some tutorials about that here:
EJB invocations from a remote client using JNDI (JBoss)
How do I access a Remote EJB component from a stand-alone java client? (GlassFish)
GlassFish Project - Simple EJB 3.0 Stateless Session Bean Example
See also:
Maven2: Best practice for Enterprise Project (EAR file)
EAR package structure
Maven structure and Java EE applications
I'm developing a Liferay application, consisting on 2 different portlets, an both have to make certain operations in common, so I decided to put that operations in static methods in an external Utils class.
I have to externalize that class to avoid duplicating the same code in both portlets, and I want to have the portlets in different WAR files.
I know I can package the Utils class in a JAR file, but we are still developing and we don't want to regenerate the JAR and restart the Tomcat for every change.
Which is the best option and how can I perform it?
If you're using the Liferay SDK, you can use the clients (recently changed to shared) directory to put your common code.
A good example is how deploy-listener-shared is used in conjunction with deploy-listener-hook.
From what it looks like, all the configuration you need to do is to modify your build.xml files that will use the client\shared classes. If you look at build file of deploy-listener-hook you can see all you need to add is the.
For the new SDK:
<property name="import.shared" value="my-utils-shared" />
For the older SDK:
<property name="dependent.clients" value="my-utils-client" />
Hope this helps!
There is another method that involves building a JAR file but it doesn't require a server restart (on Tomcat at least).
Write a build script for your JAR file so it compiles, builds the JAR and finally copies it to the following location:
{tomcat}/webapps/ROOT/WEB-INF/lib
Then in your portlet open the "liferay-plugin-package.properties" (in Liferay Developer Studio / Liferay IDE this should open with a nice GUI).
Then add the name of your JAR to the "portal-dependency-jars" list in this file so in the source it would like (Or just hit the "Add" button in the GUI and select the JARs you want):
portal-dependency-jars=my-custom-lib.jar,my-other-custom-lib.jar
Save the file, and redeploy the portlet, and the JAR will be copied across when the portlet is deployed.
I've used this method for custom JARs, and 3rd party JARs that I've needed to use in my portlets.
For the development phase just package the jar file with both applications.
Unless one application depends on the other somehow it is completely ok.
Another solution is to use JRebel tool. It will allow you to redeploy jar in tomcat without restarting.
Also you may have several portlets in one .war. You may just define them both in portlet.xml.