[
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