I Wanted to migrate my existing code from JMS1.1 to JMS 2.0. I am deploying application through WebSphere Liberty Profile 16.0 using Java 8. When I am enabling wasJmsClient-2.0 feature in server.xml, I am getting below error:
['wasJmsClient-2.0' --> 'com.ibm.websphere.appserver.internal.jms-2.0' --> 'com.ibm.websphere.appserver.javax.connector.internal-1.7'] and ['ejbLite-3.1' --> 'com.ibm.websphere.appserver.transaction-1.1' -->
'com.ibm.websphere.appserver.javax.connector.internal-1.6'] features are in conflict. Select a compatible set of features.
How do I know which features are compatible and which are not?
In general, most feature incompatibility issues in WebSphere Liberty come when mixing features from Java EE 6 technologies with features from Java EE 7. This is the case in your example - wasJmsClient-2.0 is a part of the EE 7 feature set while ejbLite-3.1 is part of the EE 6 feature set. You can resolve the feature incompatibility by changing feature ejbLite-3.1 to ejbLite-3.2.
If you want to determine the compatibility of multiple features, there are two ways that I know of (both are somewhat complex...):
1) Inspect the feature manifest files in the wlp/lib/features directory, and look for the Subsystem-Content header - and specifically entries that are of type "osgi.subsystem.feature". These are the feature's dependencies - some of them will declare that they can work with different versions of a particular feature. Others are more stringent.
2) Run "wlp/bin/featureManager featureList myFeatureList.xml". This will generate an XML file that will provide the same information as the feature manifests, but in an XML format that may be easier to read. It will show the dependencies like this:
<feature name="wasJmsClient-2.0">
<symbolicName>com.ibm.websphere.appserver.wasJmsClient-2.0</symbolicName>
<singleton>true</singleton>
<displayName>JMS 2.0 Client for Message Server</displayName>
<!-- ... -->
<include symbolicName="com.ibm.websphere.appserver.channelfw-1.0"></include>
<include symbolicName="com.ibm.websphere.appserver.transaction-1.2"></include>
<include symbolicName="com.ibm.websphere.appserver.internal.jms-2.0"></include>
</feature>
From there you could follow the dependency chain and see that wasJmsClient-2.0 depends on transaction-1.2, but that ejbLite-3.1 depends on transaction-1.1 - and neither feature would tolerate the other version.
JMS 2.0 and EJB 3.1 are at different Java EE spec levels. Try switching from ejbLite-3.1 to ejbLite-3.2 (and update any other features in your server configuration to all match the EE 7 spec level).
Related
Can a Java 6 application work on Webpshere 8.5 if the nodes are built using Java 7? I have an EAR which was developed using Java6 and deployed on Websphere 8.5 using EA but the Webservice always gives 404.
Thanks.
It appears that that no support is provided for Java SE 6 in that version of WebSphere.
From the online documentation for WebSphere 8.5.5 (not sure if this is the version you are using tho')
Notice: Java SE 6 is being removed from service. Java SE 8 is the
recommended Java SDK because it provides the latest features and
security updates. You can continue to use Java SE 6, but no service
can be provided after the end of the support date, which might expose
your environment to security risks.
In fact, it appears that not even Java SE 7 is supported in this version of WebSphere either
There is a confusion here about the meaning of "version" and how it applies to JavaEE applications:
There is the version of the JVM which is selected to run the server.
There is the JavaEE specification level used to encode XML documents (web.xml, application.xml, ejb-jar.xml, etc) which are within an application.
There is the JavaEE specification level which is supported by the server.
There is the java compiler level which is set for classes packaged within an application.
There is, technically speaking, no specific version associated with an application. That an application is at Java 7 can mean "the classes of the application were compiled to java7", or, "the XML descriptors are set to the versions available to JavaEE7", or, "the function of the application requires a container which supports JavaEE7".
A key detail is that when running with WebSphere, its the server which decides to which JavaEE specification the application is run, not any feature of the application.
I'm guessing that in the original question, "Java 6 application" means the application was compiled to java6 and that the application features are limited to those available in java6. That should work on all of WebSphere v7.0, v8.0, v8.5, and v9.0 (at all service levels).
There are some complications to consider when using a distributed topology (having a DMGr node and more than one application server nodes). A frequent complication is that one or more of the application server nodes is at a lower version than the DMgr node. This is a supported scenario (with some limits on how big of a version difference is supported). The scenario is typical when a topology (a collection of federated nodes) is being migrated gradually from a particular WebSphere version to a higher version, and during the migration a mixture of node versions is available. When this is the case, the DMgr tracks the version of the application server nodes and constrains processing of the application to ensure the deployment is valid to all of the application server nodes to which the application is deployed.
Since the JavaEE level is set by the application server version, and since, generally, higher versions of the application server implement higher JavaEE levels, applications can function differently when migrated between application server versions. Whether this is the case for this question cannot be known without looking in more detail at the exact failure which is occurring.
Does liferay 6.2 allow using new Java 8 date classes such as LocalDate to be used as a datatype for entity column fields,in order to utilise more features on the same.We need to use
<column name="createDate" type="LocalDate" />
instead of<column name="createDate" type="Date" />
Is there some other means to achieve this?Does tweaking hibernate version,allow usage on the same,if so,is that valid?
Liferay 6.2 started with Java 7 compatibility and only got compatible with Java 8 later, mostly due to limitations of the supported application servers - this is a good indicator that there's nothing foreseen with regards to Java 8 classes. While they might work, you might run into untested territory. I'm neither saying it does nor it doesn't - although I suspect that you have tried already and ran into problems when you ask the question here.
As Guivani Grifante said, upgrading Hibernate within Liferay most likely will result in a huge mess, and if you are ready to do that, I'd rather ask to upgrade to Liferay 7 (though I didn't double-check its Hibernate version).
Another means to get to such an adoption is to use the old Date type and just add a converting getLocalDate() and setLocalDate() to the YourModelImpl and just implement the conversion yourself. Yes, a bit weird, but might be the quickest fix, without a lot of immediate upgrade hassle. However, if you use 6.2 CE, note that there won't be any more updates and you should move on to 7 sooner rather than later. If you're on EE, you'll have a while of support left.
This isn't the only problem if you deploy a portlet with Java 8 into Liferay. If your code was compiled with Java 8 and contains remote services generated by service builder, you will get an error while deploy such portlet. This is caused because Liferay uses a Jodd api to analyze bytecode and get the parameters names to show in /api/jsonws
Hibernate 5.x has support to new date api, however, there is little chance of upgrade without break Liferay 6.2.
From developer viewpoint, what is diference between WebSphere Application Server(1.5GB) installed by Installation Manager and WebSphere Application Server V8.5 Liberty Profile (65 MB)? I will develop an application based on EJB, JSF and JPA. According to my search, Liberty Profile is an easy way to start develop with Websphere. I would appreciate any comment because I am in charge of preparing the workstations for a team and it is my first time to heard about Liberty Profile. I guess that Liberty Profile must be a smaller Web Server similiar to Tomcat plus EJB support and without Console Administration.
The key difference between WAS Liberty and WAS Classic boil down to the following: Java EE 7 support and Legacy app support
WebSphere Liberty supports Java EE 7 as of 8.5.5.6, WAS classic does not. WAS 9.0 supports Java EE 7
WAS Liberty does not support some of the older apps that have now been deprecated in the Java EE API such as JAX-RPC.
If you inherited an old application that takes advantage of WebSphere specific extensions you're generally bound to WAS Classic
Existing administrative and deployment scripts would not likely work on WAS Liberty
Network Deployment support is not as robust in WAS Liberty
However, if you are doing a new app it isn't too bad and you can pay for support for it without having to redeploy to something new unlike Glassfish or WildFly. There's a 2GB limit for production on the organization level, but you can have unlimited development instances. From what I can tell this is based on the honor system.
The following article documents at a high level the differences
https://developer.ibm.com/wasdev/docs/was-classic-or-was-liberty-how-to-choose/
The white paper also referenced by the article details each difference
http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/documentation/ChoosingWASClassicorWASLiberty.pdf
The WebSphere Application Server chief architect has a blog post entitled Liberty Archive Install and Installation Manager that compares the two approaches.
There is also a side-by-side comparison on page 9 of the IBM WebSphere Application Server V8.5.5 Packaging Highlights document.
You can take a look at this Redbook http://www.redbooks.ibm.com/abstracts/sg248076.html?Open particularly chapter 1 "An introduction to the Liberty profile" to learn more about Liberty Profile.
As for the programming models supported (which you can check on the same chapter), depending on the exact versions of EJB, JSF and JPA you need to work with, Liberty could, our could not be a fit for development. Also, in the same chapter you can read about the compatibility between Liberty Profile and the full Profile.
You can find also this post helpful https://www.ibmdw.net/wasdev/2013/05/20/alasdair_nottingham_talks_about_what_makes_liberty_different/
I have to develop a JAX-WS client which has to be deployed to WebSpehere 7.
WebSphere 7 uses a custom Axis2 implementation.
I've read on this guide (http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html) to use wsimport to generate classes necessary for client.
But generated classes reference to com.sun.xml.ws.spi.ProviderImpl in jaxws-rt.jar (present in JRE6), while when client runs on Websphere they reference org.apache.axis2.jaxws.spi.Provider.
Is it correct? Using Oracle JDK wsimport is the correct way to follow also if clients will be use Axis2 implementation?
There should be a wsimport tool as part of your WAS installation. I found mine under /IBM/WebSphere/AppServer/bin
Try using that tool to generate your classes, instead of the one from Oracle. It should generate classes that are more compatible with WebSphere.
You could also go get Axis2 from Apache. I imagine that Apache's wsimport (or equivalent) will produce classes that are most server independent.
http://axis.apache.org/axis2/java/core/download.cgi
Use WebSphere's own wsimport. There's a script you can run, a WSDL2Java Ant task you can use, or if you have RAD, you can do it within that.
Artifacts generated by wsimport are portable, i.e. they don't contain references to implementation specific classes. The actual JAX-WS implementation is selected at runtime. Therefore, it doesn't matter whether you use Oracle's or IBM's wsimport.
What is the best choice for an open source Enterprise-level application server when using Java 6 and Spring 3.1? Glassfish or JBOSS? Looking for good support e.g. online documentation, features, ease of use and set up, good performance, security, scalability, high availability features etc. that an enterprise would require. Enterprise being a large commercial or government client.
Are you using EJBs? If not, I would recommend jetty. jetty is a very light-weight container for doing most of the exploration/testing you would want to do in a project. Another plus that jetty delivers is that it is configured with only the most basic features enabled/configured by default.
Are you using Maven? If so, I would also recommend jetty-maven-plugin. In the past, I've had some success with using the jetty-maven-plugin for local testing on a previous project.