We are using IBM WAS 7 as the server for our application. But the organization's rules do not allow us to have servers installed in workstations. I have this J2EE web project that uses WAS 7 as the target server runtime.
At first, I installed WebSphere® Application Server V7.0 tools for Eclipse. I thought it will provide the runtime along with it as well. Now I can see the option of WAS 7 in server runtime, but on selecting it I have to provide the path where WAS 7 is installed. And I don't have that.
Can I use any other server runtime and expect that it will work within WAS 7? If not, is there any way to just get the runtime without installing the server?
If you are using fully standard Java EE APIs (and no special WebSphere classes), you can simply add the Java EE API jars to your project classpath.
Since WebSphere 7 is Java EE 5 compliant, you could go to maven and download the Java EE 5 API jar and add it to your classpath. This will allow you to compile your code in eclipse.
If you need some WebSphere specific APIs, then you need to tell your development organization that you need to have access to the Jars somehow so that you can compile your code against them. Have your legal team investigate if you can distribute the WebSphere jars to developers for compiling purposes.
Another option is downloading WebSphere Liberty (which is free for development useage) and using Liberty to compile and run your code locally. Note that you will have to install a really old version of Liberty to have it match up with the Java EE 5 WebSphere version 7 (currently Liberty is EE 7 compliant).
Disclaimer: I am a developer for both WebSphere Traditional and WebSphere Liberty. The reason I am suggesting Liberty instead of other app servers is because the askers org is ultimately using WebSphere Traditional, and Liberty will have the closest match in behavior.
It depends a little on the meaning "But the organization's rules do not allow us to have servers installed in workstations".
Often this is due to licencing constraints, in which case you can install an open-source J2EE server like Tomcat or JBOSS. So long as your apps do not call IBM-specific libraries, the same binary should run on any of these environments.
Related
we are using one java application in wildfly server which uses java 1.8.0_202, now we want to migrate the java from oracle jdk to adoptopenjdk. I changed the path of new openjdk in management console of wildfly server.
Now the question is do we need again rebuild the application using adoptopenjdk or can i use the old war which is deployed.
Thanks in advance!..
As I cannot comment because of lack of reputation as an answer:
Normally you can run a Java Application without knowledge of the Java it was built with if the versions match. Second: Why don't you just try it? If you have these strong concerns you should try it in a test environment.
You should not need to do anything to migrate from an Oracle JDK to OpenJDK. Just change the path to the JAVA_HOME and that's it. The only possible issues would be if you use Oracle specific API's which one should not be doing anyway :)
I have to compile a Java EE project with JBoss 7. When I run with JBoss 7, Netbeans creates a .war file. Due to problems with my environnment, I have to deploy this .war file with Tomcat6 on a virtual machine.
The problem is that the .war created is not compatible with tomcat6.
I tried to install tomcat7 on the virtual machine, but I have other problems like "NoClassDefFoundError".
So I'm looking for a way to convert the .war in the right version. How should I do please ?
There is no standard way to achieve this goal ("convert a .war file"), as Tomcat6 (out of the box) isn't a JEE certified application server - just a web container:
Apache Tomcat, a Servlet and Java Server Pages container
Thus, certain libraries that are part of a true JEE-application server are not bundled and present in the /lib folder of a plain Tomcat installation, for instance implementations for JTA, JPA, CDI, JAX-RS, JAX-WS...
However, you could try and download an enhanced Tomcat, namely TomEE, as it is - in it's latest release - JEE6 certified (and has several variants):
Apache TomEE, pronounced "Tommy", is an all-Apache Java EE 6 Web Profile certified stack where Apache Tomcat is top dog.
This might be a good solution to your migration approach as JBoss7 is also compliant to JEE6 level.
After you have downloaded TomEE you could then try to deploy your application in there. Nevertheless, you should have provided the full stacktrace or at least the Class (incl. fully qualified package) that is not found, as there might be certain third-party libraries in JBoss 7 that are not present in TomEE or other application servers.
Hope it helps.
War Files itself don't have a Version.
The Java Classes them selfs have a Java-Version (e.g. if they using Java 7 or Java 8).
If your Tomcat runs on Java 6 and you compiled with Java 7 you'd get a UnsupportedClassVersionError. If thats the case, you have to either update the Java-Version of Tomcat or compile your Code with Java 6 (and remove Java7 Features).
Other than that, it might be possible, that you're using Features from JBoss 7 that aren't available in Tomcat 6 (e.g you referring to Servlet 3.0 in your App, but Tomcat doesn't support that version). To make it work in this case, you'd have to remove all the Features, that Tomcat doesn't support.
Currently my server is running of the Tomcat 5.5.26 and JDK 1.5.15.
Now I want to change to tomcat 6.0.29 and JDK 1.6.29.
There was many application running of the current environment so if I can change to new environment the required to compile all the application again and upload on the new environment or existing war file is working with new environment?
The applications should just work. However, you should do thorough testing of each one before inflicting them on your users, just to make sure. Your apps may be unintentionally relying on Tomcat 5-specific behaviour.
Furthermore, there should be no need to recompile under java 6 to make them work. However, you should check that the apps do still compile under Java 6. Again, they should, but it's worth checking.
Incidentally, why Tomcat 6? Tomcat 7 is current stable version of Tomcat; if you're going to migrate, you should migrate to that.
I imported an EAR project I had written on another system into eclipse so I had code before I had completely set up the GlassFish server environment and some other config files.
I noticed that even though I had a JDK and JRE integrated with my Eclipse environment it wasn't recognizing any library files like javax. This was preventing any kind of debugging until I had finished installing the runtime environment which for me was GlassFish 3.1.
I am confused about what all the runtime environment contains because I thought the libraries necessary to interpret my code in the IDE were in the JDK and WPT web tools that I had installed and not on the GlassFish server which I think of as "just a container and Java EE server".
Java SE does not include the Java EE libraries.
There are non-Java EE javax.* packages in Java SE, however.
I'm having a bit of a problem building a Java Enterprise Edition web application on Mac OS X 10.6.2 using Ant 1.7.1, Glassfish v3 and Java EE 6.
The problem is that the build process does not find the Java EE libraries which fair enough as I don't think Apple supply them with the default Java installation but I know they exist in the Glassfish distribution.
Which jars are the correct ones to build against (I'm assuming javaee.jar is a general jar which references all the other needed jars) and what should I be putting in my ant build.xml file?
Any help is very much appreciated.
You need to have the javaee.jar in your ant classpath, but be aware: do not copy the javaee.jar to the webapp (WEB-INF/lib folder)!
I would encourage you to get and use NetBeans or GlassFish Tools Bundle For Eclipse to start working with Java EE 6 and GlassFish v3... (read my profile to find out why).
If you are determined to avoid using either of these IDEs, then I would recommend that you download the Java EE 6 SDK, to get started. The SDK includes a number of different samples that can be built and deployed using Ant. (Use -verbose to learn the 'secrets')