After re-installed Netbeans 7.4 with a fresh Glassfish 4.0, I got missing and conflicting libraries. I am using Jackson library for working with JSON and I need Jersey (from what I remember) to work with RESTful (client).
If I include the Jersey 2.0 (JAX-RS RI) library in Netbeans I get a conflict with the default JPA persistence library (CascadeType and TypedQuery). But it includes JsonNode and the ObjectMapper classes.
These are the classes that causes my problem;
org.codehaus.jackson.JsonNode;
org.codehaus.jackson.map.ObjectMapper;
I also noticed that I can set the full JEE 7 profile (only web) in the project settings for Netbeans. I think this was available before in prevous versions of Netbeans.
What libraries (version) do I need to include (I don't use Maven) to solve my JSON/RESTful problem?
Glassfish already has JAX-RS libraries, so you don't need to add any JARs to your project except the Glassfish Runtime Libraries.
In Eclipse, check if you configured the Glassfish Runtime Library and if your project is assigned to use it. Also, check if you activated the Project Facet of JAX-RS. All this can be done on Properties menu of the project.
Instead of including the default Jersey 2.0 (JAX-RS RI) library in Netbeans, which causing the conflict with the JPA persistence library. I've downloaded and included these specific libraries to handle the JSON parsing and mapping;
jackson-core-asl-1.9.2
jackson-mapper-asl-1.9.2
I've downloaded the libs from The Central Repository
Related
I'm currently using Eclipse Dali with EclipseLink 2.5.2.
Now I want to change to version EclipseLink 2.7.5, but I'm unable to find out how to setup Dali for new EclipseLink versions.
The JPA project dialog only shows EclipseLink 2.5.2 as a possible choice for the platform:
So I guess, I must download and install a new persistence platform so I'm able to select EclipseLink 2.7.5 from this dialog? Note that I already downloaded the zip archive for EclipseLink 2.7.5 - is it perhaps somehow possible to point Dali to this archive? Or is it necessary to manually remove EclipseLink 2.5.2 from the project's classpath and instead add the corresponding jar files for EclipseLink 2.7.5?
I'm sure that I'm missing something very obvious here since updating the persistence platform is certainly a common and easily done task... any help appriciated.
I was able to update to EclipseLink 2.7.5 by manually adding a new user library and then selecting this library in the JPA project dialog:
In the user library I simply added all jar files of EclipseLink 2.7.5 in the EclipseLink jlib folder.
Note that the folder of the library must not be a subfolder of the Eclipse project folder, otherwise Eclipse Dali will complain with the following error message (see this question):
The class 'javax.persistence.Convert' is required to be in the
selected libraries
Note also that for some reason it was necessary to move the EclipseLink 2.7.5 user library to the top of the dependency list in the Eclipse Run Configurations dialog.
I will happily accept any other answer that provides a more convenient way of updating EclipseLink.
I executing migration from a mobilefirst 7.0 project to mobilefirst 8.0
In 7.0 project there are some java files that does not belong to Adapters, but to server (utils and constant classes, for example).
Checking official documentation for migration purposes, I have not beenable to find anything about how to manage these kind of files.
Anyone could provide me some information about how to migrate this logic?
With MFP 8.0, the concept of packaging custom Java classes within the runtime war file does not exist.
However, you can still use the custom Java classes:
For the custom Java classes that would become your CustomLoginModule/Authenticator:
With MFP 8.0, customLoginModules and authenticators are replaced by SecurityCheck adapters. These are maven projects. The validation and code that was in your custom classes can be in your SecurityCheck adapter project.
Details here.
For custom Java classes that are invoked from Javascript adapters:
Javascript adapters are also maven projects. And the custom classes can be a part of the JS adapter project.
Details here.
Any other common / utility classes/jar files:
Add any JAR files that are not in the Maven repository:
Add the JAR files to a local repository, as described in Guide to installing third-party JARs, then add them to dependencies element.
Add the JAR files to the dependencies element by using the systemPath element. For more information, see Introduction to the Dependency Mechanism.
More reading about migrating adapters from earlier versions to MFP 8.0.
We had similar issue but we tackled it by moving the code to Javascript adapters(incase of static values). But in case of Pure Java code you have to use Java adapter because in MFP 8 we cannot put java files in the servers as the concept of WAR deployment is not there.
I'm having trouble in implementing file upload handling with Jersey, Glassfish 4 and Netbeans. I know there are a lot of tutorials out there but all of them use maven projects.
Like we know that in Netbeans web application project, after we choose Glassfish as the server, we can use all of the JEE API cause automatically Netbeans add JEE API from Glassfish to our library (like in the picture below). I think its only for compiling and not included in the deployed war.
We can even make a new non web Java application and use JEE API by adding Java EE 7 API to our library, its just API for compiling, in the runtime all of the classes are provided by the server (like in the second picture ).
Now, I want to use the Jersey Multipart API for handling file upload. Glassfish already has the required jars in its modules folder, like jersey-media-multipart. (3rd picture), I know that they are provided in the runtime but I need them to compile my project. Simply adding the jars to the project library is not a proper way cause it gives me a lot of weird errors and we know we shouldn't cause Glassfish already provides them.
I need something like Jersey Multipart API to compile the project so that in the runtime the project uses all of the classes that Glassfish already provides. Just like the Java EE 7 API Library that Netbeans provides and work well.
Well, here's the solution...
If you only add the jersey-media-multipart, you'll get error HttpReader not found so you need to aadd all of the jersey jars in the glassfish modules.
Next, right click on the libraries folder in the netbeans project and in the compile tab, uncheck all of the jersey jars in the package column to make them get excluded when we build/ run the project .
Hope this helps anyone who have similar issue.
I am developing an application under Websphere Application Server v8.0 and I need to use org.codehaus.jackson:jackson-core-asl and org.codehaus.jackson:jackson-mapper-asl version 1.9.2 (mandatory).
On WAS 8.0 such libraries are already included in his runtime, but his version is older. It's 1.6.2 (you can see it in these images):
http://i.stack.imgur.com/dTv4a.gif
and
http://i.stack.imgur.com/Vs3TM.gif
I added 1.9.2 jars on the classpath, but the application uses libraries that are bundled in WAS (1.6.2), ignoring the ones in classpath.
Because of this, I can't use some jackson features in 1.9.2 version, that were not in 1.6.2.
My question is: Is possible to configure WAS to not use jackson from his own bundled jars, and let the application to use jars from classpath?
To override the vrrsion provided by the server when called by your application, add the library to an "isolated shared library" then associate it with your app.
I have a project that has two needed dependencies for it. These dependencies have in turn apache cxf dependencies. Dependency A uses apache cxf versions 2.4.0 where dependency B uses apache cxf versions 3.1.0.
Because classes were changed between the versions, using one or the other results in ClassNotFoundException's.
A little description of what they are, Dependency A is the client jar for some old SOAP webservices. This includes the autogenerated files from wsdl2java. Dependency B is the client jar for a new REST webservice.
The main project uses Maven to handle dependencies, is a war, and is on tomcat 7.
Any thoughts for what I could do to try and get this to work correctly? I have already tried making the REST client a jar-with-dependencies and bringing it in through Tomcat's common classloader with no luck.
EDIT
After reviewing the dependencies I am bringing in, I can't simply update the dependencies because I do not have control of some of the dependencies being brought in. I would need to alter what those jars are doing and that will not work.
Its never a good idea to use two version of same dependency as it can create discrepancies in your project.
Ideally you should latest version and then make the old code compatible with latest version