I found that Hotswapagent works different way in SE and EE application. In SE application I can add a new property to the class (e.g. private Long x;) without any problem, Hotswap can update the code. But I'm not able to do this in my EE application in a JSF ManagedBean, I got "The virtual machine does not support this operation: schema changes not implemented".
My EE application is a Maven Enterprise Application (ejb,web,ear projects) in Netbeans 8.2 with Wildfly 10. I use DCEVM (jdk1.8.0_112) and Hotswapagent 1.1.0.
Simple code changes (e.g. edit method body) are works both in SE and EE applications, but it can't handle new property creation neither in ejb nor in web project. I'd like to know if I made some mistake in settings or this is because the differences between SE and EE environments. Thanks for any ideas.
There's no problem with it. Only when I start application in debug mode.
I would expect the addition of a field to be considered a schema change (in such a case, you would get the exception in both Java SE and Java EE). But Java EE is specific by modification of classes (bytecode) at runtime. I guess that when you inserted a field, it wasn’t just that field what was added, but also some synthetic getter and/or setter was introduced, which was a schema change for sure.
HotswapAgent works on JVM level, there should be no difference between Java SE and Java EE. Most probably your Wildfly server does not use DCEVM, please check your setup.
here there is all you need to know to config any EE app server
Payara + DCEVM config
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.
I've been having very hard time trying to make it work on my end. What I want to achieve is bringing up my spring-boot project that would weave all Java classes with AspectJ when I just run "java -jar app.jar" (Tomcat 8 embedded is used) without any Java agent params.
Is this generally possible? And if yes, what are the required config stuff that should be paid attention to?
Thanks a lot in advance.
It might be possible, but you would probably (at a minimum) need a custom main() method that created an LTW classloader and used that to launch your app. The default classloader in the java -jar would not be LTW-enabled. Any reason you don't want to use an agent (since you obviously control the launcher)?
Here a library that initializes aspectj and spring-aspects at runtime by injecting instrumentation: https://github.com/subes/invesdwin-instrument
You can use it as a sample.
I am trying to write a JAX WS client for a service exposed using Axis2, WebSphere8, Java 1.6.
Standalone client(i.e. client running in my local machine) works fine but when I deploy the client in a application running in same websphere server I get
java.lang.ClassCastException: Cannot cast class org.apache.axis2.jaxws.spi.Provider to class javax.xml.ws.spi.Provider
at line OpenPortType service = OpenService
.create(wsdlFile.toURL(),
new QName( "http://www.test.com/schemas/public/open-api/Open/","OpenService")).getPort(
OpenPortType.class);
When I tried to google I found similar problem existed in weblogic : https://wso2.org/jira/browse/CARBON-4835
When we see source of axis2.jaxws.spi.Provider class we come to know that it's a subclass of javax.xml.ws.spi.Provider !!
I'm wondering what could be wrong ? Any idea ?
Unless you are calling Axis2 capabilities directly, rather than simply using JAX-WS APIs, you do not want to package Axis into your EAR. WebSphere does provide its own JAX-WS implementation which I'm not surprised conflicts with another JAX-WS implementation you've deployed in your app. (In particular, note that WebSphere's own implementation is based on Axis2.)
If you do need to deploy a different implementation, you'll probably have to at least adjust your WebSphere classloader policy to parent_last. There might be more to do as well; it's been a while since we did this ourselves. But it's much easier and cleaner to use the built-in JAX-WS implementation, which means not deploying any of those jars at all.
I am trying to migrate an application from Websphere 6.1 to 7.0
I noticed that many of the ibm MQ/JMS classes have changed/disappeared =)
In particular, I am getting errors on
com.ibm.msg.client.jms.JmsQueue
com.ibm.mq.jmqi.JmqiObject
it is saying "...cannot be resolved. It is indirectly referenced from required .class files"
Does anyone know what I can do to get this to compile?
thanks
Hard to say exactly from the description so I'll provide some general pointers that may be of help.
The WMQ JMS and Java support was completely rewritten in V7 to use a common JMQI layer. This will affect the jar files that are referenced as well as the CLASSPATH and a few other things.
If you have bundled the WMQ jar files into your application, you will want to delete them and reference the ones installed with WAS instead.
If you used MDB listeners, you will need to switch to Activation Specs.
For more info, see the Integration of WebSphere MQ classes for JMS with WebSphere Application Server section in the WMQ V7 Migration manual and the CLASSPATH settings from the Environment section in the WMQ V7 Using Java manual.
The WebSphere Application Server V7 Migration Guide does not address WMQ in depth but it does have pointers to additional migration resources such as IBM Education Assistant as well as specific application and profile migration advice.
I know how I'd do this using JBoss: create a *-ds.xml file, and drop it into my deploy directory.
Is there a declarative way to do the same with GlassFish (v3.1)?
Am I thinking about this the wrong way? (See next question)
Is there a more-Glassfishy way to get my Java EE application to talk to a database?
Other potentially-revelant info:
I want to connect to a SQL Server 2008 database
I'm using Eclipse + GlassFish Server Tools
I know next to nothing about GlassFish. I'm much more familiar with JBoss
You can define it in application.xml or ejb-jar.xml of your EAR. You can even use annotations.
Long answer short: DataSource Resource Definition in Java EE 6.
BalusC is right (+1), with Java EE 6 you can declare datasource definitions either through annotations or through the use of deployment descriptors in a standard and portable way.
Just in case you'd be also interested by creating other resources than datasources like JMS resources, you can also package a glassfish-resources.xml file as part of your application. See:
Supporting glassfish-resources.xml
4.1.3 Application scoped resources