Migration J2EE Applications from OC4J to Weblogic Part -2

In continuation of the  Previous- part lets move ahead with the migration to weblogic. 

Microsoft-SQL database JTDS driver.

To use JTDS driver set the driver Jar in weblogic classpath, update %WLS_HOME%\wlserver_10.3\common\bin\commEnv.cmd. Append the value "%WL_HOME%\server\lib\jtds-1.2.4.jar" to the line starts with

set WEBLOGIC_CLASSPATH

JMS-JNDI Locations

Use the name defined in the remote JNDI field in the definition of the queue and queue connection factory; the remote JNDI doesn't accept colon like Java:Comp

Example: Change java:comp/resource/TEST_AQ/Queues/TESTQUEUE to Queues/TESTQUEUE, which is the defined remote JNDI URL of the queue in weblogic JMS configuration.

Stax library LinkageError Exception

An existing library stax-api-1.0.1.jar included in the application’s WEB-INF/lib

contains a class javax.xml.namespace.QName that conflicts with an already

loaded class in the System class loader. The implementation of this class is

provided by SUN. This is the error message we may encounter.

Caused by: java.lang.LinkageError: loader constraint violation: when resolving field

"DATETIME" the class loader (instance of

weblogic/utils/classloaders/ChangeAwareClassLoader) of the resolved type,

javax/xml/namespace/QName, have different Class objects for that type

Issue is resolved by removing this library from the application. The maven pom file was

updated to remove/exclude the following dependencies:

• stax:stax-api
• javax.xml.stream:stax-api (This API is now part of Java 6)

JAX-RPC XSD Upgrade

In our project we had lot of JAX-RPC web-services but those were not upgraded to JAX-WS but were migrated as JAX-RPC it self, these were the issues which we ran into.
Defecto recommendation is to upgrade to JAX-WS, if there is absolutely no alternative then embark on upgrading JAX-RPX to weblogic.

Definition of Inline -XSD'S

Inline definition of complex types is not supported by weblogic, when the complex type contains other simple types.Due to this weblogic server throws binding error during deployment.

Once we change this then we need to regenerate the web-service in the JDeveloper project, the only difference is in the mapping file. The JAVA types are still the same, replace the mapping file in the project  with the new mapping file and off you go. Some time you may need to edit the mapping file to adjust the package names.

XSD Definition for Simple Types.

XSD simple type elements with max occurrence more than one is not supported by weblogic server, this element should be wrapped in another complex type,

check out this link. Not able to figure out a work-around for this. Proceed with the max-occurs attribute, while deployment weblogic throws an exception but the code works, so it may be ignored.

Web-service Fault Types and Operation Types

When WSDL Operation fault type is defined of the same complex type as of the Operation input or return, the following error is thrown in JDeveloper during webservice generation time

oracle.jdeveloper.webservices.model.WebServiceException: WSDLException: faultCode=INVALID_WSDL: Declared fault Type {http://impl.bpel.service.declaration.customs.pcfc.com/types/}UpdateIncidentExceptionType is already referenced as either input or return type at oracle.jdeveloper.webservices.model.java.JavaWebService.createPortTypes(JavaWebService.java:1635) at oracle.jdeveloper.webservices.model.WebService.createServiceFromWSDL(WebService.java:2846) at oracle.jdeveloper.webservices.model.WebService.createServiceFromWSDL(WebService.java:2611)

Please find an Example

<portType name="DeclarationUpdate">  

  <operation name="raiseUpdateIncidentException">  

  <input message="tns:DeclarationUpdate_raiseUpdateIncidentException"/>  

  <output message="tns:DeclarationUpdate_raiseUpdateIncidentExceptionResponse"/> 

  <fault name="UpdateIncidentExceptionType"          message="tns:UpdateIncidentExceptionType"/>  

  </operation>  

  </portType 

A new complex type: UpdateIncidentExceptionTypeRequest similar to UpdateIncidentExceptionType was created for the input parameter to the web service operation raiseUpdateIncidentException. This input parameter is no longer a wrapperof the fault type.

This allowed the web service method to have input and fault parameters of different types.

 <portType name="DeclarationUpdate">   

 <operation name="raiseUpdateIncidentException">   

 <input message="tns:DeclarationUpdate_raiseUpdateIncidentException"/>   

 <output message="tns:DeclarationUpdate_raiseUpdateIncidentExceptionResponse"/>    <fault name="UpdateIncidentExceptionType" message="tns:UpdateIncidentExceptionType"/>  

 </operation>  

 </portType>  

BPEL WSDL Proxy Cretion

While testing the generated BPEL Process’s Client Proxy, a Runtime exception was encountered, although we specified  the correct endpoint URL of the BPEL process deployed on the Server. This issue applies to all BPEL processes.

See the example below where in which BPEL process's WSDL contains the partner link element:

 <partnerLinkType>   

 <partnerLinkType name="ProcessBOE_BPEL">  

  <role name="ProcessBOE_BPELProvider">  

  <portType name="ProcessBOE_BPEL" />   

 </role> </partnerLinkType  

This partnerlink element should be removed from the WSDL at the Client Proxy’s end to successfully test and use the proxy. This means that the WSDL found only in the Client Proxy project should be updated with this change. The WSDL which is deployed on the Server with the BPEL Process should not be updated