Bug report for Axis [2002/03/10]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal EHN=Ehnancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | +-+---+---+--+--+ | Total1 bugs | +---+
Bug report for Axis [2002/03/17]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal EHN=Ehnancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | | 7049|New|Nor|2002-03-12|Invalid code generated by WSDL2Java | | 7071|Ass|Maj|2002-03-13|Concurrency Problem in Axis engine with Applicatio| | 7132|New|Nor|2002-03-14|Attributes object does not contain all attributes | | 7133|Ass|Blk|2002-03-14|invoke does not return a value using rc1 and rc2. | +-+---+---+--+--+ | Total5 bugs | +---+
DO NOT REPLY [Bug 7270] New: - Error when mapping Arrays to Collections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7270>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7270
Error when mapping Arrays to Collections
Summary: Error when mapping Arrays to Collections
Product: Axis
Version: beta-1
Platform: PC
URL: http://www.silbergrau.com
OS/Version: Windows NT/2K
Status: NEW
Severity: Blocker
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Remote method takes a Collection as argument and returns a Collection.
Type of parameter sent is "xsd:anyType[3]" and contains 3 TypeA arguments
(Note that this there could be types extending TypeA in there!)
Seems that AXIS tries to map this to Object[] altough parameter is Collection:
"java.lang.IllegalArgumentException: argument type mismatch on object
"com.silbergrau.services.providers.tests.services.TestService",
method name "passThroughCollection", tried argument types:
[Ljava.lang.Object;"
TYPES:
--
public class TypeA {
private TypeA reference;
}
public class TypeB extends TypeA {
}
Remote method = Collection passThroughCollection(Collection collection)
REQUEST ENVELOPE:
-
Collection c = new ArrayList();
c.add(new TypeA());
c.add(new TypeA());
c.add(new TypeA());
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:soap-
env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:soap-
enc12="http://www.w3.org/2001/06/soap-encoding";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:silbergrauSoapExtensions="http://www.silbergrau.com/soap/extensions";>
http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="soap-enc11:Array" id="5" soap-enc11:arrayType="xsd:anyType[3]">
http://www.silbergrau.com/schemas/encodedTypes";>
http://www.silbergrau.com/schemas/encodedTypes";>
http://www.silbergrau.com/schemas/encodedTypes";>
RESPONSE ENVELOPE
-
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:soap-
env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:soap-
enc12="http://www.w3.org/2001/06/soap-encoding";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:silbergrauSoapExtensions="http://www.silbergrau.com/soap/extensions";>
http://xml.apache.org/axis/";>ns1:Server.userException
java.lang.IllegalArgumentException: argument type mismatch
on object
"com.silbergrau.services.providers.tests.services.TestService",
method name "passThroughCollection", tried argument types:
[Ljava.lang.Object;
http://xml.apache.org/axis/";>java.lang.IllegalArgumentException:
argument type mismatch on object
"com.silbergrau.services.providers.tests.services.TestService",
method name "passThroughCollection", tried argument types:
[Ljava.lang.Object;
at org.apache.axis.providers.java.RPCProvider.processMessage(Unknown
Source)
at org.apache.axis.providers.java.JavaProvider.invoke(Unknown Source)
at org.apache.axis.strategies.InvocationStrategy.visit(Unknown Source)
at org.apache.axis.SimpleChain.doVisiting(Unknown Source)
at org.apache.axis.SimpleChain.invoke(Unknown Source)
at org.apache.axis.server.AxisServer.invoke(Unknown Source)
at org.apache.axis.transport.http.AxisServlet.doPost(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext
(Stand
DO NOT REPLY [Bug 7268] New: - Responses no not declare correct EncodingStyles
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7268>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7268
Responses no not declare correct EncodingStyles
Summary: Responses no not declare correct EncodingStyles
Product: Axis
Version: beta-1
Platform: PC
URL: http://www.silbergrau.com
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
SOAP Specification on Encoding Styles (4.1.1):
"[...] This attribute MAY appear on any element, and is scoped
to that element's contents and all child elements not themselves
containing such an attribute, much as an XML namespace declaration
is scoped. There is no default encoding defined for a SOAP message. [...]"
When AXIS sends back a response it does not provide correct encoding styles
for referenced elements. The example below shows a testcase for such a call.
Actually you could guess the encoding style from the reference, however, there
may be more references to this element that are within different encoding
styles!
More important is that you CAN NOT determine wether the element has
id "id0" if you do not know the encoding style of this element, since this is
defined in the encoding style (encoding styles different from the soap encoding
style may define identifier attributes different to "id")!
TYPES:
--
public class TypeA {
private TypeA reference;
}
Remote method = TypeA passThroughTypeA(TypeA a)
REQUEST ENVELOPE:
-
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:soap-
env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:soap-
enc12="http://www.w3.org/2001/06/soap-encoding";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:silbergrauSoapExtensions="http://www.silbergrau.com/soap/extensions";>
http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="ns3:TypeA" id="1"
xmlns:ns3="http://www.silbergrau.com/schemas/encodedTypes";>
RESPONSE ENVELOPE
-
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns1="TestService">
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns2="http://www.silbergrau.com/schemas/encodedTypes";>
DO NOT REPLY [Bug 7269] New: - Empty ID attributes in responses
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7269>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7269
Empty ID attributes in responses
Summary: Empty ID attributes in responses
Product: Axis
Version: beta-1
Platform: PC
URL: http://www.silbergrau.com
OS/Version: Windows NT/2K
Status: NEW
Severity: Blocker
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
The following case shows a request and response where
the response references elements that do not exists.
Actually the element exist, but it has an empty ID attribute!
Note: This seems to happen whenever AXIS is sending a subclass
of the Type described. In the testcase the method takes a parameter
of TypeA but actual type sent is TypeB.
TYPES:
--
public class TypeA {
private TypeA reference;
}
public class TypeB extends TypeA {
}
Remote method = TypeA passThroughTypeA(TypeA a)
REQUEST ENVELOPE:
-
TypeA a = new TypeA();
TypeA b = new TypeB();
a.setReference(b);
b.setReference(null);
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:soap-
env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:soap-
enc12="http://www.w3.org/2001/06/soap-encoding";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:silbergrauSoapExtensions="http://www.silbergrau.com/soap/extensions";>
http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="ns3:TypeA" id="4"
xmlns:ns3="http://www.silbergrau.com/schemas/encodedTypes";>
RESPONSE ENVELOPE
-
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns1="TestService">
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns2="http://www.silbergrau.com/schemas/encodedTypes";>
http://www.silbergrau.com/schemas/encodedTypes"; xmlns:SOAP-
ENC="http://schemas.xmlsoap.org/soap/encoding/";>
DO NOT REPLY [Bug 7267] New: - Null Values in Envelope are not correct
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7267>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7267 Null Values in Envelope are not correct Summary: Null Values in Envelope are not correct Product: Axis Version: beta-1 Platform: PC URL: http://www.silbergrau.com OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] SOAP Specification (5.1): "A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:null with value '1' or possibly other application-dependent attributes and values." AXIS describes null values with the value "true" instead of "1". AXIS uses "xsi:nil" instead of "xsi:null". EXAMPLE:
DO NOT REPLY [Bug 7296] New: - deploy.wsdd for the stock sample gives false information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296 deploy.wsdd for the stock sample gives false information Summary: deploy.wsdd for the stock sample gives false information Product: Axis Version: beta-1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7296] - deploy.wsdd for the stock sample gives false information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296 deploy.wsdd for the stock sample gives false information --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 19:28 --- ... In that the header comments read
DO NOT REPLY [Bug 7298] New: - (Documentation) Installation guide does not state how to start AXIS service
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7298>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7298 (Documentation) Installation guide does not state how to start AXIS service Summary: (Documentation) Installation guide does not state how to start AXIS service Product: Axis Version: beta-1 Platform: All URL: http://cvs.apache.org/viewcvs.cgi/~checkout~/xml- axis/java/docs/install.html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Step 4 (?) of the Installation Guide should state how to start the axis service. IE "To start the Axis service, browse to: http://hostname:8080/axis/index.html Hit the link to "Administer Axis" to reach the Admin Servlet which allows you to start and stop the Service." This would ease installation and deployment of the samples.
DO NOT REPLY [Bug 7311] New: - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code Summary: WSDL2Java generates wrong code Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] WSDL2Java has a problem if a WSDL was generated from a Java class that has a method that declares "throws Exception". In that case, WSDL2Java generates code for an Exception class in the specified package but then generates in the constructor of the SoapBindingStub a "catch Exception" instead of "catch java.lang.Exception" and that results in a "Exception never thrown" compiler error.
DO NOT REPLY [Bug 7314] New: - Axis client should be able to do basic HTTP authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314 Axis client should be able to do basic HTTP authentication Summary: Axis client should be able to do basic HTTP authentication Product: Axis Version: beta-1 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] See summary.
DO NOT REPLY [Bug 7373] New: - HTTPSender does not support HTTPS through an Auth. Proxy
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7373>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7373
HTTPSender does not support HTTPS through an Auth. Proxy
Summary: HTTPSender does not support HTTPS through an Auth. Proxy
Product: Axis
Version: beta-1
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
HTTPSender needs to supply the Proxy-Authorization String when connecting to an
Authenticating proxy when doing HTTPS.
Consider changing:
out.print("CONNECT " + host + ":" + port + " HTTP/1.0\n"
+ "User-Agent: AxisClient"
+ "\r\n\r\n");
To:
String tunnelUser = System.getProperty("https.proxyUser");
String tunnelPassword = System.getProperty("https.proxyPassword");
if (tunnelUser == null) tunnelUser =
System.getProperty("http.proxyUser");
if (tunnelPassword == null) tunnelPassword =
System.getProperty("http.proxyPassword");
String msg = "CONNECT " + host + ":" + port + " HTTP/1.0\n"
+ "User-Agent: AxisClient";
if (tunnelUser != null && tunnelPassword != null) {
//add basic authentication header for the proxy
sun.misc.BASE64Encoder enc = new sun.misc.BASE64Encoder();
String encodedPassword =
enc.encode((tunnelUser + ":" + tunnelPassword).getBytes());
msg = msg + "\nProxy-Authorization: Basic " + encodedPassword;
}
msg = msg + "\nContent-Length: 0";
msg = msg + "\nPragma: no-cache";
msg = msg + "\r\n\r\n";
out.print(msg);
Or even better lookup the UserName and Password from the java.net.Authenticator
class instead of System Properties (more secure, cant see password with a ps)
PasswordAuthentication pa =
Authenticator.requestPasswordAuthentication(
InetAddress.getByName(tunnelHost),
tunnelPort, "SOCK", "Proxy","HTTP");
if(pa == null){
printDebug("No Authenticator set.");
}else{
printDebug("Using Authenticator.");
tunnelUserName = pa.getUserName();
tunnelPassword = new String(pa.getPassword());
}
DO NOT REPLY [Bug 7407] New: - Please include the wsdl2java and java2wsdl Ant tasks in the binary
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7407>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7407 Please include the wsdl2java and java2wsdl Ant tasks in the binary Summary: Please include the wsdl2java and java2wsdl Ant tasks in the binary Product: Axis Version: beta-1 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The ant tasks used to create wsdl from java and vice versa would be great in any ant based build process of client and server code. But these tasks are only found in the source in the test package, not documented and not found in the binary distros. I would suggest -move them somewhere in the axis package heirarchy -do some basic documentation; there is some work in ant's sandbox to use xdoclet to do this -mention them in the user guide -include in the binary distribution. Ta, -steve
Bug report for Axis [2002/03/24]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal EHN=Ehnancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | | 7049|New|Nor|2002-03-12|Invalid code generated by WSDL2Java | | 7071|Ass|Maj|2002-03-13|Concurrency Problem in Axis engine with Applicatio| | 7132|Ass|Nor|2002-03-14|Attributes object does not contain all attributes | | 7133|Ass|Blk|2002-03-14|invoke does not return a value using rc1 and rc2. | | 7267|New|Min|2002-03-20|Null Values in Envelope are not correct | | 7268|New|Maj|2002-03-20|Responses no not declare correct EncodingStyles | | 7269|New|Blk|2002-03-20|Empty ID attributes in responses | | 7270|New|Blk|2002-03-20|Error when mapping Arrays to Collections | | 7296|New|Nor|2002-03-20|deploy.wsdd for the stock sample gives false infor| | 7298|New|Nor|2002-03-20|(Documentation) Installation guide does not state | | 7311|New|Nor|2002-03-21|WSDL2Java generates wrong code| | 7314|New|Enh|2002-03-21|Axis client should be able to do basic HTTP authen| | 7373|New|Nor|2002-03-22|HTTPSender does not support HTTPS through an Auth.| | 7407|New|Enh|2002-03-24|Please include the wsdl2java and java2wsdl Ant tas| +-+---+---+--+--+ | Total 15 bugs | +---+
DO NOT REPLY [Bug 7467] New: - Warnings when tomcat loads axis caused by errors in web.xml URL patterns for servlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7467>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7467
Warnings when tomcat loads axis caused by errors in web.xml URL patterns for servlets
Summary: Warnings when tomcat loads axis caused by errors in
web.xml URL patterns for servlets
Product: Axis
Version: beta-1
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Deployment / Registries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
The axis web.xml file does not use the required forward slash ('/') at the
beginning of the servlet URL pattern. The following warning messages appear in
the Tomcat log file:
2002-03-25 12:26:15 StandardContext[/axis]: WARNING: URL pattern
servlet/AxisServlet must start with a / in Servlet 2.3
2002-03-25 12:26:15 StandardContext[/axis]: WARNING: URL pattern
servlet/AdminServlet must start with a / in Servlet 2.3
DO NOT REPLY [Bug 7469] New: - axis servlet throws load() exception on Tomcat startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7469>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7469 axis servlet throws load() exception on Tomcat startup Summary: axis servlet throws load() exception on Tomcat startup Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] When you start up Tomcat with axis in the webapps directory, the following error appears in the Tomcat log. Note that I have other versions of xerces in the web server, but the axis installation page says that it is okay to have other versions of the same xml parser. 2002-03-25 12:26:16 StandardContext[/axis]: Servlet /axis threw load() exception javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception at org.apache.catalina.core.StandardWrapper.load(Unknown Source) at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.install(Unknown Source) at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source) at org.apache.catalina.startup.HostConfig.start(Unknown Source) at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardHost.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) - Root Cause - java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance (DocumentBuilderFactory.java:103) at org.apache.jasper.parser.ParserUtils.parseXMLDocument(Unknown Source) at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml (Unknown Source) at org.apache.jasper.compiler.TldLocationsCache.(Unknown Source) at org.apache.jasper.EmbededServletOptions.(Unknown Source) at org.apache.jasper.servlet.JspServlet.init(Unknown Source) at org.apache.catalina.core.StandardWrapper.load(Unknown Source) at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.addChild(Unknown Source) at org.apache.catalina.core.StandardHost.install(Unknown Source) at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source) at org.apache.catalina.startup.HostConfig.start(Unknown Source) at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardHost.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source)
DO NOT REPLY [Bug 7494] New: - Incorrect Serialization of Complex Type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494 Incorrect Serialization of Complex Type Summary: Incorrect Serialization of Complex Type Product: Axis Version: beta-1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Fields are being serialized with incorrect casing. Note the field Name is coming across as name. This is with a simple service using the default BeanSerializer via the node. The response packet looks like: http://schemas.xmlsoap.org/soap/encoding/"; xmlns:ns1="http://127.0.0.1:8080/axis/services/CustomerService";> http://schemas.xmlsoap.org/soap/encoding/"; xmlns:ns2="CustomerService"> Hello
DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code --- Additional Comments From [EMAIL PROTECTED] 2002-03-27 20:26 --- I experienced the same exact problem.
DO NOT REPLY [Bug 7536] New: - Incorrect session timeout logic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7536>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7536 Incorrect session timeout logic Summary: Incorrect session timeout logic Product: Axis Version: beta-1 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] org.apache.axis.handlers.SimpleSessionHandler incorrectly determines whether or not a session has timed out. On line 161, the ">" should be a "<": if ((session.getTimeout() * 1000) > (curTime - session.getLastAccessTime())) should be if ((session.getTimeout() * 1000) < (curTime - session.getLastAccessTime()))
DO NOT REPLY [Bug 7536] - Incorrect session timeout logic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7536>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7536 Incorrect session timeout logic [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 03:15 --- Damn - nice catch! Our test wasn't catching this because setDefaultSessionTimeout() wanted seconds, and I was giving it a value as if it wanted milliseconds (i.e. the timeout was HUGE). So of course the ">" worked. This has been fixed and the test updated. Thanks!
DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 06:44 --- Created an attachment (id=1439) task to get wsdl of nagoya, generate the java then compile it
DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Major --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 06:44 --- I am going to add my voice to encountering this, with the extra pointer that one of the services which exhibits this problem is the sample StockQuoteService which ships with Axis. so, you have everything at hand to test it. I am about to attach an ant task which exhibits this problem; run it in a dir where lib/ contains all the axis stuff and an XML parser. Ant's testcases directories includes a class (BuildFileTest) to help calling ant tasks from junit tests; you may want to use a bit of it to run this sample build as part of your unit tests from now on. NB, the workaround for beta-1 developers is to use on the generated java file to patch up the java source before building.
DO NOT REPLY [Bug 7557] New: - when using simpleType, wsdd type mapping is not interpreted correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557
when using simpleType, wsdd type mapping is not interpreted correctly
Summary: when using simpleType, wsdd type mapping is not
interpreted correctly
Product: Axis
Version: beta-1
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
in my schema definition i use my own simple types to wrap arround schema
tpes like long, etc.
wsdl2java generates type mappings for each of these simple types:
e.g. customerID to java:long :
qname="ns:customerID"
type="java:long"
whith this i get an ClassNotFoundException in
org.apache.axis.deployment.wsdd.WSDDTypeMapping, method
getLanguageSpecificType(), line 230 which is rethrown
as WSDDException in org.apache.axis.deployment.wsdd.WSDDService, method
deployTypeMapping, line 405
I get this when calling the service the fisrt time
the problem seems to be that method getLanguageSpecificType()
tries to load a Class even if typeQName.getLocalPart() contains the name
of a primitive java type.
as a workarround i inserted the following coding into method
getLanguageSpecificType() at line 229:
java.util.Map primitiveTypes = new java.util.HashMap();
primitiveTypes.put("boolean", boolean.class );
primitiveTypes.put("double", double.class );
primitiveTypes.put("float", float.class );
primitiveTypes.put("int", int.class );
primitiveTypes.put("long", long.class );
primitiveTypes.put("short", short.class );
primitiveTypes.put("byte", byte.class );
Class primClass =
in my schema definition i use my own simple types to wrap arround schema
tpes like long, etc.
wsdl2java generates type mappings for each of these simple types:
e.g. customerID to java:long :
qname="ns:customerID"
type="java:long"
whith this i get an ClassNotFoundException in
org.apache.axis.deployment.wsdd.WSDDTypeMapping, method
getLanguageSpecificType(), line 230 which is rethrown
as WSDDException in org.apache.axis.deployment.wsdd.WSDDService, method
deployTypeMapping, line 405
I get this when calling the service the fisrt time
the problem seems to be that method getLanguageSpecificType()
tries to load a Class even if typeQName.getLocalPart() contains the name
of a primitive java type.
as a workarround i inserted the following coding into method
getLanguageSpecificType() at line 229:
java.util.Map primitiveTypes = new java.util.HashMap();
primitiveTypes.put("boolean", boolean.class );
primitiveTypes.put("double", double.class );
primitiveTypes.put("float", float.class );
primitiveTypes.put("int", int.class );
primitiveTypes.put("long", long.class );
primitiveTypes.put("short", short.class );
primitiveTypes.put("byte", byte.class );
Class primClass =
(Class) primitiveTypes.get( typeQName.getLocalPart() );
if ( primClass != null ) {
return primClass;
}
with this workarround it works
the wsdl i currently use is very complex, because it imports serveral schema
definition files ( not wsdl files ), so i didn't attach it.
if you need an wsdl-example pls. email me. i will try to reproduce the error
then with a simpler example, because i think the problem is not the schema
includes but the use of simple types as wrappers to other sinple types like
xsd:long
DO NOT REPLY [Bug 7560] New: - Sample: EchoAttachments File comparison aggressively suboptimal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7560>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7560 Sample: EchoAttachments File comparison aggressively suboptimal Summary: Sample: EchoAttachments File comparison aggressively suboptimal Product: Axis Version: beta-1 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you are comparing two files for equality, as EchoAttachments.compareFiles does, it is worth noting that if the two file lengths are different then the files dont match, saving testing byte by byte, which matters if you are testing handling of very large large files. (ps, there is no category for 'samples', I would have used it otherwise)
DO NOT REPLY [Bug 7557] - when using simpleType, wsdd type mapping is not interpreted correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557 when using simpleType, wsdd type mapping is not interpreted correctly --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 08:18 --- Created an attachment (id=1440) simple WSDL testcase to reproduce the error ( use wsdl2java ) to get wsdd
DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 13:38 --- I've fixed the compilation error, which should get you past the immediate problem. Since that's what this bug was about, I'll mark it as fixed. But I suspect there may be a roundtripping problem waiting in the wings, so if you find runtime problems with Java methods that throw java.lang.Exception, please reopen the bug. Personally, it's poor programming practice to catch java.lang.Exception. It rather defeats the purpose of Java explicitly requiring you to list the exceptions a method may throw.
DO NOT REPLY [Bug 7577] New: - [wsdl2java] - Impl class do not compile when having array inout parameters.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7577>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7577
[wsdl2java] - Impl class do not compile when having array inout parameters.
Summary: [wsdl2java] - Impl class do not compile when having
array inout parameters.
Product: Axis
Version: beta-1
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
(as of Marc 25th 2002)
The generated code has parenthesis at the end of the creation of the object.
As in:
page.value = new java.lang.String[]();
while they should be curly braces:
page.value = new java.lang.String[]{};
DO NOT REPLY [Bug 7494] - Incorrect Serialization of Complex Type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494 Incorrect Serialization of Complex Type [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Major Priority|Other |High
DO NOT REPLY [Bug 7601] New: - [Security] generated .class files can be downloaded on tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7601>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7601 [Security] generated .class files can be downloaded on tomcat Summary: [Security] generated .class files can be downloaded on tomcat Product: Axis Version: beta-1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The generated class files from JWS pages can be downloaded if you ask for them http://localhost:8080/axis/SearchService.class ...the web.xml needs to be set up to prevent access to *.class files.
DO NOT REPLY [Bug 7612] New: - Java2WSDL does not work in some cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612 Java2WSDL does not work in some cases Summary: Java2WSDL does not work in some cases Product: Axis Version: beta-1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 1. when namespace (target name space) has dash such as urn:my-service, java2wsdl simply print out usage instead of generate the WSDL 2. SoapAction is blank, the produced soapAction="" instead of the urn. 3. It does not work with EJB Object
DO NOT REPLY [Bug 7621] New: - [wsdl2java] - Name conflict with java.lang.Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7621>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7621 [wsdl2java] - Name conflict with java.lang.Exception Summary: [wsdl2java] - Name conflict with java.lang.Exception Product: Axis Version: beta-1 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the Wsdl2Java generated code includes a custom "Exception" class, there is a name conflict in catch blocks of the getCall() method of the generated SoapBindingStub class. In particular, the (catch Exception t) resolves to the generated package's Exception, not java.lang.Exception as expected. This should be easy to fix by using the fully qualified name java.lang.Exception in the generated code.
DO NOT REPLY [Bug 7621] - [wsdl2java] - Name conflict with java.lang.Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7621>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7621 [wsdl2java] - Name conflict with java.lang.Exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-03-29 21:22 --- *** This bug has been marked as a duplicate of 7311 ***
DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7311 WSDL2Java generates wrong code [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-03-29 21:22 --- *** Bug 7621 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 7625] New: - getPrefixes method in XMLUtils should be public
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7625>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7625
getPrefixes method in XMLUtils should be public
Summary: getPrefixes method in XMLUtils should be public
Product: Axis
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Basic Architecture
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
on the 2002/03/28 nightly build.
in org.apache.axis.utils.XMLUtils.java:
private static Hashtable getPrefixes(Document d) {}
It is a utility method. Unless it exposes something bad, it should probably
be public. It seemed odd that related methods (eg getNewPrefix) are
public and this is not
At the least, getPrefix() and getNamespace() in XMLUtils should be re-
factored to actually use getPrefixes(), which would make sense,
especially if you were caching the Hashtable for performance.
Bug report for Axis [2002/03/31]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | | 7071|Ass|Maj|2002-03-13|Concurrency Problem in Axis engine with Applicatio| | 7132|Ass|Nor|2002-03-14|Attributes object does not contain all attributes | | 7133|Ass|Blk|2002-03-14|invoke does not return a value using rc1 and rc2. | | 7267|New|Min|2002-03-20|Null Values in Envelope are not correct | | 7268|New|Maj|2002-03-20|Responses no not declare correct EncodingStyles | | 7269|New|Blk|2002-03-20|Empty ID attributes in responses | | 7270|New|Blk|2002-03-20|Error when mapping Arrays to Collections | | 7296|New|Nor|2002-03-20|deploy.wsdd for the stock sample gives false infor| | 7298|New|Nor|2002-03-20|(Documentation) Installation guide does not state | | 7314|New|Enh|2002-03-21|Axis client should be able to do basic HTTP authen| | 7373|New|Nor|2002-03-22|HTTPSender does not support HTTPS through an Auth.| | 7407|New|Enh|2002-03-24|Please include the wsdl2java and java2wsdl Ant tas| | 7467|New|Nor|2002-03-25|Warnings when tomcat loads axis caused by errors i| | 7469|New|Nor|2002-03-26|axis servlet throws load() exception on Tomcat sta| | 7494|New|Maj|2002-03-26|Incorrect Serialization of Complex Type | | 7557|New|Nor|2002-03-28|when using simpleType, wsdd type mapping is not in| | 7560|New|Enh|2002-03-28|Sample: EchoAttachments File comparison aggressive| | 7577|New|Nor|2002-03-28|[wsdl2java] - Impl class do not compile when havin| | 7601|New|Nor|2002-03-29|[Security] generated .class files can be downloade| | 7612|New|Nor|2002-03-29|Java2WSDL does not work in some cases | | 7625|New|Min|2002-03-29|getPrefixes method in XMLUtils should be public | +-+---+---+--+--+ | Total 22 bugs | +---+
DO NOT REPLY [Bug 7718] New: - JavaProvider WSDL generator does not allow inherited methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7718>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7718
JavaProvider WSDL generator does not allow inherited methods
Summary: JavaProvider WSDL generator does not allow inherited
methods
Product: Axis
Version: beta-1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Minor
Priority: Other
Component: Deployment / Registries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The Java2WSDL command-line tool allows you to specify if AXIS should use
inherited methods. The servlet does not allow you to specify this.
The following two lines (added to JavaProvider.java) allows for specifying the
behaviour in the .wsdd file:
Emitter emitter = new Emitter();
emitter.setMode(service.getStyle());
emitter.setClsSmart(cls,url);
emitter.setAllowedMethods(allowedMethods);
emitter.setIntfNamespace(url);
emitter.setLocationUrl(url);
+ String inherit = (String)service.getOption("allowInheritedMethods");
+ emitter.setUseInheritedMethods(Boolean.valueOf(inherit).booleanValue());
DO NOT REPLY [Bug 7722] New: - Extended interfaces do not show up in WSDL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7722>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7722
Extended interfaces do not show up in WSDL
Summary: Extended interfaces do not show up in WSDL
Product: Axis
Version: beta-1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Deployment / Registries
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Situation:
interface BaseInterface;
interface ExtendedInterface extends BaseInterface;
JavaProvider uses the ExtendedInterface as a class, useInheritedMethods is set
to true. The methods in the BaseInterface do not show up in the WSDL.
Solution:
in ClassRep.java, the walkInheritanceChain() and addMethods() methods use
recursion, but only one level deep. The following one-liner fixes it:
// add methods from interfaces
Class[] interfaces = cls.getInterfaces();
for (int i=0; i < interfaces.length; i++) {
- walkInheritanceChain(interfaces[i], inhMethods, implClass);
+ addMethods(interfaces[i], inhMethods, implClass);
}
This makes sure that 'addMethods' is called recursive, instead of
calling 'walkInheritanceChain' recursive. The latter method only
supports 'getSuperClass()', while the addMethods() call will also consider
interfaces (and interfaces of interfaces).
As a side-note: The code in the init() method seems redundant (and useless
too). The gathered list of interfaces and superclasses is never used, and
because the ClassRep constructor is called recursively, it loses that
information (_interfaces and _methods are members of ClassRep).
DO NOT REPLY [Bug 7743] New: - WSDL2Java does not implement hashCode methods on all classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743 WSDL2Java does not implement hashCode methods on all classes Summary: WSDL2Java does not implement hashCode methods on all classes Product: Axis Version: beta-1 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] WSDL2Java should implement hashCode generation for all of the generated classes since all fields of generated classes are of defined type derived from the XMLSchema primitive types implementing hashCode as a combination of individual field hashCodes should be possible.
DO NOT REPLY [Bug 7744] New: - WSDL2Java does not work properly if xsd:import is used
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7744>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7744 WSDL2Java does not work properly if xsd:import is used Summary: WSDL2Java does not work properly if xsd:import is used Product: Axis Version: beta-1 Platform: Sun OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Schema inclusion (as opposed to wsdl inclusion) results in undefined types, e.g. http://my.namespace/foo"; location="http://my.wwwserver/foo.xsd";> fails to define WSDL types for types defined in the imported schema. Since WSDL2Java uses the XMLUtils DOM reader which does not enable Xerces schema validation, the Xerces parser does not interpret this directive. If WSDL2Java is changed to enable this feature, the schema is read correctly but the corresponding datatypes are not defined. If the same schema is then the types are defined correctly. The same problem occurs for xsi:schemaLocation directives. If this behaviour is intentional, the reasoning should be documented as it is not intuitative
DO NOT REPLY [Bug 7745] New: - Feature Req: WSDL2Java should generate validity checks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7745>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7745 Feature Req: WSDL2Java should generate validity checks Summary: Feature Req: WSDL2Java should generate validity checks Product: Axis Version: beta-1 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For complex types containing and et al then the generated java file should export a method to check that these constraints have been fulfilled. e.g. should generate a boolean XMLConstraintsValid() method which returns true only if both the userId and password have been set. Additional optional methods could return the list of failed constraints.
Bug report for Axis [2002/04/07]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | | 7071|Ass|Maj|2002-03-13|Concurrency Problem in Axis engine with Applicatio| | 7132|Ass|Nor|2002-03-14|Attributes object does not contain all attributes | | 7133|Ass|Blk|2002-03-14|invoke does not return a value using rc1 and rc2. | | 7267|New|Min|2002-03-20|Null Values in Envelope are not correct | | 7268|New|Maj|2002-03-20|Responses no not declare correct EncodingStyles | | 7269|New|Blk|2002-03-20|Empty ID attributes in responses | | 7270|New|Blk|2002-03-20|Error when mapping Arrays to Collections | | 7296|New|Nor|2002-03-20|deploy.wsdd for the stock sample gives false infor| | 7298|New|Nor|2002-03-20|(Documentation) Installation guide does not state | | 7314|New|Enh|2002-03-21|Axis client should be able to do basic HTTP authen| | 7373|New|Nor|2002-03-22|HTTPSender does not support HTTPS through an Auth.| | 7407|New|Enh|2002-03-24|Please include the wsdl2java and java2wsdl Ant tas| | 7467|New|Nor|2002-03-25|Warnings when tomcat loads axis caused by errors i| | 7469|New|Nor|2002-03-26|axis servlet throws load() exception on Tomcat sta| | 7494|New|Maj|2002-03-26|Incorrect Serialization of Complex Type | | 7557|New|Nor|2002-03-28|when using simpleType, wsdd type mapping is not in| | 7560|New|Enh|2002-03-28|Sample: EchoAttachments File comparison aggressive| | 7577|New|Nor|2002-03-28|[wsdl2java] - Impl class do not compile when havin| | 7601|New|Nor|2002-03-29|[Security] generated .class files can be downloade| | 7612|New|Nor|2002-03-29|Java2WSDL does not work in some cases | | 7625|New|Min|2002-03-29|getPrefixes method in XMLUtils should be public | | 7718|New|Min|2002-04-03|JavaProvider WSDL generator does not allow inherit| | 7722|New|Nor|2002-04-03|Extended interfaces do not show up in WSDL| | 7743|New|Maj|2002-04-04|WSDL2Java does not implement hashCode methods on a| | 7744|New|Cri|2002-04-04|WSDL2Java does not work properly if xsd:import is | | 7745|New|Nor|2002-04-04|Feature Req: WSDL2Java should generate validity ch| +-+---+---+--+--+ | Total 27 bugs | +---+
DO NOT REPLY [Bug 7494] - Incorrect Serialization of Complex Type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7494 Incorrect Serialization of Complex Type [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 16:11 --- I just tried using capitalized element names today (April 8) and it works, so this appears to have been fixed.
DO NOT REPLY [Bug 7744] - WSDL2Java does not work properly if xsd:import is used
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7744>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7744 WSDL2Java does not work properly if xsd:import is used [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 17:35 --- This has now been fixed. I think. If it still fails for you, please provide us with a failing WSDL that we can use for a test case.
DO NOT REPLY [Bug 7856] New: - using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856 using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url Summary: using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On the client side, if I want to change the target URL in a header processor, I will probably use call.setTargetEndpointAddress(newURL). But the request message is still sent to the old URL. Apparently, HTTPSender is using MessageContext's TARNS_URL property to send the message and setTargetEndpointAddress does not change it. Currently in my application, I am directly changing the TRANS_URL property to change the target URL (and that works). java full version "1.3.1_01"
DO NOT REPLY [Bug 7577] - [wsdl2java] - Impl class do not compile when having array inout parameters.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7577>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7577 [wsdl2java] - Impl class do not compile when having array inout parameters. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 23:22 --- Fixed. Thanks for reporting it.
DO NOT REPLY [Bug 7869] New: - BeanDeserializer does not say anything sensible if setter method not found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7869>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7869 BeanDeserializer does not say anything sensible if setter method not found Summary: BeanDeserializer does not say anything sensible if setter method not found Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There is no meaningful error description of any kind (ok, null pointer exception :-) if there is no setter method in the bean.
DO NOT REPLY [Bug 7612] - Java2WSDL does not work in some cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612 Java2WSDL does not work in some cases --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 15:44 --- Could you be more elaborate? 1. I assume you mean you tried: Java2WSDL -n urn:my-service ...? Try Java2WSDL -n "urn:my-service" ... The dash is a key symbol in the command line interpreter. 2. I don't understand. If you do not specify a SOAPAction, then the SOAPAction is "". 3. How doesn't it work with an EJB Object? Do you have an example and stack traces of failures?
DO NOT REPLY [Bug 7612] - Java2WSDL does not work in some cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612 Java2WSDL does not work in some cases --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 16:29 --- 1. I assume you mean you tried: Java2WSDL -n urn:my-service ...? Try Java2WSDL -n "urn:my-service" ... The dash is a key symbol in the command line interpreter. Actually, I was using Ant to do it. I passed ant arg as urn:my-service, and it return the usage. I think you are right. I will try with the quote. 2. I don't understand. If you do not specify a SOAPAction, then the SOAPAction is "". I was comparing with WSDL generated from APACH SOAP 2.2 where SoapAction is not "" where Axis generated SoapAction="" by default. I think I am probably comparing Apple and Oranges. 3. How doesn't it work with an EJB Object? Do you have an example and stack traces of failures? I used the EJB stateless sessionbean .java file and passed JAVA2WSDL file and the WSDL was generated has no content, ie. no message, no service, no binding etc. . And there was no error. I guess all these may not real bugs. I probably should take time to understand more about AXIS before I file a bug report. Sorry. I wish there are better documentation. One thing I did noticed: hope this is not a bug, is that if the reponse type is an Integer, WSDL generated has SOAP-ENC encoding style not xsd encoding --> which MS SOAP tool kit does not like. Thanks for looking into these. I promise I will be more careful nexttime I file a bug. Chester
DO NOT REPLY [Bug 7296] - deploy.wsdd for the stock sample gives false information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7296 deploy.wsdd for the stock sample gives false information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 16:58 --- Fixed. Thanks for reporting it.
DO NOT REPLY [Bug 7612] - Java2WSDL does not work in some cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612 Java2WSDL does not work in some cases --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 17:05 --- So it sounds like this bug is down to your point #3. If you really have problems you can add the example to this bug. Your last question - about Integer. xsd:int cannot be null. Neither can the Java primitive type int. So those two map well. soapenc:int CAN be NULL, so it MUST map to something that can be null - java.lang.Integer. So when we see Integer, it gets mapped to soap-enc:int.
DO NOT REPLY [Bug 7881] New: - The Service objects createCall method returns the type of javax.xml.rpc.call.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881 The Service objects createCall method returns the type of javax.xml.rpc.call. Summary: The Service objects createCall method returns the type of javax.xml.rpc.call. Product: Axis Version: beta-1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Shouldn't the org.apache.axis.client.Serivce objects createCall method return the type for org.apache.axis.client.Call instead of javax.xml.rpc.Call. Currently it returns the javax.xml.rpc.Call object. Jamie Powell
DO NOT REPLY [Bug 7881] - The Service objects createCall method returns the type of javax.xml.rpc.call.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881 The Service objects createCall method returns the type of javax.xml.rpc.call. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 17:52 --- This has already been fixed post Beta 1.
DO NOT REPLY [Bug 7881] - The Service objects createCall method returns the type of javax.xml.rpc.call.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7881 The Service objects createCall method returns the type of javax.xml.rpc.call. --- Additional Comments From [EMAIL PROTECTED] 2002-04-09 17:56 --- OOPS! Sorry. Didn't fully read your note. The answer is "NO". org.apache.axis.client.Service implements the interface javax.xml.rpc.Service, therefore it MUST implement createCall methods that return javax.xml.rpc.Call. The actual Call object it returns, however, IS an org.apache.axis.client.Call.
DO NOT REPLY [Bug 7898] New: - Axis servlet not servicing JWS pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7898>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7898 Axis servlet not servicing JWS pages Summary: Axis servlet not servicing JWS pages Product: Axis Version: pre-release Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I guess it was that patch to list available services, but if you point your browser at : http://nagoya.apache.org:5049/axis/StockQuoteService.jws you get a list of services, rather than get to see the service itself. Two words: "Regression" and "Testing"
DO NOT REPLY [Bug 7612] - Java2WSDL does not work in some cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7612 Java2WSDL does not work in some cases --- Additional Comments From [EMAIL PROTECTED] 2002-04-10 13:59 --- >>java.lang.Integer. So when we see Integer, it gets mapped to soap-enc:int. But the soap message for java.lang.Integer actually encoded as xsd:int instead of soap-enc:int (this may or may not an general observation since I only observed in my example). So One of them has to be changed to make it consistent. Chester
DO NOT REPLY [Bug 7923] New: - BeanSerializer ptr exception when only 'setter' present
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7923>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7923 BeanSerializer ptr exception when only 'setter' present Summary: BeanSerializer ptr exception when only 'setter' present Product: Axis Version: pre-release Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Similar to bug: 7869 The BeanSerializer.serializer method assumes that a property of a bean has a 'getter' by calling Method readMethod = propertyDescriptor[i].getReadMethod. Then it uses this reference as readMethod.getReturnType. But 'readMethod' is null. Therefore, a null ptr exception is thrown. This is actually 'post' beta. Reproduction is to use a bean for a return type of a called WS method that has only a 'setter' with 'no' getter present.
DO NOT REPLY [Bug 8001] New: - Attachment creates "axis" temp-directory regardless of where axis is deployed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8001>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8001 Attachment creates "axis" temp-directory regardless of where axis is deployed Summary: Attachment creates "axis" temp-directory regardless of where axis is deployed Product: Axis Version: beta-1 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have deployed axis under /webservice. I get an /axis/WEB-INF/attachments folder created, no matter what. I think the bug is in org.apache.axis.attachments.ManagedMemoryDataSource.flushToDisk(), which seems to use "axis" as name, regardless. Kristian
Bug report for Axis [2002/04/14]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6872|New|Nor|2002-03-05|Making HTTPS proxy work | | 7071|Ass|Maj|2002-03-13|Concurrency Problem in Axis engine with Applicatio| | 7132|Ass|Nor|2002-03-14|Attributes object does not contain all attributes | | 7133|Ass|Blk|2002-03-14|invoke does not return a value using rc1 and rc2. | | 7267|New|Min|2002-03-20|Null Values in Envelope are not correct | | 7268|New|Maj|2002-03-20|Responses no not declare correct EncodingStyles | | 7269|New|Blk|2002-03-20|Empty ID attributes in responses | | 7270|New|Blk|2002-03-20|Error when mapping Arrays to Collections | | 7298|New|Nor|2002-03-20|(Documentation) Installation guide does not state | | 7314|New|Enh|2002-03-21|Axis client should be able to do basic HTTP authen| | 7373|New|Nor|2002-03-22|HTTPSender does not support HTTPS through an Auth.| | 7407|New|Enh|2002-03-24|Please include the wsdl2java and java2wsdl Ant tas| | 7467|New|Nor|2002-03-25|Warnings when tomcat loads axis caused by errors i| | 7469|New|Nor|2002-03-26|axis servlet throws load() exception on Tomcat sta| | 7557|New|Nor|2002-03-28|when using simpleType, wsdd type mapping is not in| | 7560|New|Enh|2002-03-28|Sample: EchoAttachments File comparison aggressive| | 7601|New|Nor|2002-03-29|[Security] generated .class files can be downloade| | 7612|New|Nor|2002-03-29|Java2WSDL does not work in some cases | | 7625|New|Min|2002-03-29|getPrefixes method in XMLUtils should be public | | 7718|New|Min|2002-04-03|JavaProvider WSDL generator does not allow inherit| | 7722|New|Nor|2002-04-03|Extended interfaces do not show up in WSDL| | 7743|New|Maj|2002-04-04|WSDL2Java does not implement hashCode methods on a| | 7745|New|Nor|2002-04-04|Feature Req: WSDL2Java should generate validity ch| | 7856|New|Nor|2002-04-08|using call.setTargetEndpointAddress in a header pr| | 7869|New|Enh|2002-04-09|BeanDeserializer does not say anything sensible if| | 7898|New|Maj|2002-04-09|Axis servlet not servicing JWS pages | | 7923|New|Enh|2002-04-10|BeanSerializer ptr exception when only 'setter' pr| | 8001|New|Min|2002-04-12|Attachment creates "axis" temp-directory regardles| +-+---+---+--+--+ | Total 28 bugs | +---+
DO NOT REPLY [Bug 8106] New: - Concurrency problem in date deserializer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8106>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8106 Concurrency problem in date deserializer Summary: Concurrency problem in date deserializer Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The SimpleDateFormat object used in org.apache.axis.encoding.ser.DateDeserialiser is a static object used to parse the dates. This blows up with NumberFormatExceptions when used in a multithreaded client. The problem is that SimpleDateFormat is not threadsafe when used in this way. On the serialiser side it is indirectly protected by syncing on the static calendar object. It either needs to be protected in a sync block or make it non-static.
DO NOT REPLY [Bug 8111] New: - encoding of NaN is probably incorrect in SimpleSerialiser
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8111>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8111 encoding of NaN is probably incorrect in SimpleSerialiser Summary: encoding of NaN is probably incorrect in SimpleSerialiser Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The use of double data if( data == Double.NaN) --- is probably wrong - the java docs state that Double.NaN != DoubleNaN, so a comparison such as that above will always return false. It should be if( Double.isNaN( data)) This code appears in org.apache.axis.encoding.ser.SimpleSerialiser when encoding Floats and Doubles.
DO NOT REPLY [Bug 8112] New: - The SOAPEnvelope objects addAttribute method that takes a name object is incorrect.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8112>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8112 The SOAPEnvelope objects addAttribute method that takes a name object is incorrect. Summary: The SOAPEnvelope objects addAttribute method that takes a name object is incorrect. Product: Axis Version: beta-1 Platform: PC OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently in the SOAPEnvelope object there is a addAttribute method. This method takes a Name, and String parameter. Axis does not implement any Name objects and If I go into the jax stuff for creating a name. The only way to create a Name is by SOAPEnvelope.createName method which the Apache Axis implementation of SOAPEnvelope does not contain.
DO NOT REPLY [Bug 8112] - The SOAPEnvelope objects addAttribute method that takes a name object is incorrect.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8112>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8112 The SOAPEnvelope objects addAttribute method that takes a name object is incorrect. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2002-04-15 15:34 --- The JAXM javax.xml.soap interfaces are *slowly* (currently just my spare time!) being implemented in Axis and are not yet in the list of published interfaces in the User Guide, so I wouldn't recommend using them yet. If you are desparate for them, please join in and help implement them :-)
DO NOT REPLY [Bug 7557] - when using simpleType, wsdd type mapping is not interpreted correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557 when using simpleType, wsdd type mapping is not interpreted correctly --- Additional Comments From [EMAIL PROTECTED] 2002-04-15 17:14 --- Created an attachment (id=1594) simple workarround patch
DO NOT REPLY [Bug 7268] - Responses no not declare correct EncodingStyles
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7268>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7268 Responses no not declare correct EncodingStyles [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 7898] - Axis servlet not servicing JWS pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7898>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7898 Axis servlet not servicing JWS pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 8145] New: - Tcpmon does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145 Tcpmon does not work Summary: Tcpmon does not work Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Deployment / Registries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My Tomcat uses port 8080. When I set up TCPmon to listen to port 8080, I get an error :JVM-Bind : address is in use, as a red color message in the request area of tcpmon GUI. If I stopped Tomcat, then I could start tcpmon, but then I can not restart Tomcat. I get a similar error upon starting. what is going on?
DO NOT REPLY [Bug 8145] - Tcpmon does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145 Tcpmon does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-16 07:02 --- That's not a bug. You cannot let 2 applications listen at the same port. Use tcpmon as follows: Listen port: (one that is free) 8111 Target Hostname: (Where your Tomcat runs) localhost Target Port: (The Port Tomcat runs) 8080
DO NOT REPLY [Bug 8145] - Tcpmon does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145 Tcpmon does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-04-16 17:07 --- Harold: Thanks for your comment. I did exactly what you said. This time, I don't get an exception, but I also don't get any requests/responses traces in the GUI when I access web services (e.g. running CalClient, or stock quote). Is that the way it supposed to work and show traces? or I am missing something here? I am really confused, because the tcpmon GUI picture in the axis documentations actually shows port 8080 as the listening port (look yourself in the userguide, tcpmon picture; it shows Port 8080 Tab) Thanks for your help Adel
DO NOT REPLY [Bug 7270] - Error when mapping Arrays to Collections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7270>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7270 Error when mapping Arrays to Collections [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 7269] - Empty ID attributes in responses
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7269>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7269 Empty ID attributes in responses [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-04-16 21:56 --- Could you attach a zip with a minimal client/server/wsdd which demonstrates this? That would make debugging way easier - thanks!
DO NOT REPLY [Bug 8145] - Tcpmon does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8145 Tcpmon does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 7856] - using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856 using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-16 22:20 --- This is the way it's supposed to work, and your workaround is exactly the right thing to do. Your handlers shouldn't really be modifying the Call directly.
DO NOT REPLY [Bug 7856] - using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7856 using call.setTargetEndpointAddress in a header processor on the client side does not affect the target url --- Additional Comments From [EMAIL PROTECTED] 2002-04-16 22:35 --- There may be valid reasons for modifying the call object (at least the target address) in a handler. Consider the implementation of WS-Routing. Here, on the client side, a WS-Routing request handler will typically add the WS-Routing header to the outgoing mesage. Depending on whether the message is supposed to travel through an intermediary, the target address will need to change. Note that the client application (the stub that generated the call object) does not (may not) know if the message is supposed to travel via an intermediary. Actually this is the exact specific scenario that required me to change the target address in the handler.
DO NOT REPLY [Bug 7314] - Axis client should be able to do basic HTTP authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314 Axis client should be able to do basic HTTP authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 00:04 --- Thomas, this works fine for us here at Macromedia - could you be more specific about the problem you're having, maybe include an example?
DO NOT REPLY [Bug 8191] New: - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace Summary: WSDLException when using Emitter twice and java.lang namespace Product: Axis Version: beta-1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I have a WSDL with java.lang namespace and I use the same Emitter twice to emit the same WSDL (I emit it to string and to file), then I get a WSDLException (see stacktrace below). 2 additional things about this: 1. The class WSDLException is not in the Beta1 JavaDoc 2. Why include java.lang namespace in the WSDL anyway? The Emitter does this because one of our methods throws one of our own Exception classes and so the Emitter includes the whole inheritence tree of this Exception class up to Throwable. If it would throw java.lang.Exception, then the Emitter would not do this. WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://lang.java'. Namespace prefixes must be set on the Definition object using the addNamespace(. ..) method.: at com.ibm.wsdl.util.xml.DOMUtils.getPrefix(DOMUtils.java:352) at com.ibm.wsdl.util.xml.DOMUtils.getQualifiedValue(DOMUtils.java:336) at com.ibm.wsdl.util.xml.DOMUtils.printQualifiedAttribute(DOMUtils.java: 320) at com.ibm.wsdl.xml.WSDLWriterImpl.printParts(WSDLWriterImpl.java:706) at com.ibm.wsdl.xml.WSDLWriterImpl.printMessages(WSDLWriterImpl.java:676 ) at com.ibm.wsdl.xml.WSDLWriterImpl.printDefinition(WSDLWriterImpl.java:1 11) at com.ibm.wsdl.xml.WSDLWriterImpl.writeWSDL(WSDLWriterImpl.java:923) at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:902) at org.apache.axis.wsdl.fromJava.Emitter.emit(Unknown Source) at org.apache.axis.wsdl.fromJava.Emitter.emit(Unknown Source)
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 08:28 --- Created an attachment (id=1604) The WSDL.
DO NOT REPLY [Bug 7314] - Axis client should be able to do basic HTTP authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7314 Axis client should be able to do basic HTTP authentication --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 08:33 --- OK, then this is a how-to problem. WSDL2Java generated a Locator that extends org.apache.axis.client.Service for me, but how to set the credentials there?
DO NOT REPLY [Bug 8193] New: - Interop problem with .NET clients: null values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8193>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8193 Interop problem with .NET clients: null values Summary: Interop problem with .NET clients: null values Product: Axis Version: nightly Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] .NET clients omit parameters that are null, they do not use xsi:nil="true" like an Axis client. Axis cannot handle this, yet. I have made a workaround for Beta1, but Beta2 should not be released without the true solution to this, which is in the works by Glen and the current build does not seem to include this solution.
DO NOT REPLY [Bug 7745] - Feature Req: WSDL2Java should generate validity checks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7745>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7745 Feature Req: WSDL2Java should generate validity checks [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER Summary|Feature Req: WSDL2Java |Feature Req: WSDL2Java |should generate validity|should generate validity |checks |checks --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 17:05 --- There are a number of constraints that would need to be handled. Here are some more: - choice checking - choice group checking - checking of facets (i.e. min and max values) - checking of nillable - assignment via default attributes Should the serializer framework ensure the xml is valid. On the client side ? server side ? both ? There are a number of issues here which will affect the design of this feature. One alternative if you need this behaviour is to extend the WSDL2Java emitter (and perhaps serializers) to generate the method. Thanks
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 17:22 --- I am looking at this. Could you tell explain the following in more detail. 2. Why include java.lang namespace in the WSDL anyway? The Emitter does this because one of our methods throws one of our own Exception classes and so the Emitter includes the whole inheritence tree of this Exception class up to Throwable. If it would throw java.lang.Exception, then the Emitter would not do this.
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 18:26 --- 2. If I only have methods that throw java.lang.Exception in my class, then the Emitter does not declare java.lang.Throwable in the WSDL. But if I have methods, that throw my own subclass of java.lang.Exception, then the Emitter declares the public fields of that exception class and also java.lang.Throwable, in the namespace http://java.lang. My question is: Does it make sense to declare Exception classes in the WSDL? .NET client ignores them (lucky me, otherwise it would generate useless empty proxy classes for them).
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 20:58 --- It appears from the WSDL file that your P2BExeception contains a field defined as a Throwable object. This is causing Java2WSDL to create an xml definition of Throwable. How does .NET define "ae" ?
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-17 22:18 --- I cannot find any mapping for Exception/Throwable types in a non-throws context. So I am going to change this defect to INVALID for now. Java2WSDL will now throw an No Serializer Exception if a type that implements Throwable is encountered (in a non-throws context). If Thomas presents an alternative and reasonable mapping, we can reopen this defect.
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 09:34 --- That field ae is a private instance variable in the class P2DBException. Why include it in the WSDL? .NET completely ignores ae, it's not in the generated proxy file. And there is also no Throwable being generated. OK, since Exceptions are being ignored by .NET, that's fine with me, I just wanted to mention this (IMHO) strange behavior of the Emitter. Do I understand it correctly, that the Emitter cannot generate WSDL anymore now (No Serializer Exception) for my class, that throws P2DBException? That would be unfortunate. But the real reason for this bug report was the problem when using the same Emitter twice. That can't be invalid, right?
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 12:52 --- Thomas, Please send me the PB2Exception class. Apprarently ae is a parameter for the constructor; this causes Java2WSDL to generate a message part for ae. Since ae is declared as java.lang.Throwable, the emitter used to attempt to construct a Throwable type in the "http://java.lang"; namespace...which ultimately caused serious abend problems. Since there is no mapping for java.lang.Throwable, I changed the code to now issue an appropriate message. Does .NET issue any messages ? If you would kindly send me the java file (so I am not making changes in the dark) I could verify this situation and change the code to not generate the ae part. Does .Net generate a fault message ?
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 13:21 --- I will attach P2DBException.java and .class, but this depends on many other classes of our framework, so I am not sure, if Axis can generate WSDL without those. ae is not a parameter in any constructor! stackTrace, source and ae are all private member variables! .NET does not generate anything for P2DBException or java.lang.Throwable and it issues no warning. It just completely ignores exceptions in the WSDL. I will also attach the generated C# code. I don't think, it's a good idea, if the Emitter throws an exception while trying to generate the WSDL, it should rather ignore stuff that cannot go into the WSDL. And how is this related to the fact that the WSDLException only occurs if the same Emitter is used twice?
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 13:21 --- Created an attachment (id=1616) P2DBException.java
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 13:22 --- Created an attachment (id=1617) P2DBException.class
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 13:23 --- Created an attachment (id=1618) The generated C# code.
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 15:06 --- Thanks Thomas. I will clean this up later today or Friday. There were some code changes that I was not aware of. (I am at home sick right now...) Since ae is a private variable it should never be in the wsdl. This is the root of the problem.
DO NOT REPLY [Bug 7557] - when using simpleType, wsdd type mapping is not interpreted correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7557 when using simpleType, wsdd type mapping is not interpreted correctly [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 8111] - encoding of NaN is probably incorrect in SimpleSerialiser
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8111>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8111 encoding of NaN is probably incorrect in SimpleSerialiser [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-18 19:04 --- Made the change to use isNaN().
DO NOT REPLY [Bug 8191] - WSDLException when using Emitter twice and java.lang namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8191 WSDLException when using Emitter twice and java.lang namespace --- Additional Comments From [EMAIL PROTECTED] 2002-04-19 07:24 --- I agree about the root of the problem, but still I wonder why the Emitter throws the WSDLException only at the second emit() call.
DO NOT REPLY [Bug 8296] New: - WSDL2Java forces use of namespace prefix in type attribute value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296 WSDL2Java forces use of namespace prefix in type attribute value Summary: WSDL2Java forces use of namespace prefix in type attribute value Product: Axis Version: beta-1 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems that WSDL2Java forces one to use a namespace prefix in at least the type attribute value of the message element. It may be all type attribute values specified as Qnames. According to the Namespaces In XML recommendation, namespace prefix for qualified names is optional.
DO NOT REPLY [Bug 8296] - WSDL2Java forces use of namespace prefix in type attribute value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296 WSDL2Java forces use of namespace prefix in type attribute value --- Additional Comments From [EMAIL PROTECTED] 2002-04-19 13:52 --- Created an attachment (id=1632) Example WSDL that causes failure
DO NOT REPLY [Bug 8296] - WSDL2Java forces use of namespace prefix in type attribute value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296 WSDL2Java forces use of namespace prefix in type attribute value --- Additional Comments From [EMAIL PROTECTED] 2002-04-19 13:57 --- That's actually the type attribute value of the PART element of message.
DO NOT REPLY [Bug 8296] - WSDL2Java forces use of namespace prefix in type attribute value
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8296 WSDL2Java forces use of namespace prefix in type attribute value --- Additional Comments From [EMAIL PROTECTED] 2002-04-19 14:15 --- The following is defined in your wsdl: And I believe you are questioning why type="currentDateInput" does not work. (?) Since you didn't use a prefix, then you need to have an xmlns="" defined. Also you didn't include the imported xml file.
DO NOT REPLY [Bug 7267] - Null Values in Envelope are not correct
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7267>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7267
Null Values in Envelope are not correct
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
--- Additional Comments From [EMAIL PROTECTED] 2002-04-19 14:54 ---
This actually points to a larger issue in the way we're currently handling
schema support. There are more differences than just the namespace when
switching schema versions, so we need a "SchemaContext" which gets us things
like the "null" qname and values ('null=1' for 1999 schema, 'nil=true' for
2001, etc).
The serialization is correct for 2001 schema, but wrong for 1999.
We'll fix this ASAP - thanks for the note.
DO NOT REPLY [Bug 7743] - WSDL2Java does not implement hashCode methods on all classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743 WSDL2Java does not implement hashCode methods on all classes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-04-19 15:49 --- Seems reasonable to me since it already emits equals(). I'll add this.
DO NOT REPLY [Bug 7743] - WSDL2Java does not implement hashCode methods on all classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7743 WSDL2Java does not implement hashCode methods on all classes [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|ASSIGNED|NEW
