[jira] Created: (AXIS2C-729) Code Formatting in Guththila and data type formatting
Code Formatting in Guththila and data type formatting - Key: AXIS2C-729 URL: https://issues.apache.org/jira/browse/AXIS2C-729 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: Current (Nightly) Environment: Unix Reporter: Lahiru Gunathilake Priority: Minor Fix For: Current (Nightly) There are some unformatted codings in Guththila Parser code and some other data type formating are not there. As an example in guththila.h file data type, char is defined as guththila_chat_t but most of the places it doesn't use that defined data type but used char again.And there are some other unformatted codings in all the header files and source files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-729) Code Formatting in Guththila and data type formatting
[ https://issues.apache.org/jira/browse/AXIS2C-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-729: -- Attachment: svn_diff I've done all the code formattings and converted data types in to standard guththila data types. Code Formatting in Guththila and data type formatting - Key: AXIS2C-729 URL: https://issues.apache.org/jira/browse/AXIS2C-729 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: Current (Nightly) Environment: Unix Reporter: Lahiru Gunathilake Priority: Minor Fix For: Current (Nightly) Attachments: svn_diff There are some unformatted codings in Guththila Parser code and some other data type formating are not there. As an example in guththila.h file data type, char is defined as guththila_chat_t but most of the places it doesn't use that defined data type but used char again.And there are some other unformatted codings in all the header files and source files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-729) Code Formatting in Guththila and data type formatting
[ https://issues.apache.org/jira/browse/AXIS2C-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Gunathilake updated AXIS2C-729: -- Attachment: guththila_formattings I've done all the code formattings and converted data types in to standard guththila data types. Code Formatting in Guththila and data type formatting - Key: AXIS2C-729 URL: https://issues.apache.org/jira/browse/AXIS2C-729 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: Current (Nightly) Environment: Unix Reporter: Lahiru Gunathilake Priority: Minor Fix For: Current (Nightly) Attachments: guththila_formattings, svn_diff There are some unformatted codings in Guththila Parser code and some other data type formating are not there. As an example in guththila.h file data type, char is defined as guththila_chat_t but most of the places it doesn't use that defined data type but used char again.And there are some other unformatted codings in all the header files and source files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1079) WSDL2Java issue: Problem creating methods to access type in generated document, restrictions placed on simpleType is not enforced in code, simpleType declared as long, bu
[ https://issues.apache.org/jira/browse/AXIS2-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amila Chinthaka Suriarachchi resolved AXIS2-1079. - Resolution: Won't Fix the problems you have mentioned are problems with the xmlbeans generated code. So please have a look at by generating code directly with the scomp command. WSDL2Java issue: Problem creating methods to access type in generated document, restrictions placed on simpleType is not enforced in code, simpleType declared as long, but accessed as int in document --- Key: AXIS2-1079 URL: https://issues.apache.org/jira/browse/AXIS2-1079 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: databinding Affects Versions: 0.92 Environment: Windows XP, java - 1.4.2_11 Reporter: Marius Hugo Assignee: Amila Chinthaka Suriarachchi Attachments: MerchantCatalogRequest.xsd, TradeRootMerchantTypes.xsd, TradeRootPayment.wsdl When I try and generate the code using WSDL2java, I get an extra set of methods in the generated documents. These are the methods that are there to access fields stored in the request. As an example, I declared a simpleType, SessionId, of type long with minInclusive and maxInclusive restrictions. It generates the code for the SessionId type and that type is used in the requests and responses. Also, I do not see these restrictions imposed in the code. As another example: I restrict the length that a string can take on, but there is no such restriction in the code. Enumeration seems to work fine for strings though and the code is present for those kinds of restrictions. WSDL2Java generates, as an example, a set of methods for a document as follows: - int getSessionId(); - com.company.product.webservice.types.SessionId xgetSessionId(); There are 2 pairs (one preceded with an x) in the generated document for any form of simpleTypes. Another issue to note, is that SessionId is declared as type long, but it can be accessed as an int. The first method, should not be there in my opinion. I have no idea which one to use and which value would be put in the SOAP message. If, for instance, I were to put different values in both??? In summary: - Generates two sets of methods for each simpleType that has been declared to be used in a request/response.- - Changed the type for SessionId from long to int in one of the methods. - Restrictions are only enforced in the code for restrictions of type enumaration, although I'm not too sure on the standard protocol or use for restrictions, as I am new to xml and axis. I have attached 3 files to provide all the necessary information. I used the following command to execute the WSDL2Java ./WSDL2Java.sh -uri c:/test_folder/wsdl/TradeRootPayment.wsdl -ss -sd -g -o c:/test_folder/final_test -p com.traderoot.merchant.webservice -ns2p urn:traderoot:names:tc:merchant:1.0:payment=com.traderoot.merchant.webservice,urn:traderoot:names:tc:merchant:1.0:core=com.traderoot.merchant.webservice.types -ssi -u -d xmlbeans -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3283) No access to the operationContextMap in the ConfigurationContext class
No access to the operationContextMap in the ConfigurationContext class -- Key: AXIS2-3283 URL: https://issues.apache.org/jira/browse/AXIS2-3283 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Affects Versions: 1.3 Reporter: Alexander Koezle I'm upgrading my existing code based on axis 1.1 to the 1.3 version and I get a following problem: I used the ConfigurationContext#getOperationContextMap method to check if the map is empty or still has any registered operation contexts. I use that e.g. during the application shutdown to test, if some service calls are still running (e.g. if using non blocking calls). In 1.3 version the operationContextMap has only private access, so i can't check if it is empty or not. So i would like to have something like isAnyOperationContextRegistered() method in the ConfigurationContext class. If there is another way to the information I need, please let me now. regards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1831) There is a bug in generated stub, it can not get AxisFault detail or reason when server side respond with an envelope that has fault string and fault detail
[ https://issues.apache.org/jira/browse/AXIS2-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amila Chinthaka Suriarachchi resolved AXIS2-1831. - Resolution: Fixed I tested this and works fine. here when throwing the exception you have to set the fault element. like this, FaultMessage faultMessage = new FaultMessage(test fault message); FaultElement faultElement = new FaultElement(); faultElement.setParam(test param); faultMessage.setFaultMessage(faultElement); throw faultMessage; There is a bug in generated stub, it can not get AxisFault detail or reason when server side respond with an envelope that has fault string and fault detail Key: AXIS2-1831 URL: https://issues.apache.org/jira/browse/AXIS2-1831 Project: Axis 2.0 (Axis2) Issue Type: Bug Environment: window Reporter: Na Wang Assignee: Amila Chinthaka Suriarachchi Priority: Critical There is a bug in generated stub, when server send a fault SOAP envelope, the generated sub couldn't get the AxisFault detail and reason, it only get the faultString. So AXIS2 client has no way of knowing the server side fault detail or reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-2594) Using attributeFormDefault=qualified in a schema causes null attribute values in Java objects
[
https://issues.apache.org/jira/browse/AXIS2-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amila Chinthaka Suriarachchi resolved AXIS2-2594.
-
Resolution: Fixed
please reopen this issue with your wsdl or a wsdl to show your problem if it
still exists.
Using attributeFormDefault=qualified in a schema causes null attribute
values in Java objects
---
Key: AXIS2-2594
URL: https://issues.apache.org/jira/browse/AXIS2-2594
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Affects Versions: 1.1.1
Environment: Windows XP
Java 1.6.0
XMLBeans data binding
Reporter: Paul Chisholm
Assignee: Amila Chinthaka Suriarachchi
Priority: Critical
When the schema that appears in the wsdl:types section of a WSDL file
specifies attributeFormDefault=qualified then the the getter corresponding
to an attribute returns null even though an attribute value is specified in
the XML.
Example:
Schema is
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
attributeFormDefault=qualified
elementFormDefault=qualified
targetNamespace=http://quickstart.samples/xsd;
xs:element name=attribute
xs:complexType
xs:sequence
xs:element name=value nillable=true type=xs:string /
/xs:sequence
xs:attribute name=status type=xs:string /
/xs:complexType
/xs:element
xs:element name=attributeResponse
xs:complexType
xs:sequence
xs:element name=value nillable=true type=xs:string /
/xs:sequence
xs:attribute name=status type=xs:string /
/xs:complexType
/xs:element
/xs:schema
Message/port definition is
wsdl:message name=attributeMessage
wsdl:part name=part1 element=ns:attribute/
/wsdl:message
wsdl:message name=attributeResponseMessage
wsdl:part name=part1 element=ns:attributeResponse/
/wsdl:message
wsdl:portType name=MyServicePortType
wsdl:operation name=attribute
wsdl:input message=axis2:attributeMessage/
wsdl:output message=axis2:attributeResponseMessage/
/wsdl:operation
/wsdl:portType
Client code is
public static void attribute(MyServiceStub stub){
try{
AttributeDocument reqDoc =
AttributeDocument.Factory.newInstance();
AttributeDocument.Attribute req = reqDoc.addNewAttribute();
req.setStatus(OK);
req.setValue(Testing);
AttributeResponseDocument res = stub.attribute(reqDoc);
System.err.println(Status=+res.getAttributeResponse().getStatus());
System.err.println(Value=+res.getAttributeResponse().getValue());
} catch(Exception e){
e.printStackTrace();
System.err.println(\n\n\n);
}
}
Service code is
public AttributeResponseDocument attribute(AttributeDocument param1) {
String status = param1.getAttribute().getStatus();
String value = param1.getAttribute().getValue();
System.err.println();
System.err.println(Status=+status);
System.err.println(Value=+value);
AttributeResponseDocument resDoc =
AttributeResponseDocument.Factory.newInstance();
AttributeResponseDocument.AttributeResponse res =
resDoc.addNewAttributeResponse();
res.setStatus(status);
res.setValue(value);
return resDoc;
}
When the client is run tracing of the element values displays as expected,
but tracing of the attributes always shows null.
If the schema is changed to attributeFormDefault=unqualified the attribute
values are displayed successfully.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3284) MEX module does not contain implementation class files after build
MEX module does not contain implementation class files after build -- Key: AXIS2-3284 URL: https://issues.apache.org/jira/browse/AXIS2-3284 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: modules Affects Versions: nightly Environment: Windows Vista, Eclipse 3.3 with WTP 2 and Apache Tomcat 6.0.14 Reporter: CCob The mex-mar module doesn't seem to be including the mex-impl contents so when the mex module is attempted to be deployed a DeploymentException is thrown which is caused by an ClassNotFoundException as the .class files are not present within the mex module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3252) Unexpected subelement
[ https://issues.apache.org/jira/browse/AXIS2-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amila Chinthaka Suriarachchi reassigned AXIS2-3252: --- Assignee: Amila Chinthaka Suriarachchi Unexpected subelement -- Key: AXIS2-3252 URL: https://issues.apache.org/jira/browse/AXIS2-3252 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.2 Reporter: adam Assignee: Amila Chinthaka Suriarachchi Priority: Critical Attachments: the classes.rar Hi, I try to make web service with eclipse and axis2 .. and i recieve the following exception and i don't know what is the casue : Exception *: Exception in thread main java.lang.RuntimeException: java.lang.RuntimeException: Unexpected subelement medicineId at com.cliniccruise.ws.MainClassForWSMainClassForWSSOAP11Port_httpStub.fromOM(MainClassForWSMainClassForWSSOAP11Port_httpStub.java:19136) at com.cliniccruise.ws.MainClassForWSMainClassForWSSOAP11Port_httpStub.sendMedicenObjetct(MainClassForWSMainClassForWSSOAP11Port_httpStub.java:159) at com.cliniccruise.ws.WSClient.main(WSClient.java:20) Caused by: java.lang.RuntimeException: Unexpected subelement medicineId at com.cliniccruise.ws.MainClassForWSMainClassForWSSOAP11Port_httpStub$MedicineWVO$Factory.parse(MainClassForWSMainClassForWSSOAP11Port_httpStub.java:14748) at com.cliniccruise.ws.MainClassForWSMainClassForWSSOAP11Port_httpStub$SendMedicenObjetctResponse$Factory.parse(MainClassForWSMainClassForWSSOAP11Port_httpStub.java:988) at com.cliniccruise.ws.MainClassForWSMainClassForWSSOAP11Port_httpStub.fromOM(MainClassForWSMainClassForWSSOAP11Port_httpStub.java:19130) ... 2 more The class that i make from it the web service is : MainClassForWS and my client test is : WSClient All the class relative to this exception in the attachment file i need to know from where this exception come and what causes it and what is the solution for it . Thanks. M.adam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3055) add an option not to generate xmlbeans classes and instead get them from classpath
[ https://issues.apache.org/jira/browse/AXIS2-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amila Chinthaka Suriarachchi resolved AXIS2-3055. - Resolution: Fixed added a new parameter -Ewdc to generate with a dummy schema. then you can replace this with the correct xmlbeans generated code. add an option not to generate xmlbeans classes and instead get them from classpath -- Key: AXIS2-3055 URL: https://issues.apache.org/jira/browse/AXIS2-3055 Project: Axis 2.0 (Axis2) Issue Type: New Feature Affects Versions: 1.2 Reporter: Michael Mattox Assignee: Amila Chinthaka Suriarachchi Priority: Minor With XFire, when generating the java code from the WSDL, XFire looks on the classpath for the xmlbeans and if they're there, XFire does not generate them. This would be very useful with Axis2. At the moment, I do not believe there is any way to avoid having Axis2 generate the xmlbeans classes. In my particular case I found a bug with this generation (https://issues.apache.org/jira/browse/AXIS2-3048), and the workaround is to empty out all my elements and complex types and use wsdl2java and then generate the classes from the real schemas with xmlbeans. Kind of cumbersome. I prefer to have xmlbeans generate my classes and axis2 generate the web service related files. That way I keep the two separate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Proposal to implement http content negotiation
Hi folks: +1 from me *if* we make sure there's a flag to allow people to control whether a given operation supports POX or not. Essentially I'm just saying we should backport the SOAP-Response MEP to SOAP 1.1, and allow the user to specify. By default the behavior should be as in Keith's proposal, but if they indicate that a particular operation is using the SOAP-Response MEP (this could also be a disablePOX flag or whatever), it should always return SOAP on a GET. Also... a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? --Glen Sanjiva Weerawarana wrote: +1 from me. For some further discussion on this see [1]. In particular [2] gives rationale for why its ok to give more weight to POX over SOAP 1.1. Sanjiva. [1] http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html keith chapman wrote: Hi Devs, There have been some thought on http content negotiation. With the concept of builders and formatters we have now this could be implemented trivially. The idea is to use the Accept http header to serve the response requested by the client. While going through this though I came across a issue though. This occurs when a request is sent via a GET using a browser (Cause the browser automatically adds the Accept http header). The Accept header sent by firefox is Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. The confusion comes in because text/xml is used for both SOAP and REST responses. I believe having http content negotiation as a feature will be a nice addition to Axis2. And I propose that we treat text/xml as a REST response in implementing this. This would mean that you cannot ask for a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). What do u think? Should we go ahead and implement this proposal? Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing the SOAP header of the code generated by WDSL2Java?
Hello, The request header looks like follows: ns3:metadata soapenv:mustUnderstand=0 xmlns:ns3=http://metadata.ntpsoa.nordea.com/object; However, the server requires the following header: mo:metadata schemaVersion=String xsi:schemaLocation=http://metadata.ntpsoa.nordea.com/object/Metadata.xs d xmlns:mo=http://metadata.ntpsoa.nordea.com/object; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; What can I do to resolve the problem? Thanks, Patrik
[Axis2]. Subscribe Changing the SOAP header of the code generated by WDSL2Java?
Hello, The request header looks like follows: ns3:metadata soapenv:mustUnderstand=0 xmlns:ns3=http://metadata.ntpsoa.nordea.com/object; However, the server requires the following header: mo:metadata schemaVersion=String xsi:schemaLocation=http://metadata.ntpsoa.nordea.com/object/Metadata.xs d xmlns:mo=http://metadata.ntpsoa.nordea.com/object; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; What can I do to resolve the problem? Thanks, Patrik
Re: Axis 2 webservice in Weblogic 8.1 - Must Understand check failed for header
Hi Rajesh, IFAIK, this in not because of your configuration problem. This happens if you get a fault message from the server (eg. HTTP/1.1 500 ) , the message returns through the InFaultFlow and rampart, at the moment, doesn't register any handlers in Fault Flows. Simply, security header doesn't get processed in Fault flow and axis throws an error because it is a must understand header. If you can post the soap response, we can see whether it is a fault response. If this is the problem, you can do a quick fix by registering rampart handlers in the InFaultFlow. Regards, Nandana On 10/17/07, Rajesh, Peter (CLAIMS, WIP) [EMAIL PROTECTED] wrote: Thanks Dimuthu for you reply. After I add the System.setProperty with the proper keystore and password and if I execute the java test client I get below exception. Any idea what is the reason for this error? Am I missing anything in the configuration? [java] org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secex t-1.0.xsd : Security [java] at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java :486) [java] at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(Out InAxisOperation.java:343) [java] at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOper ation.java:389) [java] at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInA xisOperation.java:211) [java] at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163 ) [java] at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528 ) [java] at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:508 ) Thanks Regards, Peter Rajesh | 860-547-3881 -Original Message- From: Dimuthu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 11:55 PM To: [EMAIL PROTECTED] Subject: Re: Axis 2 webservice in Weblogic 8.1 - SSLHandshakeException Hi, The exception says No trusted certificate found. If the server certificate is not a widely accepted certificate, i.e. if it doesn't chain to one of the entries in JAVA_HOME/jre/lib/security/cacerts then you have to set some system properties as follows. System.setProperty(javax.net.ssl.trustStore,yourpath/keystore.jks); System.setProperty(javax.net.ssl.trustStorePassword, password); System.setProperty(javax.net.ssl.trustStoreType,JKS); Regards, Dimuthu On Tue, 2007-10-16 at 15:45 -0400, Rajesh, Peter (CLAIMS, WIP) wrote: Hi, I have deployed Axis 2 webserivce in Weblogic 8.1 server with SSL enabled and when I execute the simple java client to access the webservice below error is thrown Please help to resolve this issue. [java] org.apache.axis2.AxisFault: sun.security.validator.ValidatorException: No trusted certificate found . Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found Thanks Regards, Peter Rajesh ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** -- http://wso2.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Proposal to implement http content negotiation
On 10/18/07, Glen Daniels [EMAIL PROTECTED] wrote: Hi folks: +1 from me *if* we make sure there's a flag to allow people to control whether a given operation supports POX or not. Essentially I'm just saying we should backport the SOAP-Response MEP to SOAP 1.1, and allow the user to specify. By default the behavior should be as in Keith's proposal, but if they indicate that a particular operation is using the SOAP-Response MEP (this could also be a disablePOX flag or whatever), How about using the disable REST flag for this without introducing another flag. it should always return SOAP on a GET. Also... a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? In this case the return will be the return will be SOAP 1.1 only is there was no matching ACCEPT header. Id a SOAP 1.1. request came with the header ACCEPT : text/xml then the response will be pox. Thanks, Keith. --Glen Sanjiva Weerawarana wrote: +1 from me. For some further discussion on this see [1]. In particular [2] gives rationale for why its ok to give more weight to POX over SOAP 1.1. Sanjiva. [1] http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html keith chapman wrote: Hi Devs, There have been some thought on http content negotiation. With the concept of builders and formatters we have now this could be implemented trivially. The idea is to use the Accept http header to serve the response requested by the client. While going through this though I came across a issue though. This occurs when a request is sent via a GET using a browser (Cause the browser automatically adds the Accept http header). The Accept header sent by firefox is Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5. The confusion comes in because text/xml is used for both SOAP and REST responses. I believe having http content negotiation as a feature will be a nice addition to Axis2. And I propose that we treat text/xml as a REST response in implementing this. This would mean that you cannot ask for a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). What do u think? Should we go ahead and implement this proposal? Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/
[jira] Created: (AXIS-2702) Https Support in axis1.2.1
Https Support in axis1.2.1 -- Key: AXIS-2702 URL: https://issues.apache.org/jira/browse/AXIS-2702 Project: Axis Issue Type: Bug Environment: sun solaris , iPlanet 6 Reporter: Manoj Kumar Pradhan we develop a webservice using axis1.2.1 , when we deploy in our Test enviornment which is support only Https , we unable to consume the webservcie , 1. the wsdl is generating but location url is not comming https , still it is coming http:// . 2.I have written a test client using axis1.2.1 ( no stub ) , I am using Call.setOperationName( new QName ( https://myurl/my.jws; ) ; Call.invoke(...) ; Pls advice on following. 1. Whether i nedd some special set up for Https support . 2. How to write a client program for https enabled webservice . Pls replay as soon as possible . with Thanks manoj -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3277) jaxen-LICENCE.txt should have jaxen licence text rather than Apache v2.0
[ https://issues.apache.org/jira/browse/AXIS2-3277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle reassigned AXIS2-3277: - Assignee: Rich Scheuerle jaxen-LICENCE.txt should have jaxen licence text rather than Apache v2.0 Key: AXIS2-3277 URL: https://issues.apache.org/jira/browse/AXIS2-3277 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: documentation Affects Versions: 1.4, 1.3 Reporter: Tom Seelbach Assignee: Rich Scheuerle Priority: Minor Fix For: 1.3 Attachments: LICENSE.txt The jaxen-LICENSE.txt has a copy of the Apache 2 license. http://svn.apache.org/viewvc/webservices/axis2/trunk/java/legal/jaxen-LICENSE.txt?revision=553578view=markup The license in the jaxen 1.1.1 distro is not the Apache license. Shouldn't jaxen-LICENSE.txt be a copy of the LICENSE.txt from jaxen v1.1.1 ? I will attach a copy... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3285) NullpointerException in AbstractHTTPHeader
NullpointerException in AbstractHTTPHeader
--
Key: AXIS2-3285
URL: https://issues.apache.org/jira/browse/AXIS2-3285
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel
Affects Versions: 1.3
Environment: Windows 32, Java 1.5_11
Reporter: Martin Genhart
The nullpointer happens in the following method if a cookie does not have any
parameters:
private String processCookieHeader(HeaderElement element) {
String cookie = element.getName() + = + element.getValue();
NameValuePair[] parameters = element.getParameters();
for (int j = 0; j parameters.length; j++) {
NameValuePair parameter = parameters[j];
cookie = cookie + ; + parameter.getName() + = +
parameter.getValue();
}
return cookie;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3285) NullpointerException in AbstractHTTPHeader
[
https://issues.apache.org/jira/browse/AXIS2-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Genhart updated AXIS2-3285:
--
Attachment: AbstractHTTPSender.java
Fixed version of AbstractHTTPSender:
private String processCookieHeader(HeaderElement element) {
String cookie = element.getName() + = + element.getValue();
NameValuePair[] parameters = element.getParameters();
for (int j = 0; parameters != null j parameters.length; j++) {
NameValuePair parameter = parameters[j];
cookie = cookie + ; + parameter.getName() + = +
parameter.getValue();
}
return cookie;
}
NullpointerException in AbstractHTTPHeader
--
Key: AXIS2-3285
URL: https://issues.apache.org/jira/browse/AXIS2-3285
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel
Affects Versions: 1.3
Environment: Windows 32, Java 1.5_11
Reporter: Martin Genhart
Attachments: AbstractHTTPSender.java
The nullpointer happens in the following method if a cookie does not have any
parameters:
private String processCookieHeader(HeaderElement element) {
String cookie = element.getName() + = + element.getValue();
NameValuePair[] parameters = element.getParameters();
for (int j = 0; j parameters.length; j++) {
NameValuePair parameter = parameters[j];
cookie = cookie + ; + parameter.getName() + = +
parameter.getValue();
}
return cookie;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3286) Spring AOP integration. Follow up on thread (AXIS2-3258)
Spring AOP integration. Follow up on thread (AXIS2-3258) Key: AXIS2-3286 URL: https://issues.apache.org/jira/browse/AXIS2-3286 Project: Axis 2.0 (Axis2) Issue Type: Test Affects Versions: 1.3 Environment: Java, Spring AOP Reporter: Rakesh Hi, I was looking at the resolution for the problem of using Spring AOP. I get an exception The following error occurred during schema generation: Unable to load bytecode for class abc.skl.ServiceProvider$$EnhancerByCGLIB$$4a4e81cb The thread AXIS2-3258 has a solution where you introduce an interface as ServiceClass along with ServiceObjectSupplier. My question is does this mean that my implementation class should now be split into an interface with all the method signatures and then provide an implementation class for this interface. And do this for all the services. The problem is that we are building an internal framework and will be extended by other systems. So if we do put this condition, then all subsystems will have to be modified to do the same too. Is it possible that I simply the provider class itself as the ServiceClass and also have the ServiceObjectProvider in place. Can someone please confirm my understanding. Thanks, Rakesh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3199) Java2WSDL output for no parameters or void return type
[ https://issues.apache.org/jira/browse/AXIS2-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535945 ] Chris Rose commented on AXIS2-3199: --- I'm seeing the same issue: Our application has a number of basic information retrieval methods, for example: VersionBean getVersion(); Our WSDL for this is: xs:element name='getVersion' xs:complexType / /xs:element xs:element name='getVersionResponse' type='tns:getVersionResponse'/ xs:complexType name='getVersionResponse' xs:sequence xs:element minOccurs='0' name='return' type='ns2:versionBean'/ /xs:sequence /xs:complexType xs:complexType name='version' xs:sequence !-- ... various version fields -- /xs:sequence /xs:complexType xs:complexType name='versionBean' xs:complexContent xs:extension base='ns1:version' xs:sequence/ /xs:extension /xs:complexContent /xs:complexType message name='Service_getVersion' part element='ns1:getVersion' name='parameters'/ /message message name='Service_getVersionResponse' part element='ns1:getVersionResponse' name='getVersionResponse'/ /message portType name='Service' operation name='getVersion' parameterOrder='getVersion' input message='ns1:Service_getVersion'/ output message='ns1:Service_getVersionResponse'/ /operation /portType From this we get a Service skeleton interface with a getVersion method, which is good, but instead of a getVersion() method, we have a getVersion(GetVersion) method, and the GetVersion class is a bean... with no properties. This does not correspond to the implementation of the method at all. Java2WSDL output for no parameters or void return type -- Key: AXIS2-3199 URL: https://issues.apache.org/jira/browse/AXIS2-3199 Project: Axis 2.0 (Axis2) Issue Type: Bug Reporter: Deepal Jayasinghe Assignee: Deepal Jayasinghe Deepal, Per the wrapped convention, if you have the following interface: public String foo(); java2wsdl should generate an input element called foo: w:message name=fooRequest w:part name=parameters element=t:foo/ /w:message And foo must be defined as: s:element name=foo /s:complexType /s:element See the JAX-WS spec for the specific requirements of the wrapped convention, or my blog for a quick overview: http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html Anne -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3286) Spring AOP integration. Follow up on thread (AXIS2-3258)
[ https://issues.apache.org/jira/browse/AXIS2-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535967 ] robert lazarski commented on AXIS2-3286: Hmm, CGLIB indicates you have hibernate mixed in somehow. When you say during schema generation - are you implying java2wsdl ? Apart from the interface question - which generally is a good idea anyways as it allows a different implementation for each project, which is a nice plus for spring beans and pluggability - there isn't enough info here to understand your problem. Furthermore, could you try clarifying what you mean by Is it possible that I simply the provider class itself as the ServiceClass and also have the ServiceObjectProvider in place. Spring AOP integration. Follow up on thread (AXIS2-3258) Key: AXIS2-3286 URL: https://issues.apache.org/jira/browse/AXIS2-3286 Project: Axis 2.0 (Axis2) Issue Type: Test Affects Versions: 1.3 Environment: Java, Spring AOP Reporter: Rakesh Hi, I was looking at the resolution for the problem of using Spring AOP. I get an exception The following error occurred during schema generation: Unable to load bytecode for class abc.skl.ServiceProvider$$EnhancerByCGLIB$$4a4e81cb The thread AXIS2-3258 has a solution where you introduce an interface as ServiceClass along with ServiceObjectSupplier. My question is does this mean that my implementation class should now be split into an interface with all the method signatures and then provide an implementation class for this interface. And do this for all the services. The problem is that we are building an internal framework and will be extended by other systems. So if we do put this condition, then all subsystems will have to be modified to do the same too. Is it possible that I simply the provider class itself as the ServiceClass and also have the ServiceObjectProvider in place. Can someone please confirm my understanding. Thanks, Rakesh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3282) Getting error while deploying web service made using Axis2.1.3
[ https://issues.apache.org/jira/browse/AXIS2-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ayondeep Datta closed AXIS2-3282. - Resolution: Fixed Fix Version/s: 1.3 I replaced wsdl4j.jar present in the lib of JBoss with the wsdl4j-1.6.2.jar and it resolved this issue. Getting error while deploying web service made using Axis2.1.3 -- Key: AXIS2-3282 URL: https://issues.apache.org/jira/browse/AXIS2-3282 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: adb, wsdl Affects Versions: 1.3 Environment: JBoss 4, Axis2-1.3, J2SE1.4.2 Reporter: Ayondeep Datta Fix For: 1.3 I have created a service archive file for the StockQuoteService example provided by the standard binary distribution o using ant generate.service method. I am deploying it in JBoss 4 and getting this error Error: java.lang.NoSuchMethodError: javax.wsdl.Operation.getExtensibilityElements()Ljava/util/List; at org.apache.axis2.description.WSDL11ToAxisServiceBuilder.populateOperations(WSDL11ToAxisServiceBuilder.java:1241) at The default Version service is working fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3280) IntelliJ Service Archiver class file browser not working
[ https://issues.apache.org/jira/browse/AXIS2-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536002 ] Ayondeep Datta commented on AXIS2-3280: --- This is my bad. The browser was to locate class file location and not a class file. IntelliJ Service Archiver class file browser not working Key: AXIS2-3280 URL: https://issues.apache.org/jira/browse/AXIS2-3280 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.3 Environment: Intellij 7.0, Axis-21.3, J2SE1.4.2 Reporter: Ayondeep Datta I have installed IntelliJ Axis2.1.3 plugin successfuly. When I try to create a service archiver and browse through the browser button I cannot see any files. All though files of type shows All File I cannot see any type of files. Only I can see are the folders. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3280) IntelliJ Service Archiver class file browser not working
[ https://issues.apache.org/jira/browse/AXIS2-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ayondeep Datta closed AXIS2-3280. - Resolution: Fixed The browser was to locate class file location and not a class file. IntelliJ Service Archiver class file browser not working Key: AXIS2-3280 URL: https://issues.apache.org/jira/browse/AXIS2-3280 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.3 Environment: Intellij 7.0, Axis-21.3, J2SE1.4.2 Reporter: Ayondeep Datta I have installed IntelliJ Axis2.1.3 plugin successfuly. When I try to create a service archiver and browse through the browser button I cannot see any files. All though files of type shows All File I cannot see any type of files. Only I can see are the folders. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Delegate MustUnderstand header check to MessageReceiver
I would like to propose a change to handle certain situations in jaxws
where we need to postpone the must understand header check from the
AxisEngine to the MessageReceiver. For example, in case of jaxws handler,
an application can choose to implement getHeaders() and choose to add
valid header qnames in that implementation. A mustUnderstand validation
needs to happen for this scenario as described in section 10.2.1 of jaxws
specification, in this situation if the jaxws handlers are not loaded, the
must understand checks has to be postponed from AxisEngine until the
handler are loaded and available in jaxws implementation.
Currently all the must understand processing happens in AxisEngine's
receive() method, I would like to provide a facility in AxisEngine code
where we can choose to delegate MustUnderstand Check to a Message
Receiver. I would like to propose addition of a new interface called
MessageReceiverExtension in Kernel module which has a method
isMustUnderstandCheckPostponed, this new interface will be implemented by
JAXWSMessageReceiver and will help in making the runtime decision to
postpone must understand check in AxisEngine code.
Attached is the patch with proposed changes.
Nikhil Thaker
office: 512 838 9964
[EMAIL PROTECTED]Index:
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/Constants.java
===
---
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/Constants.java
(revision 3243)
+++
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/Constants.java
(working copy)
@@ -241,7 +241,12 @@
* from SOAPFault to AxisFault
*/
public static final String INBOUND_FAULT_OVERRIDE = inboundFaultOverride;
-
+
+/**
+ * This is used to store Header QNames that failed mustUnderstand check.
+ */
+public static final String FAULTY_HEADER_QNAMES = faultyHeaderQNames;
+
public static interface Configuration {
public static final String ENABLE_REST = enableREST;
public static final String ENABLE_REST_THROUGH_GET = restThroughGet;
@@ -329,6 +334,7 @@
* @see org.apache.axis2.transport.MessageFormatter
*/
public static final String MESSAGE_TYPE = messageType;
+
}
}
Index:
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/MessageReceiverExtension.java
===
---
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/MessageReceiverExtension.java
(revision 0)
+++
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/MessageReceiverExtension.java
(revision 0)
@@ -0,0 +1,19 @@
+package org.apache.axis2.engine;
+/*
+ * MessageReceiverExtension will be used to add additional functionality to
MessageReceiver.
+ * For Example MessageReceiverExtension can be used by JAXWSMessageReceiver to
validate the
+ * MustUnderstand Checks, We use this functionality in case a webservice uses
jaxws handlers and
+ * that AxisEngine does not have handler instance which get loaded later in
the webservice lifecycle.
+ *
+ */
+public interface MessageReceiverExtension{
+/**
+ * checkNonUnderstoodHeaderInFuture returns a true if the header
mustUnderstand check need to be
+ * posponed till the request is received by MessageReceiver.
+ * In some instances especially in Handler processing, the handlers are
not loaded/instantiated until the
+ * first webservice call is made. Thus header qNames that are set in
getHeaders()are not available to
+ * AxisEngine. We will use this method in such situations to pospone the
MustUnderstand Check.
+ * @return
+ */
+public boolean
isMustUnderstandCheckPostponed(org.apache.axis2.context.MessageContext
axisRequestMsgCtx);
+}
Index:
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/AxisEngine.java
===
---
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/AxisEngine.java
(revision 3243)
+++
C:/webservices/rad/WSFP_GM_092507/modules/kernel/src/org/apache/axis2/engine/AxisEngine.java
(working copy)
@@ -17,12 +17,19 @@
package org.apache.axis2.engine;
+import java.lang.reflect.Method;
+import java.util.ArrayList;
+import java.util.Iterator;
+
+import javax.xml.namespace.QName;
+
import org.apache.axiom.soap.SOAP11Constants;
import org.apache.axiom.soap.SOAP12Constants;
import org.apache.axiom.soap.SOAPConstants;
import org.apache.axiom.soap.SOAPEnvelope;
import org.apache.axiom.soap.SOAPHeaderBlock;
import org.apache.axis2.AxisFault;
+import org.apache.axis2.Constants;
import org.apache.axis2.client.async.Callback;
import org.apache.axis2.context.ConfigurationContext;
import
[jira] Created: (AXIS2-3287) ConverterUtil.convertToArray fails for boolean.class
ConverterUtil.convertToArray fails for boolean.class
Key: AXIS2-3287
URL: https://issues.apache.org/jira/browse/AXIS2-3287
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: adb, databinding
Affects Versions: 1.3, 1.4
Environment: Maven version: 2.0.7
Java version: 1.6.0_02
OS name: windows xp version: 5.1 arch: x86
Reporter: Thorsten H. Riek
Priority: Critical
Conversion ConverterUtil.convertToArray fails for
String[] testString = {true,false};
Object[] convertedObj = ConverterUtil.convertToArray( boolean.class, testString
);
The Result is:
convertedObj[0] -- false
convertedObj[1] -- false
The Problem is the conversion from String to boolean is wrong:
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray
{noformat}
} else if (boolean.class.equals(baseArrayClass)) {
boolean[] array = new boolean[listSize];
for (int i = 0; i listSize; i++) {
Object o = objectList.get(i);
if (o != null) {
array[i] = Boolean.getBoolean(o.toString());
}
}
returnArray = array;
{noformat}
array[i] = Boolean.getBoolean(o.toString()); is wrong
it should be:
array[i] = Boolean.parse(o.toString());
Here is the modified Testcase to reproduce it:
ConverterUtilTest
{noformat}
/** boolean arrays */
public void testBool() {
List l = new ArrayList();
l.add(true);
l.add(false);
l.add(true);
l.add(false);
Object convertedObj = ConverterUtil.convertToArray(
boolean.class, l);
assertTrue(convertedObj.getClass().isArray());
assertTrue(convertedObj.getClass().equals(boolean[].class));
if (convertedObj.getClass().isArray()) {
Object[] result = l.toArray();
for (int i=0;iresult.length ; i++){
System.out.println(Boolean.parseBoolean((String) result[i])+
== +((boolean[])convertedObj)[i]);
assertTrue(Boolean.parseBoolean((String)result[i])==((boolean[])convertedObj)[i]);
}
}
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3287) ConverterUtil.convertToArray fails for boolean.class
[
https://issues.apache.org/jira/browse/AXIS2-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten H. Riek updated AXIS2-3287:
Description:
Conversion ConverterUtil.convertToArray fails for
String[] testString = {true,false};
Object[] convertedObj = ConverterUtil.convertToArray( boolean.class,
testString );
The Result is:
convertedObj[0] -- false
convertedObj[1] -- false
The Problem is the conversion from String to boolean is wrong:
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray
// -
} else if (boolean.class.equals(baseArrayClass)) {
boolean[] array = new boolean[listSize];
for (int i = 0; i listSize; i++) {
Object o = objectList.get(i);
if (o != null) {
array[i] = Boolean.getBoolean(o.toString());
}
}
returnArray = array;
}
// -
array[i] = Boolean.getBoolean(o.toString()); is wrong
it should be:
array[i] = Boolean.parseBoolean(o.toString());
Here is the modified Testcase to reproduce it:
ConverterUtilTest
// -
/** boolean arrays */
public void testBool() {
List l = new ArrayList();
l.add(true);
l.add(false);
l.add(true);
l.add(false);
Object convertedObj = ConverterUtil.convertToArray(
boolean.class, l);
assertTrue(convertedObj.getClass().isArray());
assertTrue(convertedObj.getClass().equals(boolean[].class));
if (convertedObj.getClass().isArray()) {
Object[] result = l.toArray();
for (int i=0;iresult.length ; i++){
System.out.println(Boolean.parseBoolean((String) result[i])+
== +((boolean[])convertedObj)[i]);
assertTrue(Boolean.parseBoolean((String)result[i])==((boolean[])convertedObj)[i]);
}
}
}
// -
was:
Conversion ConverterUtil.convertToArray fails for
String[] testString = {true,false};
Object[] convertedObj = ConverterUtil.convertToArray( boolean.class, testString
);
The Result is:
convertedObj[0] -- false
convertedObj[1] -- false
The Problem is the conversion from String to boolean is wrong:
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray
{noformat}
} else if (boolean.class.equals(baseArrayClass)) {
boolean[] array = new boolean[listSize];
for (int i = 0; i listSize; i++) {
Object o = objectList.get(i);
if (o != null) {
array[i] = Boolean.getBoolean(o.toString());
}
}
returnArray = array;
{noformat}
array[i] = Boolean.getBoolean(o.toString()); is wrong
it should be:
array[i] = Boolean.parse(o.toString());
Here is the modified Testcase to reproduce it:
ConverterUtilTest
{noformat}
/** boolean arrays */
public void testBool() {
List l = new ArrayList();
l.add(true);
l.add(false);
l.add(true);
l.add(false);
Object convertedObj = ConverterUtil.convertToArray(
boolean.class, l);
assertTrue(convertedObj.getClass().isArray());
assertTrue(convertedObj.getClass().equals(boolean[].class));
if (convertedObj.getClass().isArray()) {
Object[] result = l.toArray();
for (int i=0;iresult.length ; i++){
System.out.println(Boolean.parseBoolean((String) result[i])+
== +((boolean[])convertedObj)[i]);
assertTrue(Boolean.parseBoolean((String)result[i])==((boolean[])convertedObj)[i]);
}
}
}
{noformat}
ConverterUtil.convertToArray fails for boolean.class
Key: AXIS2-3287
URL: https://issues.apache.org/jira/browse/AXIS2-3287
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: adb, databinding
Affects Versions: 1.4, 1.3
Environment: Maven version: 2.0.7
Java version: 1.6.0_02
OS name: windows xp version: 5.1 arch: x86
Reporter: Thorsten H. Riek
Priority: Critical
Conversion ConverterUtil.convertToArray fails for
String[] testString = {true,false};
Object[] convertedObj = ConverterUtil.convertToArray( boolean.class,
testString );
The Result is:
convertedObj[0] -- false
convertedObj[1] -- false
The Problem is the conversion from String to boolean is wrong:
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray
// -
} else if
Re: [AXIS2] Proposal to implement http content negotiation
Glen, If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? That's my understanding. I believe this is addressed in the SOAP 1.2 spec as to what constitutes a mismatch error and what kinds of responses can go back. Would this leave the existing behavior unchanged for services that declare an explicit SOAP binding in a WSDL? In other words, does this just apply to endpoints choosing to leverage a RESTful pattern/API, or will all applications be subject to negotiation? -Nick Glen Daniels [EMAIL PROTECTED] t.com To axis-dev@ws.apache.org 10/18/2007 05:41 cc AM Subject Re: [AXIS2] Proposal to implement Please respond to http content negotiation [EMAIL PROTECTED] e.org Hi folks: +1 from me *if* we make sure there's a flag to allow people to control whether a given operation supports POX or not. Essentially I'm just saying we should backport the SOAP-Response MEP to SOAP 1.1, and allow the user to specify. By default the behavior should be as in Keith's proposal, but if they indicate that a particular operation is using the SOAP-Response MEP (this could also be a disablePOX flag or whatever), it should always return SOAP on a GET. Also... a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? --Glen Sanjiva Weerawarana wrote: +1 from me. For some further discussion on this see [1]. In particular [2] gives rationale for why its ok to give more weight to POX over SOAP 1.1. Sanjiva. [1] http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html keith chapman wrote: Hi Devs, There have been some thought on http content negotiation. With the concept of builders and formatters we have now this could be implemented trivially. The idea is to use the Accept http header to serve the response requested by the client. While going through this though I came across a issue though. This occurs when a request is sent via a GET using a browser (Cause the browser automatically adds the Accept http header). The Accept header sent by firefox is Accept: text/xml,application/xml,application/xhtml +xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. The confusion comes in because text/xml is used for both SOAP and REST responses. I believe having http content negotiation as a feature will be a nice addition to Axis2. And I propose that we treat text/xml as a REST response in implementing this. This would mean that you cannot ask for a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). What do u think? Should we go ahead and implement this proposal? Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] inline: graycol.gifinline: pic21264.gifinline: ecblank.gif
[axis2] [proposal] Delegate MustUnderstand header check to MessageReceiver
Forwarding with subject tags... - Forwarded by Nicholas L Gallardo/Austin/IBM on 10/18/2007 04:16 PM - Nikhil V Thaker/Columbus/I [EMAIL PROTECTED] To axis-dev@ws.apache.org 10/18/2007 03:10 cc PM Subject Delegate MustUnderstand header Please respond to check to MessageReceiver [EMAIL PROTECTED] e.org I would like to propose a change to handle certain situations in jaxws where we need to postpone the must understand header check from the AxisEngine to the MessageReceiver. For example, in case of jaxws handler, an application can choose to implement getHeaders() and choose to add valid header qnames in that implementation. A mustUnderstand validation needs to happen for this scenario as described in section 10.2.1 of jaxws specification, in this situation if the jaxws handlers are not loaded, the must understand checks has to be postponed from AxisEngine until the handler are loaded and available in jaxws implementation. Currently all the must understand processing happens in AxisEngine's receive() method, I would like to provide a facility in AxisEngine code where we can choose to delegate MustUnderstand Check to a Message Receiver. I would like to propose addition of a new interface called MessageReceiverExtension in Kernel module which has a method isMustUnderstandCheckPostponed, this new interface will be implemented by JAXWSMessageReceiver and will help in making the runtime decision to postpone must understand check in AxisEngine code. Attached is the patch with proposed changes. Nikhil Thaker office: 512 838 9964 [EMAIL PROTECTED](See attached file: patch_with_tests.txt) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]inline: pic03524.gifinline: ecblank.gif patch_with_tests.txt Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Hi David, I agree with the proposal! Just one clarification though : Are we going to include the SecuredAddressingDispatchValidator in the addressing module? If so should we a property in the message context to point to the AxisOperation used for security configuration? Thanks, Ruchith On 10/9/07, David Illsley [EMAIL PROTECTED] wrote: As discussed a couple of months back, the current one-shot WS-Addressing header extraction isn't suited for use with security. This is because either: 1. Addressing runs before security and populates fields such as ReplyTo/FaultTo which, if later found to be invalid would not be un(de?)populated (which is a security risk). 2. Addressing runs after security, hence interoperable Operation-Level security is not possible as it relies on the WS-A Action/WS-A RelatesTo for operation identification. I've thought about this problem a fair bit and I'm of the opinion that security is important enough that we should break the WS-A headers apart and change the model slightly. The following proposal is very much open to change, but I do believe is in the right general direction. AddressingDispatchExtractor -- Extracts wsa:Action and/or wsa:RelatesTo value -- Determines the correct AxisOperation/OperationContext for security -- Does not set them in normal place on message context in case they are invalid -- Places them on message context as properties -- Sets WS-A namespace on message context to allow security + later WS-A handers to proces the correct headers SecurityHandler(s) -- Configured based on the AxisOperation extracted by the AddressingDispatchExtractor -- Validates the WS-A headers with the selected namespace (if appropriate) AddressingRemainderInHandler -- Extracts remaining WS-A headers and sets them on the MessageContext -- Amalgem of AddressingFinalInHandler and AddressingSubmissionInHandler -- Namespace has already been selected so makes sense to combine General Dispatchers SecuredAddressingDispatchValidator -- Verfies that the AxisOperation to be invoked matches the AxisOperation used for security configuration -- Only required if security is engaged Backwards Compatibility -- For users who haven't modified the WS-A Module - no backwards copat issues -- For users who have, need to modify their custom module.xml to use the new handlers Anyone have any thoughts on this? Cheers, David -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- www.ruchith.org www.wso2.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3290) surefire is still run even if maven.test.skip is true
surefire is still run even if maven.test.skip is true
-
Key: AXIS2-3290
URL: https://issues.apache.org/jira/browse/AXIS2-3290
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: samples, build,site
Affects Versions: 1.3
Environment: WinXP. Maven 2.0.4
Reporter: Kent Tong
Priority: Minor
mvn install -Dmaven.test.skip=true still runs surefire and all the tests. The
relevant output is:
jar:
[INFO] Executed tasks
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [antrun:run {execution: test-compile}]
[INFO] Executing tasks
testsetup:
[INFO] Executed tasks
[INFO] [surefire:test]
[INFO] Setting reports dir: C:\axis2-1.3\modules\kernel\target/surefire-reports
---
T E S T S
---
log4j:WARN No appenders could be found for logger
(org.apache.axis2.engine.Phase).
log4j:WARN Please initialize the log4j system properly.
[surefire] Running org.apache.axis2.addressing.AddressingHelperTest
[surefire] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3288) Maven2 WSDL2Code Plug-in Guide has incorrect and missing descriptions.
Maven2 WSDL2Code Plug-in Guide has incorrect and missing descriptions. -- Key: AXIS2-3288 URL: https://issues.apache.org/jira/browse/AXIS2-3288 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: documentation Affects Versions: 1.3 Reporter: Naozo Yoshioka Maven2 WSDL2Code Plug-in Guide http://ws.apache.org/axis2/tools/1_3/maven-plugins/maven-wsdl2code-plugin.html incorrect and missing descriptions like below. groupIdorg.apache.axis2.maven2/groupId must be replaced by groupIdorg.apache.axis2/groupId Map of namespace URI to packages. Example: namespaceURIs namespaceURI uriuri1/uri packagepackage1/package /namespaceURI /namespaceURI must be replaced by Map of namespace URI to packages. Example: namespaceURIs namespaceURI uriuri1/uri packageNamepackage1/packageName /namespaceURI /namespaceURI The row for unwarp is missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AXIS2] Proposal to implement http content negotiation
Hi Nicholas, Yes it will be in effect for all application (Subjected to the fact that it sends an Accept header). If the client does not send an Accept header then everything will be as it used to be. But as Glen suggested we could have a switch to turn this feature off. Thanks, Keith. On 10/19/07, Nicholas L Gallardo [EMAIL PROTECTED] wrote: Glen, If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? That's my understanding. I believe this is addressed in the SOAP 1.2 spec as to what constitutes a mismatch error and what kinds of responses can go back. Would this leave the existing behavior unchanged for services that declare an explicit SOAP binding in a WSDL? In other words, does this just apply to endpoints choosing to leverage a RESTful pattern/API, or will all applications be subject to negotiation? -Nick [image: Inactive hide details for Glen Daniels [EMAIL PROTECTED]]Glen Daniels [EMAIL PROTECTED] *Glen Daniels [EMAIL PROTECTED]* 10/18/2007 05:41 AM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [AXIS2] Proposal to implement http content negotiation Hi folks: +1 from me *if* we make sure there's a flag to allow people to control whether a given operation supports POX or not. Essentially I'm just saying we should backport the SOAP-Response MEP to SOAP 1.1, and allow the user to specify. By default the behavior should be as in Keith's proposal, but if they indicate that a particular operation is using the SOAP-Response MEP (this could also be a disablePOX flag or whatever), it should always return SOAP on a GET. Also... a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). If the request is SOAP 1.1, we should always return SOAP 1.1 regardless of the Accept header, right? --Glen Sanjiva Weerawarana wrote: +1 from me. For some further discussion on this see [1]. In particular [2] gives rationale for why its ok to give more weight to POX over SOAP 1.1. Sanjiva. [1] http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html keith chapman wrote: Hi Devs, There have been some thought on http content negotiation. With the concept of builders and formatters we have now this could be implemented trivially. The idea is to use the Accept http header to serve the response requested by the client. While going through this though I came across a issue though. This occurs when a request is sent via a GET using a browser (Cause the browser automatically adds the Accept http header). The Accept header sent by firefox is Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5. The confusion comes in because text/xml is used for both SOAP and REST responses. I believe having http content negotiation as a feature will be a nice addition to Axis2. And I propose that we treat text/xml as a REST response in implementing this. This would mean that you cannot ask for a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 response will be went only when the request is SOAP 1.1 and there is no matching value in the Accept header). What do u think? Should we go ahead and implement this proposal? Thanks, Keith. -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/ graycol.gifecblank.gif
[jira] Created: (AXIS2-3289) SwaTest.wsdl not found when building binary from source distribution
SwaTest.wsdl not found when building binary from source distribution Key: AXIS2-3289 URL: https://issues.apache.org/jira/browse/AXIS2-3289 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: samples, build,site Affects Versions: 1.3 Environment: WinXP. maven 2.0.4. Reporter: Kent Tong I am running mvn install in the axis2 source directory. When running the tests, one test will fail with the following error: [surefire] Running org.apache.axis2.description.WSDL11ToAxisServiceBuilderAttachmentTest testResouceFile: test-resources\wsdl\SwaTest.wsdl Error in WSDL : SwaTest.wsdl Exception: java.io.FileNotFoundException: test-resources\wsdl\SwaTest.wsdl ( ???) java.io.FileNotFoundException: test-resources\wsdl\SwaTest.wsdl (???) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.axis2.description.WSDL11ToAxisServiceBuilderAttachmentTest.testAttachment(WSDL11ToAxisServiceBuilderAttachmentTest.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) If I change into axis2\modules\kernel and run mvn install, then it will work. This is probably due to http://jira.codehaus.org/browse/SUREFIRE-191 and the line in WSDL11ToAxisServiceBuilderAttachmentTest.java: File testResourceFile = new File(test-resources/wsdl/SwaTest.wsdl); //relative to the project root, not module! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3083) SAAJ Implementation - blank namespaces when adding a SOAP body
[
https://issues.apache.org/jira/browse/AXIS2-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536072
]
Jeff Faath commented on AXIS2-3083:
---
Gents, I just checked the Oct. 17th nightly build and I'm getting the same
issue as the Oct. 3rd build. Any chance you can take a look at this? This is
literally last issue left before we cut a new release of jUDDI.
Thanks!
SAAJ Implementation - blank namespaces when adding a SOAP body
--
Key: AXIS2-3083
URL: https://issues.apache.org/jira/browse/AXIS2-3083
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Affects Versions: 1.3
Environment: All, using 1.3RC2 libraries
Reporter: Jeff Faath
Assignee: sumedha rubasinghe
This code:
public static void main(String[] args) {
String s = ?xml version=\1.0\ encoding=\UTF-8\? +
registryInfo xmlns=\urn:uddi-org:api\ +
property xmlns=\urn:uddi-org:api_v2\
name=\operatorEmailAddress\ value=\[EMAIL PROTECTED]/ +
property xmlns=\urn:uddi-org:api_v2\
name=\operatorName\ value=\jUDDI.org\/ +
property xmlns=\urn:uddi-org:api_v2\
name=\registryVersion\ value=\0.9rc4\/ +
property xmlns=\urn:uddi-org:api_v2\
name=\uddiVersion\ value=\2.0\/ +
/registryInfo;
try {
DocumentBuilderFactory docBuilderFactory =
DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
Document doc = docBuilder.parse(new ByteArrayInputStream(s.getBytes()));
writeXmlFile(doc);
SOAPMessage soapRes = null;
MessageFactory msgFactory = MessageFactory.newInstance();
soapRes = msgFactory.createMessage();
soapRes.getSOAPBody().addDocument(doc);
System.out.println(\n---);
writeXmlFile(soapRes.getSOAPBody());
}
catch (Exception e) {
System.out.println(e.getMessage());
}
}
public static void writeXmlFile(Node node) {
try {
Source source = new DOMSource(node);
Result result = new StreamResult(System.out);
Transformer xformer = TransformerFactory.newInstance().newTransformer();
xformer.transform(source, result);
} catch (TransformerConfigurationException e) {
} catch (TransformerException e) {
}
}
produces this output (indents added for readability):
?xml version=1.0 encoding=UTF-8?
registryInfo xmlns=urn:uddi-org:api
property xmlns=urn:uddi-org:api_v2 name=operatorEmailAddress
value=[EMAIL PROTECTED]/
property xmlns=urn:uddi-org:api_v2 name=operatorName
value=jUDDI.org/
property xmlns=urn:uddi-org:api_v2 name=registryVersion
value=0.9rc4/
property xmlns=urn:uddi-org:api_v2 name=uddiVersion value=2.0/
/registryInfo
---
?xml version=1.0 encoding=UTF-8?
soapenv:Body xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:axis2ns1=
axis2ns3:registryInfo xmlns:axis2ns2= xmlns:axis2ns3=
property name=operatorEmailAddress value=[EMAIL PROTECTED]/
property name=operatorName value=jUDDI.org/
property name=registryVersion value=0.9rc4/
property name=uddiVersion value=2.0/
/axis2ns3:registryInfo
/soapenv:Body
Where the namespaces are blank after adding the XML to the SOAPMessage's body.
This is using the simplest example I could make. In my actual project, where
essentially the same code is being executed, I get something like this
returned, which is the opposite problem...too many namespaces:
?xml version=1.0 encoding=UTF-8?
soapenv:Body xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:axis2ns18=urn:uddi-org:api
axis2ns24:registryInfo xmlns:axis2ns24=urn:uddi-org:api
xmlns:axis2ns13=urn:uddi-org:api_v2 xmlns:axis2ns17=urn:uddi-org:api_v2
xmlns:axis2ns19=urn:uddi-org:api xmlns:axis2ns5=urn:uddi-org:api_v2
xmlns:axis2ns9=urn:uddi-org:api_v2
axis2ns5:property xmlns:axis2ns20=urn:uddi-org:api_v2
name=operatorEmailAddress value=[EMAIL PROTECTED]
xmlns:axis2ns5=urn:uddi-org:api_v2/
axis2ns9:property xmlns:axis2ns21=urn:uddi-org:api_v2
name=operatorName value=jUDDI.org xmlns:axis2ns9=urn:uddi-org:api_v2/
axis2ns13:property xmlns:axis2ns22=urn:uddi-org:api_v2
name=registryVersion value=0.9rc4 xmlns:axis2ns13=urn:uddi-org:api_v2/
axis2ns17:property xmlns:axis2ns23=urn:uddi-org:api_v2
name=uddiVersion value=2.0 xmlns:axis2ns17=urn:uddi-org:api_v2/
/axis2ns24:registryInfo
/soapenv:Body
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To
