wrong port used for xsd in wsdl (openesb)

the environment is openesb (with netbeans 6.5.1) and glassfish server.
when the composite app with bpel processes is deployed, the wsdls for the processes include wrong ports in imports of inner schema files (in this case, 8080 instead of 9080).
here is a description of the problem http://n2.nabble.com/Wrong-Port-Used-When-Generating-Web-Service-Client-td3388707.html and the issue https://open-esb.dev.java.net/issues/show_bug.cgi?id=2204
Actually, the issue had been solved in the internal trunk, however the solution won't be available till next release :(
so, what to do ??

the workaround is

• download the wsdls and all dependent schema files,
  
• edit all imports (of used schema files) manually and
  
• use the local wsdl in order to generate stubs at client side .
  

Thus, the stubs will be generated without any error :)

btw, deploying the business processes to apache ode is also tried. however, the same problem remained :(

converting java classes to schema: schemagen

schemagen tool comes with jaxb reference implementation and can be used to generate schemas from java classes. here is the command line version http://java.sun.com/webservices/docs/2.0/jaxb/schemagen.html and ant version https://jaxb.dev.java.net/jaxb20-ea/docs/schemagenTask.html When command line version is used, the names of the generated schema files are given automatically as schema1.xsd, schema2.xsd,.. etc. (one schema file per namespace). However, controlling names of files is possible when ant task is used, so i prefer using ant task.
Here is my sample schemagen ant file:

<?xml version="1.0" encoding="UTF-8"?>
<project name="projectname" default="generate-schema" basedir=".">

<path id="classpath">
<pathelement location="path/to/classes"/>
<fileset dir="/path/to/jaxb/lib">
<include name="**/*.jar"/>
</fileset>
</path>

<taskdef name="schemagen" classname="com.sun.tools.jxc.SchemaGenTask">
<classpath refid="classpath"/>
</taskdef>

<target name="generate-schema">
<schemagen srcdir="path/to/src" destdir="path/to/generatedfiles">
<classpath refid="classpath"/>
<schema namespace="http://namespace" file="nameOfMySchema.xsd" />
</schemagen>
</target>

</project>

However, if java classes contains jpa specific annotations, the apt tool could not handle this and throw annotation specific exceptions when the lib coming with jaxb ri is used in the classpath.
Annotations for Persistence part on http://www.devx.com/Java/Article/34069/0/page/1 solves this. download sample code on http://assets.devx.com/sourcecode/18778.zip and use the lib coming with the sample on path 18778/JAXB/lib. Actually, the above ant file is a simplified version of 18778/JAXB/3-JAXB and JPA/build.xml coming with the example..

So, it is ok for now :)

sharing same classes with multiple web services (jaxws)

Problem Definition:
In the default case all the class definitions under a web service are generated in the namespace of the web service. For instance let the web service endpoint SampleWS class is under package org.first and let this web service returns a org.second.SampleType. When the web service is deployed and stubs are generated in the client side, SampleType is also under org.first package. When org.second.SampleType is a shared class amongst multiple web services, this leads to problem, since there will be multiple SampleType classes under multiple packages.

Solution:
The specified problem could be solved at the client side by providing wsimport with a binding file specifying actual namespaces for all shared classes. https://jax-ws.dev.java.net/guide/Compiling_multiple_WSDLs_that_share_a_common_schema.html

However, it is also possible to solve the situation at server side by forcing to put all shared classes in their actual packages by adding namespace definition via XmlType annotation as follows:

import javax.xml.bind.annotation.XmlType;

@XmlType(namespace="http://org.example.hilal")
public class Calc {
private int result;

public int getResult() {
return result;
}

public void setResult(int result) {
this.result = result;
}
}

i prefer the second way, solving problems at server side always seems better to me :)

configuring service endpoint at runtime

i want to keep my generated stubs when the web service deployment point changes. here is how to configure service end point at runtime: http://tugdualgrall.blogspot.com/2009/02/jax-ws-how-to-configure-service-end_17.html
i prefer the second method:

org.me.calculator.CalculatorWSService service = new org.me.calculator.CalculatorWSService(
new URL("http://10.1.70.59:9080/CalculatorApp/CalculatorWSService?wsdl"), new QName("http://calculator.me.org/", "CalculatorWSService"));

org.me.calculator.CalculatorWS port = service.getCalculatorWSPort();


link to an article about wsdl styles

Actually, wsdl styles always make my mind confused. i think this article helped me understand, so lets note it down:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/