Fw: Platform abstraction layer thoughts
Nadir, +1 to make the platform abstraction layer a separate library. I assume all our current libraries (client, transport, channel, etc) will be linked with the platform abstraction library. In which case, I propose moving trace into the platform abstraction library as well since all libraries need it. Currently trace entrypoints are called by address from the transport, channel, etc libraries, since these libraries are not linked with AxisClient. This makes for horrible code which would be greatly simplified by moving trace into the new platform abstraction library. Mark Mark Whitlock IBM - Forwarded by Mark Whitlock/UK/IBM on 24/05/2005 11:35 - Nadir Amra [EMAIL PROTECTED] To 23/05/2005 20:19 Apache AXIS C Developers List axis-c-dev@ws.apache.org cc Please respond to Apache AXIS C Subject Developers List Re: Fw: Platform abstraction layer thoughts Mark, I prefer that the platform abstraction layer is in a seperate library. Any small functions, when it makes sense, can always be defined as inlined, no? Nadir K. Amra Mark Whitlock [EMAIL PROTECTED] wrote on 05/19/2005 04:30:41 AM: Hi Nadir, +1 to putting all platform-specific code in the platform abstraction layer. The disadvantage of linking the platform-specific code into a separate library is that it stops the compiler from optimising small functions by inlining them. I guess the platform-specific layer is likely to be full of such small functions. The advantage of linking the platform-specific code into a separate library is that the transport, channel and XML parser libraries could all link with the PS library (since they are not linked with the AxisClient library). Which do you prefer? Mark Mark Whitlock IBM
[jira] Commented: (AXISCPP-657) Stress test fails to dlopen channel
[ http://issues.apache.org/jira/browse/AXISCPP-657?page=comments#action_66166 ] Mark Whitlock commented on AXISCPP-657: --- I was running this test on AIX. I haven't tried other platforms as yet. Stress test fails to dlopen channel --- Key: AXISCPP-657 URL: http://issues.apache.org/jira/browse/AXISCPP-657 Project: Axis-C++ Type: Bug Components: Basic Architecture Reporter: Mark Whitlock I changed the CalculatorDoc_TTest so that it ran 20 threads and in each thread looped round invocating the web service 20 times. This failed with Exception : DLOPEN FAILED in loading channel library /home/whitlock/nw00-L050523_P/src/ws-axis/c/../../../obj/package/wscc-1.0-AIX/lib/libhttp_channel.a If I increased the thread count and loop count I got many more of these failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-657) Stress test fails to dlopen channel
[ http://issues.apache.org/jira/browse/AXISCPP-657?page=comments#action_66167 ] Mark Whitlock commented on AXISCPP-657: --- I ran the same test on Windows XP. I never got any dlopen failures. Instead with 50threads * 50loops I got lots of Exception : HTTPTransportException:Client failed to open Failed to open connection to server: hostname='bora.hursley.ibm.com' port='9080' Error Message='No connection could be made because the target machine actively refused it. ' I thought this might be a firewall problem on the server so I switched the firewall off on the server and ran it again. This time the client hung and when I killed it my machine got very sick and I had to reboot it. Stress test fails to dlopen channel --- Key: AXISCPP-657 URL: http://issues.apache.org/jira/browse/AXISCPP-657 Project: Axis-C++ Type: Bug Components: Basic Architecture Reporter: Mark Whitlock I changed the CalculatorDoc_TTest so that it ran 20 threads and in each thread looped round invocating the web service 20 times. This failed with Exception : DLOPEN FAILED in loading channel library /home/whitlock/nw00-L050523_P/src/ws-axis/c/../../../obj/package/wscc-1.0-AIX/lib/libhttp_channel.a If I increased the thread count and loop count I got many more of these failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AXISCPP-658) make the openConnection method really open the connection instead of flushOutput
[ http://issues.apache.org/jira/browse/AXISCPP-658?page=all ] Samisa Abeysinghe reassigned AXISCPP-658: - Assign To: Samisa Abeysinghe make the openConnection method really open the connection instead of flushOutput -- Key: AXISCPP-658 URL: http://issues.apache.org/jira/browse/AXISCPP-658 Project: Axis-C++ Type: Improvement Components: Transport (axis3) Versions: 1.5 Final Environment: All platforms Reporter: Samisa Abeysinghe Assignee: Samisa Abeysinghe Fix For: 1.6 Alpha The openConnection method does nothing at the moment in transport. The actual connection opening is done in the flushOutput method. It is ideal to have the openConnection method acctually open the connection in the transport. To do this, we have to remove the connection opening from the flushOutput methid and also ensure that the connection opening is done in some sensible place in the Call class - probably in invoke method after the handlers are loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AXISCPP-659) Move connection opening out of flushOutput method
Move connection opening out of flushOutput method - Key: AXISCPP-659 URL: http://issues.apache.org/jira/browse/AXISCPP-659 Project: Axis-C++ Type: Improvement Components: Transport (axis3) Versions: 1.5 Final Reporter: Samisa Abeysinghe Fix For: 1.6 Alpha Connection opening should not be the responsibility of the flushOutput method. Rather it has to be an independent act. When connection opening is within the flushOutput, it becomes harder to debug. Hence it is ideal to move this to out of flushOutput. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Custom endpointURL in wsdd and AxisServlet problem
Dear Axis developers, I've came over a problem (or at least an incosistency) with latest Axis version (1.2 stable): I wanted to set up manually endpointURL/ in my services' .wsdd file. Let's assume that a service is deployed at: http://my_host.com/axis/services/Foo If I set up endpointURL like this: endpointURLhttp://my_host.com/axis/services/Foo/endpointURL I get the link to the wsdl file at http://my_host.com/axis/services like this: http://my_host.com/axis/services/FooFoo?wsdl but when I set up endpointURL like this: endpointURLhttp://my_host.com/axis/services//endpointURL the link to wsdl works fine, however the soap:service tag looks like this... soap:service location="http://my_host.com/axis/services" I'd appreciate any comment if the above is a bug or maybe there is some more subtle way of setting this . After looking to AxisServlet.java, I saw that AxisServlet combines endpointURL with services' name and with "?wsdl" Is that how it should work?? Thanks in advance, Bartek Kryza
[jira] Updated: (AXIS-2011) Multi Dimensional Array Serilization
[ http://issues.apache.org/jira/browse/AXIS-2011?page=all ] Guillaume Sauthier updated AXIS-2011: - Attachment: axis-arrayMapping.patch A real patch against latest CVS apply into src Multi Dimensional Array Serilization Key: AXIS-2011 URL: http://issues.apache.org/jira/browse/AXIS-2011 Project: Axis Type: Improvement Components: Deployment / Registries, Serialization/Deserialization Versions: 1.2 Environment: JOnAS 4.4 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar Actually the test case test.wsdl.marshall is broken because Axis do not serialize 2D arrays as expected. See http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 for reference. We are expecting a correct SOAP Message formed like this : soap:Body ns1:myOperation return return soapenc:arraytype=xsd:string[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=xsd:string xsi:nil=true [...] Instead, we have the following : soap:Body ns1:myOperation return return soapenc:arraytype=ns:ArrayOfstring[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=ns:ArrayOfArrayOfstring xsi:nil=true [...] Points to notice : A. the first arrayType has a wrong xml type (expecting most inner non array type xsd:string in place of ns:ArrayOfstring) B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements for the first dim C. last element of the array has a wrong xsi:type ! I don't know where it comes from but its wrong, indeed :) The first thing I tried to change the xsi:type (C) was to lookup the xml type from the (most inner non array )Java type we retrieve. Problem with this approach : I can't exactly control if I will get an xsd:string or soapenc:string. For my case, I was waiting an xsd:string and the TypeMapping gives me a soapenc:string. Grrr ! Looking deeper in ArraySerializer.serialize(), we can see that this serializer is not symetrical (for java type and xml type) : we can go several levels deep when searching for the most inner non array java type, but we're stuck to the itemType (only 1 level deep) retrieved from SerializationContext for xml types! My idea is to allow searching in xml types too. If we have for each ArraySerializer the wanted innerType, we can get the mapped serializer. If the retrieved serializer is an ArraySerilalizer, we can go one step further, ... So with this, we're symetrical (we go deeper for the xml AND java types in the same time). Notice that's more time consumming, because we search TypeMapping very often ! Now, how to give these metadatas to the Engine ? In the wsdd, indeed ! So now, we have a new element arrayMapping element that allow us to specify the innerType for an ArraySerializer ! To be complete, I made some changes too in JavaDeployWriter, to write up the arrayMapping element when an ArraySerializerFactory has to be used. Important : This is only for review (Glen/Tom ?) !! The code attached to this report is neither clean nor complete : - innerName attribute is not used, could be usefull ? - to limitate the number of impacted files, a lot of Constants are inside WSDDArrAyMapping, should go in WSDDContstants. - at this time, arrayMapping is only understand if contained in a service element ! We should add for each TypeMappingContainer subclasses... - WSDDArrayMapping can be improved with error message (when trying to set ser/deser other than ArraySerFactory...) - maybe we can add some NPE checks :) Thanks for your comments/suggestions ! --Guillaume -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AXIS-2011) Multi Dimensional Array Serilization
[ http://issues.apache.org/jira/browse/AXIS-2011?page=all ] Guillaume Sauthier reassigned AXIS-2011: Assign To: Guillaume Sauthier (was: Guillaume Sauthier) Multi Dimensional Array Serilization Key: AXIS-2011 URL: http://issues.apache.org/jira/browse/AXIS-2011 Project: Axis Type: Improvement Components: Serialization/Deserialization, Deployment / Registries Versions: 1.2 Environment: JOnAS 4.4 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier Fix For: 1.2.1 Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar Actually the test case test.wsdl.marshall is broken because Axis do not serialize 2D arrays as expected. See http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 for reference. We are expecting a correct SOAP Message formed like this : soap:Body ns1:myOperation return return soapenc:arraytype=xsd:string[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=xsd:string xsi:nil=true [...] Instead, we have the following : soap:Body ns1:myOperation return return soapenc:arraytype=ns:ArrayOfstring[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=ns:ArrayOfArrayOfstring xsi:nil=true [...] Points to notice : A. the first arrayType has a wrong xml type (expecting most inner non array type xsd:string in place of ns:ArrayOfstring) B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements for the first dim C. last element of the array has a wrong xsi:type ! I don't know where it comes from but its wrong, indeed :) The first thing I tried to change the xsi:type (C) was to lookup the xml type from the (most inner non array )Java type we retrieve. Problem with this approach : I can't exactly control if I will get an xsd:string or soapenc:string. For my case, I was waiting an xsd:string and the TypeMapping gives me a soapenc:string. Grrr ! Looking deeper in ArraySerializer.serialize(), we can see that this serializer is not symetrical (for java type and xml type) : we can go several levels deep when searching for the most inner non array java type, but we're stuck to the itemType (only 1 level deep) retrieved from SerializationContext for xml types! My idea is to allow searching in xml types too. If we have for each ArraySerializer the wanted innerType, we can get the mapped serializer. If the retrieved serializer is an ArraySerilalizer, we can go one step further, ... So with this, we're symetrical (we go deeper for the xml AND java types in the same time). Notice that's more time consumming, because we search TypeMapping very often ! Now, how to give these metadatas to the Engine ? In the wsdd, indeed ! So now, we have a new element arrayMapping element that allow us to specify the innerType for an ArraySerializer ! To be complete, I made some changes too in JavaDeployWriter, to write up the arrayMapping element when an ArraySerializerFactory has to be used. Important : This is only for review (Glen/Tom ?) !! The code attached to this report is neither clean nor complete : - innerName attribute is not used, could be usefull ? - to limitate the number of impacted files, a lot of Constants are inside WSDDArrAyMapping, should go in WSDDContstants. - at this time, arrayMapping is only understand if contained in a service element ! We should add for each TypeMappingContainer subclasses... - WSDDArrayMapping can be improved with error message (when trying to set ser/deser other than ArraySerFactory...) - maybe we can add some NPE checks :) Thanks for your comments/suggestions ! --Guillaume -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-2011) Multi Dimensional Array Serialization
[ http://issues.apache.org/jira/browse/AXIS-2011?page=all ] Guillaume Sauthier updated AXIS-2011: - Summary: Multi Dimensional Array Serialization (was: Multi Dimensional Array Serilization) Fix Version: 1.2.1 Multi Dimensional Array Serialization - Key: AXIS-2011 URL: http://issues.apache.org/jira/browse/AXIS-2011 Project: Axis Type: Improvement Components: Serialization/Deserialization, Deployment / Registries Versions: 1.2 Environment: JOnAS 4.4 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier Fix For: 1.2.1 Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar Actually the test case test.wsdl.marshall is broken because Axis do not serialize 2D arrays as expected. See http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 for reference. We are expecting a correct SOAP Message formed like this : soap:Body ns1:myOperation return return soapenc:arraytype=xsd:string[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=xsd:string xsi:nil=true [...] Instead, we have the following : soap:Body ns1:myOperation return return soapenc:arraytype=ns:ArrayOfstring[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=ns:ArrayOfArrayOfstring xsi:nil=true [...] Points to notice : A. the first arrayType has a wrong xml type (expecting most inner non array type xsd:string in place of ns:ArrayOfstring) B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements for the first dim C. last element of the array has a wrong xsi:type ! I don't know where it comes from but its wrong, indeed :) The first thing I tried to change the xsi:type (C) was to lookup the xml type from the (most inner non array )Java type we retrieve. Problem with this approach : I can't exactly control if I will get an xsd:string or soapenc:string. For my case, I was waiting an xsd:string and the TypeMapping gives me a soapenc:string. Grrr ! Looking deeper in ArraySerializer.serialize(), we can see that this serializer is not symetrical (for java type and xml type) : we can go several levels deep when searching for the most inner non array java type, but we're stuck to the itemType (only 1 level deep) retrieved from SerializationContext for xml types! My idea is to allow searching in xml types too. If we have for each ArraySerializer the wanted innerType, we can get the mapped serializer. If the retrieved serializer is an ArraySerilalizer, we can go one step further, ... So with this, we're symetrical (we go deeper for the xml AND java types in the same time). Notice that's more time consumming, because we search TypeMapping very often ! Now, how to give these metadatas to the Engine ? In the wsdd, indeed ! So now, we have a new element arrayMapping element that allow us to specify the innerType for an ArraySerializer ! To be complete, I made some changes too in JavaDeployWriter, to write up the arrayMapping element when an ArraySerializerFactory has to be used. Important : This is only for review (Glen/Tom ?) !! The code attached to this report is neither clean nor complete : - innerName attribute is not used, could be usefull ? - to limitate the number of impacted files, a lot of Constants are inside WSDDArrAyMapping, should go in WSDDContstants. - at this time, arrayMapping is only understand if contained in a service element ! We should add for each TypeMappingContainer subclasses... - WSDDArrayMapping can be improved with error message (when trying to set ser/deser other than ArraySerFactory...) - maybe we can add some NPE checks :) Thanks for your comments/suggestions ! --Guillaume -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2011) Multi Dimensional Array Serialization
[ http://issues.apache.org/jira/browse/AXIS-2011?page=comments#action_66159 ] Davanum Srinivas commented on AXIS-2011: Guillaume, +1 to check in the code. thanks, dims Multi Dimensional Array Serialization - Key: AXIS-2011 URL: http://issues.apache.org/jira/browse/AXIS-2011 Project: Axis Type: Improvement Components: Serialization/Deserialization, Deployment / Registries Versions: 1.2 Environment: JOnAS 4.4 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier Fix For: 1.2.1 Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar Actually the test case test.wsdl.marshall is broken because Axis do not serialize 2D arrays as expected. See http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 for reference. We are expecting a correct SOAP Message formed like this : soap:Body ns1:myOperation return return soapenc:arraytype=xsd:string[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=xsd:string xsi:nil=true [...] Instead, we have the following : soap:Body ns1:myOperation return return soapenc:arraytype=ns:ArrayOfstring[][2] xsi:type=soapenc:Array return soapenc:arraytype=xsd:string[2] xsi:type=soapenc:Array return xsi:type=xsd:string [Value1] return xsi:type=xsd:string [] return xsi:type=ns:ArrayOfArrayOfstring xsi:nil=true [...] Points to notice : A. the first arrayType has a wrong xml type (expecting most inner non array type xsd:string in place of ns:ArrayOfstring) B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements for the first dim C. last element of the array has a wrong xsi:type ! I don't know where it comes from but its wrong, indeed :) The first thing I tried to change the xsi:type (C) was to lookup the xml type from the (most inner non array )Java type we retrieve. Problem with this approach : I can't exactly control if I will get an xsd:string or soapenc:string. For my case, I was waiting an xsd:string and the TypeMapping gives me a soapenc:string. Grrr ! Looking deeper in ArraySerializer.serialize(), we can see that this serializer is not symetrical (for java type and xml type) : we can go several levels deep when searching for the most inner non array java type, but we're stuck to the itemType (only 1 level deep) retrieved from SerializationContext for xml types! My idea is to allow searching in xml types too. If we have for each ArraySerializer the wanted innerType, we can get the mapped serializer. If the retrieved serializer is an ArraySerilalizer, we can go one step further, ... So with this, we're symetrical (we go deeper for the xml AND java types in the same time). Notice that's more time consumming, because we search TypeMapping very often ! Now, how to give these metadatas to the Engine ? In the wsdd, indeed ! So now, we have a new element arrayMapping element that allow us to specify the innerType for an ArraySerializer ! To be complete, I made some changes too in JavaDeployWriter, to write up the arrayMapping element when an ArraySerializerFactory has to be used. Important : This is only for review (Glen/Tom ?) !! The code attached to this report is neither clean nor complete : - innerName attribute is not used, could be usefull ? - to limitate the number of impacted files, a lot of Constants are inside WSDDArrAyMapping, should go in WSDDContstants. - at this time, arrayMapping is only understand if contained in a service element ! We should add for each TypeMappingContainer subclasses... - WSDDArrayMapping can be improved with error message (when trying to set ser/deser other than ArraySerFactory...) - maybe we can add some NPE checks :) Thanks for your comments/suggestions ! --Guillaume -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Axis2] Proposal for adding a method in OMElement API.
Hi guys, I would like to get involved with Axis 2 development. Can any of you let me know a good starting poitn?? Regards Vaidya On 5/22/05, Paul R Brown [EMAIL PROTECTED] wrote: Jaya -- [Eran] Well, I accept the proposal but not the method signature. Uniqueness of a namespace comes from the URI, but not from the prefix. A URI can contain more than one prefix. [jayachadra[ I think it's the otherway round. A URI can have multiple prefixes, but a prefix has associated with it just one URI. So supposing the map looks like prefix1 - http://commonurl.org/ prefix2 - http://commonurl.org/ prefix3 - http://commonurl.org/ Uniqueness here comes with prefix. FWIW, there is no uniqueness either way, really. A prefix represents a single URI, if any, in a given context, but the binding in a nested context may shadow one in a larger context. foo:bar xmlns:foo=qux:fneh foo:baz xmlns:foo=baz:snee att=foo:gazoom / /foo:bar The fact that there is another binding hiding behind the foo prefix is not insignificant if the foo on the foo:baz element is deleted. This is why you can't use just a HashMap for namespaces at an element. -- Paul
Re: [Axis2] Proposal for adding a method in OMElement API.
Hi Raghavendra! You can start at the wiki, it could be outdated but nevertheless a good starting point. URL is http://wiki.apache.org/ws/FrontPage/Axis2 Jaya On 5/24/05, Raghavendra Vaidya [EMAIL PROTECTED] wrote: Hi guys, I would like to get involved with Axis 2 development. Can any of you let me know a good starting poitn?? Regards Vaidya On 5/22/05, Paul R Brown [EMAIL PROTECTED] wrote: Jaya -- [Eran] Well, I accept the proposal but not the method signature. Uniqueness of a namespace comes from the URI, but not from the prefix. A URI can contain more than one prefix. [jayachadra[ I think it's the otherway round. A URI can have multiple prefixes, but a prefix has associated with it just one URI. So supposing the map looks like prefix1 - http://commonurl.org/ prefix2 - http://commonurl.org/ prefix3 - http://commonurl.org/ Uniqueness here comes with prefix. FWIW, there is no uniqueness either way, really. A prefix represents a single URI, if any, in a given context, but the binding in a nested context may shadow one in a larger context. foo:bar xmlns:foo=qux:fneh foo:baz xmlns:foo=baz:snee att=foo:gazoom / /foo:bar The fact that there is another binding hiding behind the foo prefix is not insignificant if the foo on the foo:baz element is deleted. This is why you can't use just a HashMap for namespaces at an element. -- Paul -- -- Jaya
[jira] Resolved: (AXIS-1469) Updates not effective after saveChanges() or writeTo()
[ http://issues.apache.org/jira/browse/AXIS-1469?page=all ] Venkat Reddy resolved AXIS-1469: Resolution: Fixed Fixed by a patch for AXIS-1960. Updates not effective after saveChanges() or writeTo() -- Key: AXIS-1469 URL: http://issues.apache.org/jira/browse/AXIS-1469 Project: Axis Type: Bug Components: SAAJ Versions: 1.2 Beta Environment: JDK 1.4.2, Resin 2.1.14 Reporter: Mattias Jiderhamn Priority: Critical Not sure how to explain this in an understandable manner, but run this code and you will clearly see the problem: SOAPMessage soapMessage = MessageFactory.newInstance().createMessage(); SOAPEnvelope soapEnvelope = soapMessage.getSOAPPart().getEnvelope(); // Get handle to envelope // soapMessage.writeTo(System.out); // This would give the same results soapMessage.saveChanges(); // This converts the SOAP message to String form (as a Fix for Bug 16418???) soapEnvelope.addChildElement(foo, bar, http://foo/bar;); // Add child elements soapMessage.writeTo(System.out); // The message is already in String form, and changes have no effect -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Axis2] REMINDER : Axis IRC chat TOMORROW
Hi folks! This is an automatic reminder that the weekly Axis2 developer chat will be occurring tomorrow, May 25, at: 5AM PDT, 8AM EDT, 12PM GMT, 6PM SLT, 10PM (next day) AEST The chat takes place on the freenode IRC network, (use server irc.freenode.net), on channel #apache-axis, and is scheduled to last one hour, though it may run longer. Please join us! Current topics can be found at http://wiki.apache.org/ws/ChatAgenda. If you need an IRC client for windows, check out http://www.mirc.com, and http://www.mirc.com/links.html has some links to clients for other OS's. Thanks, --Glen P.S. To account for the time difference between the US, Europe, and Sri Lanka, we toggle the times each week. NEXT week, the chat will be at: 7PM PDT, 10PM EDT, 2AM GMT, 8AM (next day) SLT, 12PM (next day) AEST
[jira] Created: (AXIS-2013) Deserialization of Exception fails
Deserialization of Exception fails -- Key: AXIS-2013 URL: http://issues.apache.org/jira/browse/AXIS-2013 Project: Axis Type: Bug Components: Serialization/Deserialization Versions: current (nightly) Environment: Linux, JDK 1.4.2_06 Reporter: Hans I have a very basic application deployed as a webservice with one operation that throws a user-defined exception (derived from AxisFault). The client application calling this operation has defined a type mapping that maps the operation fault to a client-side Exception class. When the client invokes the operation and the exception is thrown, the client throws an AxisFault instead of the client-exception class. When I edit the server-config.wsdd and set the parameter 'sendMultiRefs' to false, everything works ok: the exception thrown in the server is deserialized and the client throws the mapped client-side exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2013) Deserialization of Exception fails
[ http://issues.apache.org/jira/browse/AXIS-2013?page=comments#action_66178 ] Hans commented on AXIS-2013: Both the client and server are java applications using Axis 1.2.1. Deserialization of Exception fails -- Key: AXIS-2013 URL: http://issues.apache.org/jira/browse/AXIS-2013 Project: Axis Type: Bug Components: Serialization/Deserialization Versions: current (nightly) Environment: Linux, JDK 1.4.2_06 Reporter: Hans I have a very basic application deployed as a webservice with one operation that throws a user-defined exception (derived from AxisFault). The client application calling this operation has defined a type mapping that maps the operation fault to a client-side Exception class. When the client invokes the operation and the exception is thrown, the client throws an AxisFault instead of the client-exception class. When I edit the server-config.wsdd and set the parameter 'sendMultiRefs' to false, everything works ok: the exception thrown in the server is deserialized and the client throws the mapped client-side exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1978) Invalid code generated in JavaServiceImplWriter w/multiple ports
[
http://issues.apache.org/jira/browse/AXIS-1978?page=comments#action_66172 ]
Eric Hardesty commented on AXIS-1978:
-
Your statement about about only one IF or ELSE block being executed is
incorrect. In the example if the endpoint is hooxEndpoint2 then only the
last IF is executed, but if the endpoint is hooxEndpoint3 then the first IF
to set the endpoint is executed and the final else is also executed and an
unknown port name is returned since the ELSE is only applicable to the final IF
block. The code is setting the endpoint and continuing not returning.
Eric
Invalid code generated in JavaServiceImplWriter w/multiple ports
Key: AXIS-1978
URL: http://issues.apache.org/jira/browse/AXIS-1978
Project: Axis
Type: Bug
Components: WSDL processing
Environment: N/A
Reporter: Eric Hardesty
Priority: Minor
The code generated by writeSetEndpointAddress in JavaServiceImplWriter is
incorrect if multiple ports are included for a service. The code needs to be
similar to writeGetPortQNameClass where the else is included at the end of
the if statement. Below I have a sample an example of the WSDL, generated
Locator patch file(untested at this time):
WSDL:
service name=HooXEndpointInterfaceService
port binding=impl:HooXEndpointHooxBinding name=hooxEndpoint3
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
port binding=impl:HooXEndpointHooxBinding name=hooxEndpoint2
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
port binding=impl:HooXEndpointSoapBinding name=hooxEndpoint1
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
/service
HooXEndpointInterfaceServiceLocator:
/**
* Set the endpoint address for the specified port name.
*/
public void setEndpointAddress(java.lang.String portName,
java.lang.String address) throws javax.xml.rpc.ServiceException {
if (hooxEndpoint3.equals(portName)) {
sethooxEndpoint3EndpointAddress(address);
}
if (hooxEndpoint1.equals(portName)) {
sethooxEndpoint1EndpointAddress(address);
}
if (hooxEndpoint2.equals(portName)) {
sethooxEndpoint2EndpointAddress(address);
}
else { // Unknown Port Name
throw new javax.xml.rpc.ServiceException( Cannot set Endpoint
Address for Unknown Port + portName);
}
Patch:
Index: JavaServiceImplWriter.java
===
RCS file:
/home/cvspublic/ws-axis/java/src/org/apache/axis/wsdl/toJava/JavaServiceImplWriter.java,v
retrieving revision 1.44
diff -u -r1.44 JavaServiceImplWriter.java
--- JavaServiceImplWriter.java20 Jan 2005 21:35:22 - 1.44
+++ JavaServiceImplWriter.java5 May 2005 22:54:48 -
@@ -601,15 +601,18 @@
public void setEndpointAddress(java.lang.String
portName, java.lang.String address) throws
+ javax.xml.rpc.ServiceException.class.getName() + {);
+pw.print();
for (Iterator p = portNames.iterator(); p.hasNext();) {
String name = (String) p.next();
-pw.println(if (\ + name + \.equals(portName)) {);
+pw.println(if (\ + name + \.equals(portName)) {);
pw.println(set + name +
EndpointAddress(address););
pw.println(});
+pw.print(else );
}
-pw.println(else { // Unknown Port Name);
+pw.println( { // Unknown Port Name);
+
pw.println(throw new
+ javax.xml.rpc.ServiceException.class.getName() + (\
+ Messages.getMessage(unknownPortName)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1978) Invalid code generated in JavaServiceImplWriter w/multiple ports
[
http://issues.apache.org/jira/browse/AXIS-1978?page=comments#action_66183 ]
Tom Jordahl commented on AXIS-1978:
---
Eric is correct, the patched code is correct, the original code will throw the
unknown endpoint exception. We should fix that.
Invalid code generated in JavaServiceImplWriter w/multiple ports
Key: AXIS-1978
URL: http://issues.apache.org/jira/browse/AXIS-1978
Project: Axis
Type: Bug
Components: WSDL processing
Environment: N/A
Reporter: Eric Hardesty
Priority: Minor
The code generated by writeSetEndpointAddress in JavaServiceImplWriter is
incorrect if multiple ports are included for a service. The code needs to be
similar to writeGetPortQNameClass where the else is included at the end of
the if statement. Below I have a sample an example of the WSDL, generated
Locator patch file(untested at this time):
WSDL:
service name=HooXEndpointInterfaceService
port binding=impl:HooXEndpointHooxBinding name=hooxEndpoint3
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
port binding=impl:HooXEndpointHooxBinding name=hooxEndpoint2
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
port binding=impl:HooXEndpointSoapBinding name=hooxEndpoint1
wsdlsoap:address
location=http://localhost:9000/hooxsample/hooxEndpoint1/hooxEndpoint1/
/port
/service
HooXEndpointInterfaceServiceLocator:
/**
* Set the endpoint address for the specified port name.
*/
public void setEndpointAddress(java.lang.String portName,
java.lang.String address) throws javax.xml.rpc.ServiceException {
if (hooxEndpoint3.equals(portName)) {
sethooxEndpoint3EndpointAddress(address);
}
if (hooxEndpoint1.equals(portName)) {
sethooxEndpoint1EndpointAddress(address);
}
if (hooxEndpoint2.equals(portName)) {
sethooxEndpoint2EndpointAddress(address);
}
else { // Unknown Port Name
throw new javax.xml.rpc.ServiceException( Cannot set Endpoint
Address for Unknown Port + portName);
}
Patch:
Index: JavaServiceImplWriter.java
===
RCS file:
/home/cvspublic/ws-axis/java/src/org/apache/axis/wsdl/toJava/JavaServiceImplWriter.java,v
retrieving revision 1.44
diff -u -r1.44 JavaServiceImplWriter.java
--- JavaServiceImplWriter.java20 Jan 2005 21:35:22 - 1.44
+++ JavaServiceImplWriter.java5 May 2005 22:54:48 -
@@ -601,15 +601,18 @@
public void setEndpointAddress(java.lang.String
portName, java.lang.String address) throws
+ javax.xml.rpc.ServiceException.class.getName() + {);
+pw.print();
for (Iterator p = portNames.iterator(); p.hasNext();) {
String name = (String) p.next();
-pw.println(if (\ + name + \.equals(portName)) {);
+pw.println(if (\ + name + \.equals(portName)) {);
pw.println(set + name +
EndpointAddress(address););
pw.println(});
+pw.print(else );
}
-pw.println(else { // Unknown Port Name);
+pw.println( { // Unknown Port Name);
+
pw.println(throw new
+ javax.xml.rpc.ServiceException.class.getName() + (\
+ Messages.getMessage(unknownPortName)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
RE: Custom endpointURL in wsdd and AxisServlet problem
Is that how it should work?? Yes. Note that if you are deploying the Axis servlet at /axis/services, setting a service endpoint there is going to cause trouble. -- Tom Jordahl Macromedia Server Development From: Bartosz Kryza [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 4:42 AM To: axis-dev@ws.apache.org Subject: Custom endpointURL in wsdd and AxisServlet problem Dear Axis developers, I've came over a problem (or at least an incosistency) with latest Axis version (1.2 stable): I wanted to set up manually endpointURL/ in my services' .wsdd file. Let's assume that a service is deployed at: http://my_host.com/axis/services/Foo If I set up endpointURL like this: endpointURLhttp://my_host.com/axis/services/Foo/endpointURL I get the link to the wsdl file at http://my_host.com/axis/services like this: http://my_host.com/axis/services/FooFoo?wsdl but when I set up endpointURL like this: endpointURLhttp://my_host.com/axis/services//endpointURL the link to wsdl works fine, however the soap:service tag looks like this... soap:service location=http://my_host.com/axis/services I'd appreciate any comment if the above is a bug or maybe there is some more subtle way of setting this . After looking to AxisServlet.java, I saw that AxisServlet combines endpointURL with services' name and with ?wsdl Is that how it should work?? Thanks in advance, Bartek Kryza
[jira] Created: (AXIS-2015) org.apache.axis.types.URI does not compare registry authority in equals()
org.apache.axis.types.URI does not compare registry authority in equals() - Key: AXIS-2015 URL: http://issues.apache.org/jira/browse/AXIS-2015 Project: Axis Type: Bug Components: Basic Architecture Versions: current (nightly) Reporter: Steve Green org.apache.axis.types.URI does not compare registry authority in equals(). This test program prints true. URI oURI1 = new URI (abc://@10); URI oURI2 = new URI (abc://@20); System.out.println (oURI1.equals(oURI2)); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-2015) org.apache.axis.types.URI does not compare registry authority in equals()
[ http://issues.apache.org/jira/browse/AXIS-2015?page=all ] Steve Green updated AXIS-2015: -- Attachment: 2015.patch Patch and test case org.apache.axis.types.URI does not compare registry authority in equals() - Key: AXIS-2015 URL: http://issues.apache.org/jira/browse/AXIS-2015 Project: Axis Type: Bug Components: Basic Architecture Versions: current (nightly) Reporter: Steve Green Attachments: 2015.patch org.apache.axis.types.URI does not compare registry authority in equals(). This test program prints true. URI oURI1 = new URI (abc://@10); URI oURI2 = new URI (abc://@20); System.out.println (oURI1.equals(oURI2)); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Unable to process ?wsdls - found out why
Title: Unable to process ?wsdls - found out why
I had been unable to get my axiscpp 1.5 installation to process ?wsdl URL's. Apache would always segfault, even though the /axis/ URL produces a web page with links to all the wsdls. As related below, I was able to work around the problem by hard-coding the path to my AXISCPP_DEPLOY tree. But the code in engine/Axis.cpp doesn't work.
Anyway, some other things I noticed once I got WSDL's to my browser:
1) The code that puts out the service list page seems to work from the server.wsdd file, not the wsdl's directory. Since the wsdl display code uses a simple fopen to open the wsdl file, and that's case-sensitive, some services (e.g. Calculator) where the service name and wsdl don't match case don't work.
2) My browser (Firefox) displays the wsdl as what looks like a form with a bunch of input fields, even though 'View Page Source' shows it as nicely-formatted xml. Firefox displays my trading partner's asmx?wsml file as formatted xml directly, and IE displays the axis-generated wsdl directly. Is this a mime-type issue? I know IE tends to guess file types when the mime type is wrong more than mozilla-based browsers do.
Here's where the problem code is. Haven't been able to code a real fix yet (and have only been able to debug by putting out some HTML and returning before the code that segfaults - there must be a better way?):
The segfault occurs in this line in the src/engine/Axis.cpp file:
sServiceName = g_pConfig-getAxisConfProperty(AXCONF_AXISHOME);
If I replace that line with:
sServiceName = /usr/local/axiscpp_deploy/;
It works.
since the AXCONF_AXISHOME property doesn't get set up until readConfFile() is done, I also tried coding this:
if (! g_pConfig-getAxisConfProperty(AXCONF_AXISHOME)) {
g_pConfig-readConfFile();
}
sServiceName = g_pConfig-getAxisConfProperty(AXCONF_AXISHOME);
It still segfaults on the get AxisConfProperty() call, though the readConfFile call returns okay.
Finally, I tried this instead of hard-coding the 'deploy' directory;
sServiceName = getenv (AXISCPP_DEPLOY);
Also segfaults.
What's up?
R o b Y a m p o l s k y
Harris Corporation
[EMAIL PROTECTED]
(212) 303 - 4250
[Axis2] Axis2 getting started
Hi Vaidya, Code is the best starting point if you can :). But better go and have a look at the site (http://ws.apache.org/axis2/), IMHO, its the best place. Site documentation is on Axis2 M1, but the development is now coming towards another milestone. So some stuff in the site docs may also be outdated. So for the time being, you can through the existing site docs, until we come up with new set of docs. And you can post any of your questions either to dev or user list. But make sure to prefix your mail subject with [Axis2]. Regards, Chinthaka
Re: [Axis2] Proposal for adding a method in OMElement API.
Hi Jaya and all, I still find difficult to give you a method to remove namespaces. Namespaces, once defined in an element, that will be used by all of its children. So if we try to remove a namespace, that will be a total mess. Isn't it ? So I'm in doubt to give *any* of the methods to remove namespaces . Regards, Chinthaka
Re: [Axis2] Proposal for adding a method in OMElement API.
agreed .. way it is done .. remeove a name sapces can be tricky Do we need to edit the OM to that extent ? mostly it is reading that we do ...I think but are there lot of usecases? .. there is security .. but it replace body or a header Can not we live with what we have? Thanks Srinath On 5/25/05, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Jaya and all, I still find difficult to give you a method to remove namespaces. Namespaces, once defined in an element, that will be used by all of its children. So if we try to remove a namespace, that will be a total mess. Isn't it ? So I'm in doubt to give *any* of the methods to remove namespaces . Regards, Chinthaka
Re: [Axis2] Proposal for adding a method in OMElement API.
Hi all, Well since our OMElementImpl keeps its own list of namespaces adding / declaring a namespace would affect that Element only. if the reference is removed from the parent I don't see a problem with the children since they keep their own reference to the particular namespace. We ask for a mandatory namespace at creation, rememebr ? The only thing that will not be elegant is the serialization.(I don't see a problem though. The serializer handles it right and generates a sematically valid XML. That generated XML is not elegant) So even though a non-used namspace does no harm (except serializing it on the declared element making the XML ugly) we can techinically remove it without a problem.On 5/25/05, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Jaya and all,I still find difficult to give you a method to remove namespaces.Namespaces, once defined in an element, that will be used by all of itschildren. So if we try to remove a namespace, that will be a total mess. Isn't it ?So I'm in doubt to give *any* of the methods to remove namespaces .Regards,Chinthaka-- Ajith Ranabahu
Re: [Axis2] Proposal for adding a method in OMElement API.
Okay - the usecase we have is the following method in SAAJ API on javax.xml.soap.SOAPElement: boolean removeNamespaceDeclaration(java.lang.String prefix) We can't implement this without the undelying OM design catering to such needs. So here goes my +1 for implmenting this method on OMElement. Regarding the uniqueness of prefix, i dont think it is an issue, because every element has its own hashmap object for namespaces, and for one prefix, there can be only one namespace in the scope, so removal such namespace will not affect other elements or other namespaces, i guess. When in doubt, lets vote :-) - Venkat On 5/25/05, Ajith Ranabahu [EMAIL PROTECTED] wrote: Hi all, Well since our OMElementImpl keeps its own list of namespaces adding / declaring a namespace would affect that Element only. if the reference is removed from the parent I don't see a problem with the children since they keep their own reference to the particular namespace. We ask for a mandatory namespace at creation, rememebr ? The only thing that will not be elegant is the serialization.(I don't see a problem though. The serializer handles it right and generates a sematically valid XML. That generated XML is not elegant) So even though a non-used namspace does no harm (except serializing it on the declared element making the XML ugly) we can techinically remove it without a problem. On 5/25/05, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Jaya and all, I still find difficult to give you a method to remove namespaces. Namespaces, once defined in an element, that will be used by all of its children. So if we try to remove a namespace, that will be a total mess. Isn't it ? So I'm in doubt to give *any* of the methods to remove namespaces . Regards, Chinthaka -- Ajith Ranabahu
Re: [Axis2] Proposal for adding a method in OMElement API.
Since most likely OM will be built through generated code, I'm wondering why this method is required. --dasarath --- Eran Chinthaka [EMAIL PROTECTED] wrote: Hi Jaya and all, I still find difficult to give you a method to remove namespaces. Namespaces, once defined in an element, that will be used by all of its children. So if we try to remove a namespace, that will be a total mess. Isn't it ? So I'm in doubt to give *any* of the methods to remove namespaces . Regards, Chinthaka __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
