4

I'm developing an enterprise application on Java EE 6 platform. The IDE is NetBeans 7.2 and the application server is GlassFish 3.1.2.2.

The business logic has to use a library (HBase-RDF to be specific) to handle some tasks in its core. The original HBase-RDF code depends on many packages of which I believe their newer versions are already used by Glassfish. For instance, I can see javax.xml, javax.activation, com.sun.jersey and similar packages already included in the jar files.

Although I had previously developed not-so-trivial Java EE applications in the past, I have faced countless headaches developing the application which may or may not be related to this. From what I had read on the web, including dozens of stackoverflow questions and bug tracking systems, I guess I may be able to get rid of some of those headaches if I can package the original library (HBase-RDF) with all its dependencies as a whole jar file and prevent them being included directly in the project.

My first question is, am I right about the cause of the problems? Can this be the source of my problems? I guess the answer would be yes, because I have already solved one of my problems by removing JAXB and Xerces jars from the classpath and fortunately those portions of the Hbase-RDF I have to work with does not engage them.

And the second question is, in case that I'm right about the previous question, how can I do this? How can I restrict these libraries to be used only by one library (Hbase-RDF)?

NOTE: It may be useful to say that the build process finishes without any problems, but I face two major problems deploying and running the project. First, the application deploys successfully on my local Glassfish instance which is installed alongside netbeans, but the same .ear package fails to deploy on another same-version instance and the server.log file does not contain anything helpful for finding the cause of the problem. The error is very similar to this but the proposed solutions don't work. The second problem is very similar to this and again, I have tried every single proposed solution with no luck. It's interesting to see that the web service inside the web module calls the EJB successfully, but the JSF facelet index.html fails to run.

Community
  • 1
  • 1
Arash Shahkar
  • 655
  • 3
  • 12
  • 24
  • Do you use Maven, Ivy, Gradle or so? – Piotr Gwiazda Aug 29 '12 at 20:25
  • The original library code came with a pom.xml. Since I don't use maven , I just packaged the library in a jar file and included it alongside its dependencies in my project. It might be a mistake and I would be glad to hear about the correct thing to do. – Arash Shahkar Aug 29 '12 at 20:27
  • 2
    This is Maven that makes such things for you. It basically compares versions of dependencies and if allowed picks only one or shows you where the collisions exist. Please post pom.xml from the library and the we'll see. – Piotr Gwiazda Aug 30 '12 at 07:26

1 Answers1

0

I am not really sure if your concern is about the build process or the deployment.
Because for deployment, if you have a library that is dependent on a different version of a library you already deploy this is impossible to work without resorting to OSGi (can not have both versions of the library with the same classloader).
Have you tried completely removing the dependent libraries and only use the newer versions.
If your only dependencies are for JAXB and the xml package of java you might be lucky

Cratylus
  • 52,998
  • 69
  • 209
  • 339
  • I have already tried this. The code inside the library would break. It appears to be a matter of backward incompatibility or, despite my efforts to be sure about what I'm doing, I might have removed something that wasn't present in the newer libraries. Even packages like javax.servlet are included as dependencies... – Arash Shahkar Aug 29 '12 at 21:02
  • Did you try removing only the common libraries? – Cratylus Aug 29 '12 at 21:04
  • I tried this before posting the question as it was the last thing I could think of. The library code breaks. – Arash Shahkar Aug 29 '12 at 21:21