axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Nielsen (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Commented: (AXIS-1956) Client-side wsdd with service element changes request
Date Wed, 27 Apr 2005 20:11:23 GMT
     [ http://issues.apache.org/jira/browse/AXIS-1956?page=comments#action_63919 ]
     
Brian Nielsen commented on AXIS-1956:
-------------------------------------

Created workaround or problem solved?

I've found out how get it running, and the problem relates to doing doc/lit vs. rpc/enc. 

If I just use 
..
<service name="SearchManagerPort">
... 

I get the rpc/enc behaviour, but if I insert either of the attributes use or style with the
correct values I get doc/lit and It works:

..
<service name="SearchManagerPort" style="document" use="literal">
..


When I look into the code it's all more clear "org/apache/axis/deployment/wsdd/WSDDService.java",
in the constructor with an Element as parameter:

..
     String styleStr = e.getAttribute(ATTR_STYLE);
        if (styleStr != null && !styleStr.equals("")) {
            style = Style.getStyle(styleStr, Style.DEFAULT);
            desc.setStyle(style);
            providerQName = style.getProvider();
        }

        String useStr = e.getAttribute(ATTR_USE);
        if (useStr != null && !useStr.equals("")) {
            use = Use.getUse(useStr, Use.DEFAULT);
            desc.setUse(use);
        } else {
            if (style != Style.RPC) {
                // Default to use=literal if not style=RPC
                use = Use.LITERAL;
                desc.setUse(use);
            }
        }
...

if no style is set, it is set to default which is RPC (org/apache/axis/constants/Style.java)
and if the use is not set, it is set to 
ENCODED (org/apache/axis/constants/Use.java), though if style is not RPC use is set to literal.
Actually it looks like a bug because it probably should state "!style.equals(Style.RPC)" but
I'm not sure.


So is how does this position this issue?

Well I'm happy to get it working, but I'll call it a workaround, since the WSDL dictates doc/lit
it should not be up to the client-config.wsdd to dictate otherwise.

My personal preference would be to split the deployment descriptors for client-side and server-side.
Sure they have a lot in common, but also some differencies, like all the WSDL stuff for the
server side (is generated dynamically which still needs quite some work on axis) or just the
"wsdlFile". Also the pivot on the transport is a difference. I also can't figure out how the
global paramteres like sendXSItypes influence this, since the doc/rpc choice should take care
of this. I also would like to see wsdd-validation, so wrong spellings and maluse could be
stopped with xsd validation, I feel that is one of the many great uses of xsd's anyway. 

Since this is my first issue I'm not sure whether is should close this issue and create a
new one with my feature wishes?

Brgds Brian






> Client-side wsdd with service element changes request
> -----------------------------------------------------
>
>          Key: AXIS-1956
>          URL: http://issues.apache.org/jira/browse/AXIS-1956
>      Project: Axis
>         Type: Bug
>   Components: Deployment / Registries
>     Versions: current (nightly), 1.2RC3
>  Environment: Linux, JVM j2sdk1.4.2_07
>     Reporter: Brian Nielsen

>
> Using handlers in the Transport or Global "chain" cause no problem, but when I add a
specific service to my client-config.wsdd, the request i changed so it doesn't work anymore.
> Before the service element is added to my client-config the request is:
> <soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="id-3403998">
>   <SimpleDocumentSearch xmlns="http://isb.oio.dk/oioservice/service/SearchManager/Search/">
>     <FreeSearchText>LDAP_userid.xsd</FreeSearchText>
>   </SimpleDocumentSearch>
> </soapenv:Body>
> and after:
> <soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="id-5514537">
>   <SimpleDocumentSearch xmlns="http://isb.oio.dk/oioservice/service/SearchManager/Search/">
>     <FreeSearchText xmlns="">LDAP_userid.xsd</FreeSearchText>
>     <ObjectClassIDList xmlns="" xsi:nil="true"></ObjectClassIDList>
>   </SimpleDocumentSearch>
> </soapenv:Body>
> So the namespace of the "parameters" are set to the default namespace and the second
optional element is inserted and all of a sudden as a nillable element, the schema part from
the WSDL goes like:
> <xs:element name="SimpleDocumentSearch" type="search:SimpleDocumentSearchType"/>
> <xs:complexType name="SimpleDocumentSearchType">
>  <xs:sequence maxOccurs="1" minOccurs="1">
>    <xs:element minOccurs="0" name="FreeSearchText" type="xs:string"/>
>    <xs:element minOccurs="0" name="ObjectClassIDList" type="search:ObjectClassIDListType"/>
>   </xs:sequence>
> </xs:complexType>
> The service/WSDL for this service is located here: 
> http://isb.oio.dk/oioservice/service/public/2/searchmanager.asmx?WSDL
> it's a .NET service and it uses Web Service Security, where I have no problem using Addressing/WSS4J
as long as i stay away from service specific configurations, but in the long term I'll have
to be able to have several service specific handlers in my client-config.wsdd.
> I think I've seen a related issue before, but I can't find it now. 
> I've tried to reproduce the problem with a more simple scenario, but I didn't get any
problems there so there must be som other part involved.

-- 
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


Mime
View raw message