I have simple question. I'm working on JAVA application which runs on Glassfish 4.1, I wrote code that needs > Guava 18.0 libs, when i run my code in my local IDE it works well, but when i try to run this code as part of the application on Glassfish I'm getting error caused by the fact that the application contains Guava libs in version 13 and i need version 18+. So, my question is:
Can i somehow add Guava 18.0 libs to the Glassfish and tell it to
prefer this new library in my application?
Thanks for answers.
Try this:
Download The new library files you're interested in (or pull them from your local repository considering you already have them there).
The outdated files in Glassfish should be inside of the glassfish module somewhere near:
\glassfish4\glassfish\modules
Replace the old library file with the newly downloaded fresh files.
I had to do the same once before with a jboss logger when getting a debugF error and I got this answer from SO here. Good luck!
Related
I am working on an old jsp project. I have to modify it so that I can use it to meet my needs. I was facing issue while using any newer version of tomcat or java sdk. Therefore, I am using Tomcat 5.5.7 and java SDK 1.5. I have updated java class files of this project using eclipse helios (2012). But the implementation don't show up in my project. Like when I change the database name and run the project it still wants to use the old database name. I have tried to upgrade the whole project to a new version of tomcat and java sdk but it doesn't work. Can anyone help me with this?
Steps you need to take -
Import the project into eclipse - Create a new project, import using existing source files.
You need to setup the Java Facet of "Dynamic Web Application" along with some other Facets to make this application run successfully on the tomcat container inside of eclipse.
You need to install the server tools in eclipse. Using the Java EE perspective is very helpful.
When making changes to the JDK or the server runtime, as you mentioned, you will need to update the projects build path. Right click on the root of your project and go to the build path. Change the SDK version, change the runtime version of tomcat that is included with it. You will need to create a new Java Server runtime for any other versions of Tomcat you want to add to the project.
This is a complicated issue, and there is no specific answer, as your question is very broad. I would recommend watching some tutorials on "How to setup Web application projects in Eclipse." Maybe add Java 5 or 6 to the search to get older results.
I am migrating an application that used Jetty 7.4.5.v20110725 to Jetty 9.3.0.M2, using Maven. I already had upgraded the javax.servlet-api to 3.1.0.
But I am using the FakeHttpServer version 0.3.0 for tests, and at this time there is no newer version. It uses the org.eclipse.jetty.server.nio.SelectChannelConnector class that used to exist up to Jetty 8.x, but does not exists anymore in Jetty 9.
Currently my projects breaks at runtime with a NoClassDefFoundError due to the removed class in Jetty that FakeHttpServer tries to use, holding me back from upgrading Jetty. What can I do to fix that?
Note, this was also cross-posted in the Portuguese StackOverflow version: https://pt.stackoverflow.com/q/64548/132
Upgrade the code that uses Jetty on FakeHttpServer for Jetty 9.
That is your only choice if you want to use Jetty 9 with FakeHttpServer.
Looking at the project page for FakeHttpServer, it seems that there have been no updates (commits) to the project tree since Dec 2012.
You'll either have to convince the project leads to update it, or do it yourself.
Note that Jetty contains several ways of testing webapps. Look at the unit tests in the jetty source code and I'm sure you will find the equivalent of FakeHttpServer.
ServletTester comes to mind as one example. Or just create a Server using the LocalConnector is another way.
When running my Java EE app on TomEE I get the following error:
java.lang.NoClassDefFoundError: javax/persistence/NamedStoredProcedureQuery
There are no compile time errors when I build the app.I am developing in Eclipse and have Apache TomEE selected under targeted runtimes in the project properties, so that the project has access to Java EE.
As the project uses Hibernate I have the following jars in the WEB-INF\lib directory (it's my understanding that these jars in turn use javax.persistence):
hibernate-commons-annotations-4.0.4
hibernate-core-4.3.5
hibernate-jpa-2.1
I've seen a bunch of questions like this one detailing that the solution is to add the required JPA jar into the lib directory of the app and all will be well. But although that solution may work it sounds hacky to me, I want TomEE to manage the JPA libraries itself. It's a Java EE server so why doesn't it do this. Whats a clean solution?
#JB Nizet's answer is the accepted solution:
This class exists since JPA 2.1. I guess your TomEE version only
supports JPA 2.0. And indeed, thehome page of TomEE says: "Java EE 6
Web Profile". Java EE 6 includes JPA 2.0, not 2.1. – JB Nizet
I am working on a big project that requires massive financial calculations, I am using
Netbeans IDE 7.3 with a default web application of Java EE 5 (not a maven application)
,My application server is tomcat 7 I am using jsps and servlets my OS is windows 7.
I downloaded and added the jquantlib binary to my application, but when I run it keeps saying that it needs the slf4j-api extension that is not found so i download it also and added its jar to my project but still the error persists.
How can I solve this ? and can anyone give me some guidelines on how to do it ?
The key here is that jquantlib requires slf4j-api version 1.4.0 in the jar manifest:
(from MANIFEST.MF in jquantlib.jar)
Implementation-Vendor-Id: org.jquantlib
Extension-List: slf4j-api
slf4j-api-Extension-Name: slf4j-api
slf4j-api-Implementation-Version: 1.4.0
Tomcat will try to use the version of slf4j-api that you're including in your app, but it's likely that what you've included isn't actually compatible. See http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.34/org/apache/catalina/util/Extension.java#Extension.isCompatibleWith%28org.apache.catalina.util.Extension%29 for details.
Bottom line - try to use slf4j-api version 1.4.0 in your application.
Try removing the lines from the MANIFEST.MF file that mention the sfl4j
am developing a simple web app using jsps and servlets for tomcat 5.5.
Currently using the Eclipse Helios and Dynamic Web Application Project.
For some reason it is a nightmare. We spent 4 hours today trying to deploy a servlet to tomcat. We kept getting errors like
"java.lang.UnsupportedClassVersionError: Bad version number in .class file"
we played around with everything trying to set the build compatibility to what tomcat had but couldn't make the stupid thing work. (Yes it is possible we're incompetent. any suggestions on what we can try looking at are apprecieated)
My friend recalls from long time ago that he used this plugin
eclipsetotale_tomcatPlugin
in order to create a "tomcat project". My question is, does sysdeo tomcat plugin add any features that aren't already available in helios?
thanks
Not sure about sysdeo, but your error seems similar to bug 116713:
If your default JRE is set to 1.4.2 and you have a Web project targetting
Tomcat 5.5 (dynamic Web module version 2.4 and Java 5.0), when you tried to run
a main program, you'll get the error (you mention).
What is your default JRE set for your project?
This scenario happens when the JVM running the code is older than the one the compiler generated code for.
Have you considered simply running Tomcat under Java 6? If that is not an option, please edit your question to include this and any other restrictions on this project.
We used to get that error often when we had Java version issues. Eclipse environment and Windows environment (java_home and path variables typically) are easy to overlook.
Also, you can use javap -v Foo in same directory as Foo.class to find out its version.
Just use the Eclipse IDE for Java EE Developers, 206 MB edition of Eclipse. It has Tomcat and other webserver support built-in by default. Works like a charm!
Sysdeo is an old, as far as I know obsolete, plugin.