SoapUI issue

Facing this below error with SoapUI tool and struggling to resolve it. Here is the solution...

SoapUI ERROR:java.net.ConnectException: Connection refused: connect

Throws above error when some webservice request is being made after successfully generating mock requests from WSDL. I was unable to understand when the WSDL is hit and mock requests are generated properly, why this error appears from mock request. After struggling for a while find out the reason as given below.

Solution steps:

1.       Double click on “xxxPortBinding” from left menu which holds all the mock requests.

2.       Click on “Service EndPoints” to see if EndPoint URL formed is correct. In my case it was omitting context path in the URL field. 

Strangely, SoapUI tool forms new URL to hit omitting the context path. Could be a defect in this tool.

Also, for bad credentials error, add credentials from clicking “Auth” menu and add username and password details there.

Tips on Websphere AS 7

Thought of consolidating couple of issues I faced in making my EAR &WAR files work in WAS 7. Sure, it could save some time in analysing and finding right solution to most of the novice users.  

Application with WebServices - IBM default WS Disabling

First and foremost, application embedded with web services APIs and especially has client logic to invoke  web services, it may fail to work when deployed in WAS 7. This is because WAS 7 comes bundled with Apache Axis 2 and takes control of any web services call from the application deployed and ignores the API provided inside application. To overcome this, follow below steps:

1. Apply latest fix pack (I have tried FP 21) 
2. While deploying the EAR file, option "Classes loaded with local class loader first (parent last)” should be selected in both “Class loading and update detection“ and “Manage Module” sections.
3. Disabling default IBM JAXWS engine - To disable at global (server) level, follow below steps:
1. From admin console add a custom property to disable default engine. Go to : Servers > Server Types > WebSphere application servers > server1 > Java and Process Management > Process definition > Java Virtual Machine
2. Add below property in “Generic JVM arguments” field:-Dcom.ibm.websphere.webservices.DisableIBMJAXWSEngine =true
4. To disable only for particular application 
5. 
   
1.   Add below entry in manifest.mf file of war files (This happens at application level)   DisableIBMJAXWSEngine: true

In case of either of the above steps not working for some reason, follow below step of modifiying the default provided axis2 jar file.

Open '<WAS_HOME>/plugins/org.apache.axis2.jar' and remove 'META-INF/services/javax.xml.ws.spi.Provider'

   5. After above changes restart the server. 

Resolving CXF problem 

CXF in WAS 7 with ClientProxy component fails with below error making one scratch head to figure out solution!

java.lang.ClassCastException: org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler incompatible with org.apache.cxf.frontend.ClientProxy

Code which fails: 

MyWebService ss = new   MyWebService (wsdlURL, SERVICE_NAME);
instance = ss.getTestHttpPort();Client cxfClient = ClientProxy.getClient(instance); 


This issue occurs only in WAS 7 for CXF when generated class used (from WSDL2Java tool) for creating proxy. JaxWsProxyFactoryBean comes to rescue in such scenarios and to resolve this issue.

With JaxWsProxyFactoryBean for creating JAX-WS proxies, slight modification as given below need to be done the codebase:


JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress(wsdlURL);
factory.setServiceClass(MyWebService.class);
MyWebService port = (MyWebService) factory.create();
//and then call ClientProxy as usual but with the object created using JaxWsProxyFactoryBean
Client client = ClientProxy.getClient(port); 


Heap setting change never brings up the server

Heap size change from admin console calls for restarting the WAS but sometimes when the input crossed limit or some mess up happened, sever never comes up. Novice users like me spend hours together to fix this horrid problem. Hope this helps bothered developers like me.

When server is not starting because of your wrong input, just look at this file.

profiles

 AppSrvX

   config

      cells
        cellX
          nodes
             nodeX
               server
                server.xml 

Find jvmEntries element in this xml which will have initial and maximum heap size attributes and change them back to original/proper value.

JDBC Driver Error with MSSQL DB

Encountered this JDBC driver error when my multiple threaded client was inserting records to the MSSQL DB. 


java.sql.SQLException: Transaction (Process ID 59) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:368)


The quick way of solving it is to modify SQL server settings. From SMSS,  advanced settings can be configured to help prevent unintentional issues such as a query that causes locking or blocking. 


To access these settings in SSMS, choose Tools -> Options…  ->  Query Execution -> SQL Server -> Advanced dialog box.


1. Change SET TRANSACTION ISOLATION LEVEL to READ UNCOMMITTED :
This will minimize the impact of your ad-hoc queries by allowing dirty reads. While this can be beneficial for many production environments, make sure to understand the implications of this setting before implementing.


2. Change SET DEADLOCK_PRIORITY to Low :
This will tell SQL Server to select your session as the victim in the event of a deadlock.


3. Change SET LOCK TIMEOUT to a smaller, defined value, such as 30000 milliseconds (30 seconds):
By default, SQL Server will wait forever for a lock to be released. By specifying a value, SQL Server will abort after the specified timeout period when a lock is encountered. 


Though, this solution from server side solves the above issue, it is always not recommended as it could applies dirty read setting to all the DB instances and other transactionally important application may behave odd due to this.

CXF Embedded Application in JBoss-6.x AS

The CXF libraries stuffed in web applications lib folder to enable webservices capability usually works fine with servers like Tomcat (at least till version 6) which has by default no CXF related libraries at server path. But same web application fails even to get deployed in JBoss6.x conflicting with server provided CXF libraries.

When I faced the same issue, it took solid 8-10 hours to find out working solution. Hope my findings helps someone in same despair.

This issue made me take serious look at the class loading behavior of JBoss and I was certain that JBoss would have feature to disable or yield parent (server) classes loading. I have seen the same feature in Websphere application server. With full confidence, I have tried JBoss recommended ways of adding jboss-app.xml, jboss-classloading.xml and jboss-scanning.xml to web application path to make it look for classes from its own lib folder first.

I have tried giving the jboss-app.xml file different names like jboss-app.xml, jboss-web.xml and jboss-.xml etc. to see it work. I was thinking that I was missing correct syntax here and tried many options in vain.

Similarly tried many options with jboss-classloading.xml and I was sure about the following element and unfortunately, this also did not solve the problem.

 I knew surely that the above approach is cleaner and recommended way to go for which was not yielding any result.

As a last resort, I have physically removed all the CXF libraries from server end itself. I have found some cxf related files at common/lib and removed all cxf*.jar from there. Also, from server/default/Deployers/jbossws.deployer directory removed all jars. After these changes, when server was restarted some errors in boot.log appears related to the missing cxf jars but the web application got deployed successfully and functionality was intact.

Probably, it is good to use Jboss 7 as it claims to provide flexibility in choosing webservices kit (either cxf or native) and choosing native kit could resolve cxf classloading issues. Never tried though!


Please take note that this could stop other applications (if any) which depends on JBoss provided CXF libraries! 

Managing JVMs in RHEL

Java fraternity new to Linux environments usually face the trouble of managing JVM instance in terms of upgrading or migrating them. Some time back, when I wanted to remove the old JVM instance, I too faced this issue and hope this solution I found, would help others save some time.

Below step by step approach would help the beginners:

1. Download rpm.bin file
2. run : ./*.bin
3. Follow below steps to remove the old java and add new java into environment

Re configuring the default Java configuration for Red Hat / Fedora

This is done as root or equivalent.

First remove /var/lib/alternatives/java file by typing;

rm /var/lib/alternatives/java

When asked press the 'y' key,

Now to create the new (corrected) alternatives file for java type
the following commands as root (modify for jdk as needed);

/usr/sbin/alternatives --install /usr/bin/java java /usr/lib/jvm/jre-1.4.2-gcj/bin/java 1

/usr/sbin/alternatives --install /usr/bin/java java /usr/java/jre1.6.0/bin/java 2

/usr/sbin/alternatives --config java

You should now see for example:

There are 2 programs which provide 'java'.

Selection Command
-----------------------------------------------
1 /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*+ 2 /usr/java/jre1.6.0/bin/java

Enter to keep the current selection[+], or type selection number:

Type:

In the example above java is already configured correctly [*+ 2] to use Sun's Java, no changes are needed, just press the Enter key here. If you have been following the instructions then you should have the same results (version numbers may be sightly different).

Now type; /usr/sbin/alternatives --display java

You should see for example;

java - status is manual.
link currently points to /usr/java/j2re1.5.0_09/bin/java
/usr/lib/jvm/jre-1.4.2-gcj/bin/java - priority 1
/usr/java/jre1.6.0/bin/java - priority 2
Current `best' version is /usr/java/jre1.6.0/bin/java.

Next you might want to create (or edit) /etc/profile.d/java.sh
file, example below;

export JAVA_HOME="/usr/java/jre1.6.0/bin/bin"
export JAVA_PATH="$JAVA_HOME"
export PATH="$PATH:$JAVA_HOME"

When done creating or editing the file type;

source /etc/profile.d/java.sh

Now any user root or other wise should be able to use the command;

which java

and the results should read something like;

/usr/bin/java

Also any user root or other wize should be able to use the command;

java -version

and the results should read something like;

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

Java Program as a Service in Windows

When first time heard about the requirement of running java programs as a Windows service, my mind ran right towards java native (JNI) programming. Took really some time to figure out that there is a simple way to achieve this. That simple way is to use just one ready made jar file for the same occasion.    
Thought of sharing this which I''m sure many test and development boxes setup requires this for some quick testing references.

There is a free utility tool available for this and can be downloaded from Java Service Launcher (JSLWIN).

The description says that it is a lightweight tool to run Java applications as Windows (NT, Win2000, Win2003) services. JSL is released as a ready to use executable. Setup is straight forward including just one executable and one configuration file.

Thought, there are many ways to achieve it, the way I set up was something like below:

1. Download JSL utility and place it in some directory. IN my case it is E:\JSL

2. Created ServiceLauncher class which in turn calls my entry class. Build jar file for the same.

3. JSL.jar need to be placed in lib folder along with the module that need to be made run as a service and dependent jars. ServiceLauncher.jar to be placed in JSL.

4. Change the Java path, JSL path, library path and very importantly working directory information in jsl.ini file

5. Place all the module related files(XML and classes here) in E:\JSL

6. From command prompt, run jsl -install to install the module as a service

7. Start the service from windows service console

8. To remove the sevice from console, stop the service and then run jsl -remove

9. To test before install, run jsl -debug or jsl -run

OpenCMIS Class Loading Behavior

Ever tried OpenCMIS client in any web applications and observed performance issues with that. I did find that recently using OpenCMIS 0.4 version with my web application deployed in Tomcat 6. The issue I faced was classes loaded were kept on growing and looks like it was never garbage collected even after stopping that particular application. The free tool VisualVM was used to analyse this along with jmap and jhat utils from jdk 1.6 to see the strong references which never gets unreachable. With these tools it was clearly evident that even after redploying the particular web application, references of the loaded classes were not removed.

The in-depth analysis to the problem helped me to learn some nuances of class loading mechanism. Thanks to the problem and thought of sharing the same here.

Some reasons that could cause this problem:

1. Frequent offenders are scripting languages, dynamic proxies (including the ones generated by application servers)

2. Custom class loaders that don't carefully free up older classes after loading new ones

3. Also, Tomcat container holds the reference for the opencmis classes(specifically JAXB static references) and cleanup never happens. This cold be a limitation running CMIS code from JSP/Servlets.

4. Heavy use of Proxy classes, which are created during run time

5. Just like Hibernate, OpenCMIS creates and loads new classes on the fly at run time, and thus drawing heavily on the (possibly non-heap allocated) method area of the JVMs memory space. The behavior is expected in case of on the fly created classes. When application is not generating classes on the fly, the number of loaded classes and amount of permgen should be more or less static.


Finally, the solution which worked out in my case:

1. Added -XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC to JAVA_OPTS in catalina.bat
2. Replaced jaxb-impl2.2.1 wih version 2.2.3 jars jaxb-impl.jar and jaxb-api.jar

Other problem I have observed here is whenever the testui web application stopped from tomcat console, web application class loader does not unload CMIS JAXB classes because of which we see memory leak likely to happen message. Here we have not much control or it is not recommended to tweak the class loader functionality. Instead just stop and restart Tomcat.