I am using Axway server which runs on jre 1.5 . So it accepts all classed builded below 1.6 . But problem is I read THIS LINK and I got this line as guide
Environment:
* Java Developer Kit (JDK) 1.4.x or greater for deployment and 1.5.x (Java 5) for compiling/building. As of AMQ 5.5.0 you need JDK 1.6.0 to**
Which says I can use ActiveMQs below version 5.5 for jre 1.5.
when I use ActiveMQ 5.4.3 am getting bad class version error.Please help me.
This is the line where am getting this error
Object o = Class.forName("org.apache.activemq.ActiveMQConnectionFactory",
true,ConnFactory.class.getClassLoader())
.newInstance();
You could extract the jar as a zip file, and then look inside the folder and check inside the META-INF directory. The MANIFEST.MF file will tell you what version of the jvm the jar was compiled with. I just grabbed the 5.4.3 version of the activemq jar and it said this:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: chirino
**Build-Jdk: 1.6.0_26**
Specification-Title: ActiveMQ :: Jar Bundle
Specification-Version: 5.4.3
Specification-Vendor: The Apache Software Foundation
Implementation-Title: ActiveMQ :: Jar Bundle
Implementation-Version: 5.4.3
Implementation-Vendor-Id: org.apache.activemq
Implementation-Vendor: The Apache Software Foundation
which clearly shows that it was built with the 1.6 jvm. Might need to download the source and build it on 1.5 manually.
In maven repository the last version of activemq built on jdk 1.5 is 5.4.2.
Problem is due to the jvm config file entry for jar newly added.
I don't know and I am not responsible and I don't have permission to do any Admin related privileges.
I put the jar in CLASSPATH exactly.So its ok for all the classes to access that.
But problem is in JVM config file I have to put the entry, I mean I have to give name of the jar with CLASSPATH in jvm.config file of axway.Though I put my jar in class path without put entry in jvm.config, it is worthless.Because while jvm get initialized it checks the config file first to add jar with it.
Related
What impact will be happen if I change the Bundle-Version which present in Manifest.MF file?
Also I could not understand why we used Bundle-Version, Manifest-Version, Bundle-ManifestVersion into Manifest.MF file?
Manifest-Version is the version of the Java manifest specification that this manifest uses - normally always 1.0. You won't normally change this.
Bundle-ManifestVersion is the version of the OSGi manifest specification that this manifest uses. Again you won't normally change this.
Bundle-Version is the version of the plugin in the form 'major.minor.micro.qualifier'. 'qualifier' is usually some sort of build id. You will normally increment one of 'major', 'minor' or 'micro' each time you change the plugin.
OSGi uses the term 'Bundle' for what Eclipse calls a 'plug-in'.
Bundle-Version - The version of the OSGi bundle (in Eclipse bundles are also called plug-ins): bundles can define dependencies to other bundles in a version range
Manifest-Version - The version of the JAR Manifest format (up to now 1.0)
Bundle-ManifestVersion - The version of the OSGi Manifest format which extends the JAR Manifest format (2 since release 4)
I am creating a Vaadin (version 7) portlet, my development environment is eclipse 4.3.1 + tomcat-7.0.27+Liferay-portal-6.1.1-ce-ga2, I am checking the stuff on tomcat and the portlet runs fine there.
Now my deployment environment is Glassfish-3.1.2+Liferay-portal-6.1.1-ce-ga2, the same portlet and the log message is: "sampleApp was successfully deployed", the Portlet error is "Failed to load the bootstrap javascript: ./../../VAADIN/vaadinBootstrap.js".
Please help me solve this.
From Book of Vaadin:
Liferay 6.1, [...], comes bundled with an older Vaadin 6 version. If you want to use Vaadin 7, you need to remove the bundled version and install the newer one manually as described in this chapter.
In these instructions, we assume that you use Liferay bundled with Apache Tomcat, although you can use almost any other application server with Liferay just as well.
12.5.1. Removing the Bundled Installation
Before installing a new Vaadin version, you need to remove the version bundled with Liferay. You need to remove the Vaadin library JAR from the library directory of the portal and the VAADIN directory from under the root context. For example, with Tomcat, they are usually located as follows:
tomcat-x.x.x/webapps/ROOT/html/VAADIN
tomcat-x.x.x/webapps/ROOT/WEB-INF/lib/vaadin.jar
12.5.2. Installing Vaadin
Get the Vaadin installation package from the Vaadin download page
Extract the following Vaadin JARs from the installation package:
vaadin-server.jar,
vaadin-shared.jar,
as well as the vaadin-shared-deps.jar and jsoup.jar dependencies from the lib folder
Rename the JAR files as they were listed above, without the version number
Put the libraries in tomcat-x.x.x/webapps/ROOT/WEB-INF/lib/
Extract the VAADIN folders from vaadin-server.jar, vaadin-themes.jar, and vaadin-client-compiled.jar and copy their contents to tomcat-x.x.x/webapps/ROOT/html/VAADIN.
$ cd tomcat-x.x.x/webapps/ROOT/html
$ unzip path-to/vaadin-server-7.1.0.jar 'VAADIN/*'
$ unzip path-to/vaadin-themes-7.1.0.jar 'VAADIN/*'
$ unzip path-to/vaadin-client-compiled-7.1.0.jar 'VAADIN/*'
You need to define the widget set, the theme, and the JAR in the portal-ext.properties configuration file for Liferay, as described earlier. The file should normally be placed in the Liferay installation directory. See Liferay documentation for details on the configuration file.
Below is an example of a portal-ext.properties file:
# Path under which the VAADIN directory is located.
# (/html is the default so it is not needed.)
# vaadin.resources.path=/html
# Portal-wide widget set
vaadin.widgetset=com.vaadin.portal.gwt.PortalDefaultWidgetSet
# Theme to use
vaadin.theme=liferay
I installed openjdk 1.7.0 and set it up in IntelliJ 10.5
When I compile (anything) I get the error "Fatal Error: Unable to find package java.lang in classpath or bootclasspath".
I looked at this question:
IntelliJ gives Fatal Error: Unable to find package java.lang in classpath or bootclasspath but all jar files inside the lib directory are already added.
Ok. I was wrong there weren't all jars added. I found some more in (sub)directories other than 'lib'. After adding all those manually everything is fine. Seems like even IDEA 10.5.2 does not like the structure in openJDK yet.
Try IDEA 10.5.2. Make sure that JDK path is not a symlink. If the issue remains, specify your OS and attach a screenshot of JDK classpath configured in IDEA.
I had the same problem. I added all jar files in the following directories manually:
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/1.7.0.jre/Contents/Home/lib
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/1.7.0.jre/Contents/Home/lib/ext
I have been working on this problem for one whole day but in vain without any effective solution.
I have an ear file packaged with an ejb and a handful of jar files (including hibernate and the other dependent jar files).The ejb is stateless and enabled as a web service.
The ear file has been packaged using maven and has the below structure
ear->projectrelatedejb.jar
->hibernate.jar
->otherdependent. jar
->META-INF/application.xml
->META-INF/manifest.mf
The application.xml and manifest file are automatically generated by maven when I do a package.
When I deploy this ear file on glassfish it gets deployed with the ejb methods being accessible using web services. However when accessing the application (using soapui),
the ejb methods that perform some database functionality using hibernate throw java.lang.NoClassDefFoundError for the hibernate api during runtime.
It is obvious from the error that the hibernate jars are not on the classpath during runtime but since the jars are within the ear Glassfish should have
added it to the application classpath.
I tried various options like adding the classpath entries to the manifest.mf during the package (by using the element addClasspath with the maven-ear-plugin) which didn't do any good.Also with Glassfish we cannot add the dependent jars as modules to the application.xml unless the jars are application client jars
(Glassfish wouldn't deploy the ear file if the application.xml has the dependent jars declared as modules).
I also tried placing the jars in the lib directory within the ear (which isn't actually required) and with the manifest Class-Path header referencing the jars in the lib directory which also didn't fix the problem.
The quick and dirty fix which I can do to get this working is to place the hibernate and the other the dependent jars in Glassfish's lib directory.However,this is a bad practice
and I am somewhat reluctant to do it.
I would really appreciate if someone can provide me with a working solution to this problem.I have gone through the net looking for this problem
but couldn't find any solution.
Wondering if its a bug with glassfish or does glassfish need something special to reference the jars in an ear.
Thanks in advance.
I found a similar problem which is discussed here: http://www.tricoder.net/blog/?p=59.
Simply put, try putting the libraries in EAR/lib directory and according to JEE5 spec, glassfish will add them to class path automatically.
I used Server Library option to deploy application JARs and it worked for me.
Right click on your EAR-> Properties -> Libraries-> Add Library -> Create -> give name and change type in Library Type to Server Libraries then add JARs that should be deployed and confirm.
I work with NetBeans 7.0.1 and GlassFish server 3.1
When you say you added classpath entries to manifest.mf, which manifest.mf do you refer to? The one in ear-root/META-INF/manifest.mf ? Try adding a META-INF/MANIFEST.MF to your ejb module with Class-Path entries!
Using a test app to figure out problems with production application and hsqldb.
If I compile the test app with the hsqldb.jar file as an external jar in eclipse the program works. However, if I only have the jar file in my JRE system library I get a pre-9.0 client attempted to connect error from the database.
The two files are the exact same files. Only difference is one was added as external jar and the other was just in the class path. When production app builds it is using classpath to same file and generating the same pre-9.0 error.
The jar you want to use is an HSQLDB version 2.0 jar. There is a second HSQLDB jar which is version 1.8 and is in your classpath before your intended jar.
This is a classpath issue. You should be able to find where the second jar (1.8) is and how it gets into the classpath by using java -verbose or other debugging options.
[added] An additional step you could take to debug this in your application is to print out the value of the field org.hsqldb.persist.HsqlDatabaseProperties.THIS_FULL_VERSION before connecting to the database. This will print the version of the jar used as the client. A successful connection means the client and server jars are the same version.
The server instance prints out its version to the console when it starts.
I would also recommend using the latest snapshot jar for HSQLDB from the http://hsqldb.org/support/ page.
Sorted out problem by moving hsqldb.jar to first declared in classpath.