You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brad <br...@javawork.co.uk> on 2008/08/01 10:02:40 UTC
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Hi,
if you want to REST and a plain POST of an xml document then why not
ditch SOAP altogether and use HTTP headers for your metadata? Both of
your requirements are essentially XML over HTTP so why not use their
common ground to your advantage.
The schema part of your WSDL will still be valid so your interface
"contract" is still there. Saves you have to do too much which ties
your code to a specific implementation too.
Brad.
On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
<Ch...@morganstanley.com> wrote:
> We want to deploy services that are consumable either via conventional
> POST of a request document,
> or via RESTful invocation. It seems that wrapped-doc/literal has the
> feature of being able to do that
> without resorting to any extra work via the URIMappingInterceptor, which
> is wired in by default.
>
> The trouble is that our request has some meta data that must be added to
> the soap header,
> and in the case of conventional invocation via POST of a request
> document, all is fine.
>
> Now we want to also be able to pass this meta data when performing
> RESTful invocation, so the
> idea is to just tack on some extra query string parameters, in addition
> to the operation parameters defined in the
> WSDL.
>
> Ideally, the RESTful invocation processor would ignore the extra
> parameters which are not
> in the WSDL, unfortunately, before URIMappingInterceptor even gets a
> chance to complain, we
> get an array index error.
>
>
> protected MessageContentsList getParameters(Message message,
> BindingOperationInfo operation) {
> [...]
> int idx = 0;
> if (inf != null) {
> idx = inf.getIndex();
> }
> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> (types is null for no-arg operation)
> [...]
> }
>
> I could subclass this interceptor and change the behavior of
> getParameters(...) by override,
> then somehow configure cxf to use the derived class. However, I thought
> I'd ask the list -
> is this idea of simulating the Envelope Header in RESTful invocation by
> exra parameters a
> good idea? Obviously, there are limitations to what can be represented
> compared to
> full hierarchical XML, but this can be partially compensated for by a
> param name
> scheme such as:
> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
>
> I would hate to have to muddy up our contract definitions in the WSDL
> just to
> accommodate meta data that is only relevant to the infrastructure,
> rather then
> specific business functionality. I ask beause it might just be easier
> for me to patch
> URIMappingInterceptor directly, but I wonder if the patch would be
> accepted.
>
> Thanks,
>
> -Chris W.
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
>
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
You might also want to consider combining the JAX-WS and JAX-RS on the server side, while still using WSDL on the client side - it
might work quite well, and it would likely make the server side more flexible with respect to dealing with various non-SOAP
requests...You might be able to preserve the same server side code when combining JAX-WS and JAX-RS
Cheers, Sergey
----- Original Message -----
From: "Wolf, Chris (IT)" <Ch...@morganstanley.com>
To: "Daniel Kulp" <dk...@apache.org>; <us...@cxf.apache.org>
Sent: Tuesday, August 12, 2008 8:30 PM
Subject: RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Great, thanks I'll see how it goes...
-Chris W.
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Tuesday, August 12, 2008 2:09 PM
To: users@cxf.apache.org
Cc: Wolf, Chris (IT)
Subject: Re: ArrayIndexOutOfRange exception problem in
URIMappingInterceptor
Chris,
We'd definitely be open to a patch. :-)
Dan
On Tuesday 12 August 2008 11:20:07 am Wolf, Chris (IT) wrote:
> Benson,
>
> We can look at that, but more generally, I was hoping to see the
> URIMappingInterceptor ignore GET parameters that were not in the WSDL.
>
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Friday, August 01, 2008 9:33 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> How about using our JavaScript client generator to talk SOAP from the
> browser?
>
> On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
>
> <Ch...@morganstanley.com> wrote:
> > We're not going to ditch SOAP because of the advantages of code
> > generation from WSDL (top-down methodology), WS-* standards and
> > features, etc. As long as our code only use JAX-WS APIs, we're not
> > tied to a specific implementation.
> >
> > RESTful invocation is a minor use-case. The HTTP headers idea is an
> > interesting idea, however, not workable if we want to invoke with a
> > browser. (although the browser invocation use-case is just for
> > testing, right now)
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > Brad
> > Sent: Friday, August 01, 2008 4:03 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > Hi,
> >
> > if you want to REST and a plain POST of an xml document then why not
> > ditch SOAP altogether and use HTTP headers for your metadata? Both
> > of your requirements are essentially XML over HTTP so why not use
> > their common ground to your advantage.
> >
> > The schema part of your WSDL will still be valid so your interface
> > "contract" is still there. Saves you have to do too much which ties
> > your code to a specific implementation too.
> >
> > Brad.
> >
> > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> >
> > <Ch...@morganstanley.com> wrote:
> >> We want to deploy services that are consumable either via
> >> conventional
> >>
> >> POST of a request document, or via RESTful invocation. It seems
> >> that
> >>
> >> wrapped-doc/literal has the feature of being able to do that
> >> without resorting to any extra work via the URIMappingInterceptor,
> >> which is wired in by default.
> >>
> >> The trouble is that our request has some meta data that must be
> >> added
> >>
> >> to the soap header, and in the case of conventional invocation via
> >> POST of a request document, all is fine.
> >>
> >> Now we want to also be able to pass this meta data when performing
> >> RESTful invocation, so the idea is to just tack on some extra query
> >> string parameters, in addition to the operation parameters defined
> >> in
> >>
> >> the WSDL.
> >>
> >> Ideally, the RESTful invocation processor would ignore the extra
> >> parameters which are not in the WSDL, unfortunately, before
> >> URIMappingInterceptor even gets a chance to complain, we get an
> >> array
> >>
> >> index error.
> >>
> >>
> >> protected MessageContentsList getParameters(Message message,
> >> BindingOperationInfo operation) {
> >> [...]
> >> int idx = 0;
> >> if (inf != null) {
> >> idx = inf.getIndex();
> >> }
> >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> >> (types is null for no-arg operation)
> >> [...]
> >> }
> >>
> >> I could subclass this interceptor and change the behavior of
> >> getParameters(...) by override,
> >> then somehow configure cxf to use the derived class. However, I
> >> thought I'd ask the list - is this idea of simulating the Envelope
> >> Header in RESTful invocation by exra parameters a good idea?
> >> Obviously, there are limitations to what can be represented
> >> compared to full hierarchical XML, but this can be partially
> >> compensated for by
> >>
> >> a param name scheme such as:
> >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yan
> >> g
> >>
> >> I would hate to have to muddy up our contract definitions in the
> >> WSDL
> >>
> >> just to accommodate meta data that is only relevant to the
> >> infrastructure, rather then specific business functionality. I ask
> >> beause it might just be easier for me to patch
> >> URIMappingInterceptor directly, but I wonder if the patch would be
accepted.
> >>
> >> Thanks,
> >>
> >> -Chris W.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by "Wolf, Chris (IT)" <Ch...@morganstanley.com>.
Great, thanks I'll see how it goes...
-Chris W.
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Tuesday, August 12, 2008 2:09 PM
To: users@cxf.apache.org
Cc: Wolf, Chris (IT)
Subject: Re: ArrayIndexOutOfRange exception problem in
URIMappingInterceptor
Chris,
We'd definitely be open to a patch. :-)
Dan
On Tuesday 12 August 2008 11:20:07 am Wolf, Chris (IT) wrote:
> Benson,
>
> We can look at that, but more generally, I was hoping to see the
> URIMappingInterceptor ignore GET parameters that were not in the WSDL.
>
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Friday, August 01, 2008 9:33 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> How about using our JavaScript client generator to talk SOAP from the
> browser?
>
> On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
>
> <Ch...@morganstanley.com> wrote:
> > We're not going to ditch SOAP because of the advantages of code
> > generation from WSDL (top-down methodology), WS-* standards and
> > features, etc. As long as our code only use JAX-WS APIs, we're not
> > tied to a specific implementation.
> >
> > RESTful invocation is a minor use-case. The HTTP headers idea is an
> > interesting idea, however, not workable if we want to invoke with a
> > browser. (although the browser invocation use-case is just for
> > testing, right now)
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > Brad
> > Sent: Friday, August 01, 2008 4:03 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > Hi,
> >
> > if you want to REST and a plain POST of an xml document then why not
> > ditch SOAP altogether and use HTTP headers for your metadata? Both
> > of your requirements are essentially XML over HTTP so why not use
> > their common ground to your advantage.
> >
> > The schema part of your WSDL will still be valid so your interface
> > "contract" is still there. Saves you have to do too much which ties
> > your code to a specific implementation too.
> >
> > Brad.
> >
> > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> >
> > <Ch...@morganstanley.com> wrote:
> >> We want to deploy services that are consumable either via
> >> conventional
> >>
> >> POST of a request document, or via RESTful invocation. It seems
> >> that
> >>
> >> wrapped-doc/literal has the feature of being able to do that
> >> without resorting to any extra work via the URIMappingInterceptor,
> >> which is wired in by default.
> >>
> >> The trouble is that our request has some meta data that must be
> >> added
> >>
> >> to the soap header, and in the case of conventional invocation via
> >> POST of a request document, all is fine.
> >>
> >> Now we want to also be able to pass this meta data when performing
> >> RESTful invocation, so the idea is to just tack on some extra query
> >> string parameters, in addition to the operation parameters defined
> >> in
> >>
> >> the WSDL.
> >>
> >> Ideally, the RESTful invocation processor would ignore the extra
> >> parameters which are not in the WSDL, unfortunately, before
> >> URIMappingInterceptor even gets a chance to complain, we get an
> >> array
> >>
> >> index error.
> >>
> >>
> >> protected MessageContentsList getParameters(Message message,
> >> BindingOperationInfo operation) {
> >> [...]
> >> int idx = 0;
> >> if (inf != null) {
> >> idx = inf.getIndex();
> >> }
> >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> >> (types is null for no-arg operation)
> >> [...]
> >> }
> >>
> >> I could subclass this interceptor and change the behavior of
> >> getParameters(...) by override,
> >> then somehow configure cxf to use the derived class. However, I
> >> thought I'd ask the list - is this idea of simulating the Envelope
> >> Header in RESTful invocation by exra parameters a good idea?
> >> Obviously, there are limitations to what can be represented
> >> compared to full hierarchical XML, but this can be partially
> >> compensated for by
> >>
> >> a param name scheme such as:
> >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yan
> >> g
> >>
> >> I would hate to have to muddy up our contract definitions in the
> >> WSDL
> >>
> >> just to accommodate meta data that is only relevant to the
> >> infrastructure, rather then specific business functionality. I ask
> >> beause it might just be easier for me to patch
> >> URIMappingInterceptor directly, but I wonder if the patch would be
accepted.
> >>
> >> Thanks,
> >>
> >> -Chris W.
> >> --------------------------------------------------------
> >>
> >> NOTICE: If received in error, please destroy and notify sender.
> >> Sender
> >
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> >
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender
>
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
>
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by Daniel Kulp <dk...@apache.org>.
Chris,
We'd definitely be open to a patch. :-)
Dan
On Tuesday 12 August 2008 11:20:07 am Wolf, Chris (IT) wrote:
> Benson,
>
> We can look at that, but more generally, I was hoping to see the
> URIMappingInterceptor
> ignore GET parameters that were not in the WSDL.
>
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Friday, August 01, 2008 9:33 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> How about using our JavaScript client generator to talk SOAP from the
> browser?
>
> On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
>
> <Ch...@morganstanley.com> wrote:
> > We're not going to ditch SOAP because of the advantages of code
> > generation from WSDL (top-down methodology), WS-* standards and
> > features, etc. As long as our code only use JAX-WS APIs, we're not
> > tied to a specific implementation.
> >
> > RESTful invocation is a minor use-case. The HTTP headers idea is an
> > interesting idea, however, not workable if we want to invoke with a
> > browser. (although the browser invocation use-case is just for
> > testing, right now)
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > Brad
> > Sent: Friday, August 01, 2008 4:03 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > Hi,
> >
> > if you want to REST and a plain POST of an xml document then why not
> > ditch SOAP altogether and use HTTP headers for your metadata? Both of
> > your requirements are essentially XML over HTTP so why not use their
> > common ground to your advantage.
> >
> > The schema part of your WSDL will still be valid so your interface
> > "contract" is still there. Saves you have to do too much which ties
> > your code to a specific implementation too.
> >
> > Brad.
> >
> > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> >
> > <Ch...@morganstanley.com> wrote:
> >> We want to deploy services that are consumable either via
> >> conventional
> >>
> >> POST of a request document, or via RESTful invocation. It seems that
> >>
> >> wrapped-doc/literal has the feature of being able to do that without
> >> resorting to any extra work via the URIMappingInterceptor, which is
> >> wired in by default.
> >>
> >> The trouble is that our request has some meta data that must be added
> >>
> >> to the soap header, and in the case of conventional invocation via
> >> POST of a request document, all is fine.
> >>
> >> Now we want to also be able to pass this meta data when performing
> >> RESTful invocation, so the idea is to just tack on some extra query
> >> string parameters, in addition to the operation parameters defined in
> >>
> >> the WSDL.
> >>
> >> Ideally, the RESTful invocation processor would ignore the extra
> >> parameters which are not in the WSDL, unfortunately, before
> >> URIMappingInterceptor even gets a chance to complain, we get an array
> >>
> >> index error.
> >>
> >>
> >> protected MessageContentsList getParameters(Message message,
> >> BindingOperationInfo operation) {
> >> [...]
> >> int idx = 0;
> >> if (inf != null) {
> >> idx = inf.getIndex();
> >> }
> >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> >> (types is null for no-arg operation)
> >> [...]
> >> }
> >>
> >> I could subclass this interceptor and change the behavior of
> >> getParameters(...) by override,
> >> then somehow configure cxf to use the derived class. However, I
> >> thought I'd ask the list - is this idea of simulating the Envelope
> >> Header in RESTful invocation by exra parameters a good idea?
> >> Obviously, there are limitations to what can be represented compared
> >> to full hierarchical XML, but this can be partially compensated for
> >> by
> >>
> >> a param name scheme such as:
> >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
> >>
> >> I would hate to have to muddy up our contract definitions in the WSDL
> >>
> >> just to accommodate meta data that is only relevant to the
> >> infrastructure, rather then specific business functionality. I ask
> >> beause it might just be easier for me to patch URIMappingInterceptor
> >> directly, but I wonder if the patch would be accepted.
> >>
> >> Thanks,
> >>
> >> -Chris W.
> >> --------------------------------------------------------
> >>
> >> NOTICE: If received in error, please destroy and notify sender.
> >> Sender
> >
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> >
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
>
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.
>
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by Benson Margulies <bi...@gmail.com>.
What I mean is that the CXF committers are a loosely-coupled group of
people.
On Tue, Aug 12, 2008 at 12:46 PM, Wolf, Chris (IT) <
Chris.Wolf@morganstanley.com> wrote:
> I'm not certain what you mean by "division-of-labor disease". Since we
> are developing
> services intended for a wide audience, we want to provide flexible
> request handling,
> which may include RESTful invocation, but with some additional
> meta-parameters, to
> be igored by CXF. We will also highlight your Javascipt client as well,
> thanks.
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Tuesday, August 12, 2008 11:48 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> You're experiencing a bit of division-of-labor disease here. Inside CXF,
> I'm the department of full-SOAP javascript clients, and others
> concentrate on JAX-RS. I'm not standing in the way of the JAX-RS
> department making you happy, I was just noting that your description
> suggested that perhaps the SOAP client might be a option you would
> consider.
>
> On Tue, Aug 12, 2008 at 11:20 AM, Wolf, Chris (IT) <
> Chris.Wolf@morganstanley.com> wrote:
>
> > Benson,
> >
> > We can look at that, but more generally, I was hoping to see the
> > URIMappingInterceptor ignore GET parameters that were not in the WSDL.
> >
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > Sent: Friday, August 01, 2008 9:33 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > How about using our JavaScript client generator to talk SOAP from the
> > browser?
> >
> > On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
> > <Ch...@morganstanley.com> wrote:
> > > We're not going to ditch SOAP because of the advantages of code
> > > generation from WSDL (top-down methodology), WS-* standards and
> > > features, etc. As long as our code only use JAX-WS APIs, we're not
> > > tied to a specific implementation.
> > >
> > > RESTful invocation is a minor use-case. The HTTP headers idea is an
>
> > > interesting idea, however, not workable if we want to invoke with a
> > > browser. (although the browser invocation use-case is just for
> > > testing, right now)
> > >
> > > Thanks,
> > >
> > > -Chris W.
> > >
> > > -----Original Message-----
> > > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > > Brad
> > > Sent: Friday, August 01, 2008 4:03 AM
> > > To: users@cxf.apache.org
> > > Subject: Re: ArrayIndexOutOfRange exception problem in
> > > URIMappingInterceptor
> > >
> > > Hi,
> > >
> > > if you want to REST and a plain POST of an xml document then why not
>
> > > ditch SOAP altogether and use HTTP headers for your metadata? Both
> > > of your requirements are essentially XML over HTTP so why not use
> > > their common ground to your advantage.
> > >
> > > The schema part of your WSDL will still be valid so your interface
> > > "contract" is still there. Saves you have to do too much which ties
> > > your code to a specific implementation too.
> > >
> > > Brad.
> > >
> > > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> > > <Ch...@morganstanley.com> wrote:
> > >> We want to deploy services that are consumable either via
> > >> conventional
> > >
> > >> POST of a request document, or via RESTful invocation. It seems
> > >> that
> >
> > >> wrapped-doc/literal has the feature of being able to do that
> > >> without resorting to any extra work via the URIMappingInterceptor,
> > >> which is wired in by default.
> > >>
> > >> The trouble is that our request has some meta data that must be
> > >> added
> >
> > >> to the soap header, and in the case of conventional invocation via
> > >> POST of a request document, all is fine.
> > >>
> > >> Now we want to also be able to pass this meta data when performing
> > >> RESTful invocation, so the idea is to just tack on some extra query
>
> > >> string parameters, in addition to the operation parameters defined
> > >> in
> >
> > >> the WSDL.
> > >>
> > >> Ideally, the RESTful invocation processor would ignore the extra
> > >> parameters which are not in the WSDL, unfortunately, before
> > >> URIMappingInterceptor even gets a chance to complain, we get an
> > >> array
> >
> > >> index error.
> > >>
> > >>
> > >> protected MessageContentsList getParameters(Message message,
> > >> BindingOperationInfo operation) {
> > >> [...]
> > >> int idx = 0;
> > >> if (inf != null) {
> > >> idx = inf.getIndex();
> > >> }
> > >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> > >> (types is null for no-arg operation)
> > >> [...]
> > >> }
> > >>
> > >> I could subclass this interceptor and change the behavior of
> > >> getParameters(...) by override,
> > >> then somehow configure cxf to use the derived class. However, I
> > >> thought I'd ask the list - is this idea of simulating the Envelope
> > >> Header in RESTful invocation by exra parameters a good idea?
> > >> Obviously, there are limitations to what can be represented
> > >> compared to full hierarchical XML, but this can be partially
> > >> compensated for by
> > >
> > >> a param name scheme such as:
> > >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yan
> > >> g
> > >>
> > >> I would hate to have to muddy up our contract definitions in the
> > >> WSDL
> >
> > >> just to accommodate meta data that is only relevant to the
> > >> infrastructure, rather then specific business functionality. I ask
>
> > >> beause it might just be easier for me to patch
> > >> URIMappingInterceptor directly, but I wonder if the patch would be
> accepted.
> > >>
> > >> Thanks,
> > >>
> > >> -Chris W.
> > >> --------------------------------------------------------
> > >>
> > >> NOTICE: If received in error, please destroy and notify sender.
> > >> Sender
> > > does not intend to waive confidentiality or privilege. Use of this
> > > email is prohibited when received in error.
> > >>
> > > --------------------------------------------------------
> > >
> > > NOTICE: If received in error, please destroy and notify sender.
> > > Sender
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> > >
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
>
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> >
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
>
RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by "Wolf, Chris (IT)" <Ch...@morganstanley.com>.
I'm not certain what you mean by "division-of-labor disease". Since we
are developing
services intended for a wide audience, we want to provide flexible
request handling,
which may include RESTful invocation, but with some additional
meta-parameters, to
be igored by CXF. We will also highlight your Javascipt client as well,
thanks.
-Chris W.
-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: Tuesday, August 12, 2008 11:48 AM
To: users@cxf.apache.org
Subject: Re: ArrayIndexOutOfRange exception problem in
URIMappingInterceptor
You're experiencing a bit of division-of-labor disease here. Inside CXF,
I'm the department of full-SOAP javascript clients, and others
concentrate on JAX-RS. I'm not standing in the way of the JAX-RS
department making you happy, I was just noting that your description
suggested that perhaps the SOAP client might be a option you would
consider.
On Tue, Aug 12, 2008 at 11:20 AM, Wolf, Chris (IT) <
Chris.Wolf@morganstanley.com> wrote:
> Benson,
>
> We can look at that, but more generally, I was hoping to see the
> URIMappingInterceptor ignore GET parameters that were not in the WSDL.
>
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Friday, August 01, 2008 9:33 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> How about using our JavaScript client generator to talk SOAP from the
> browser?
>
> On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
> <Ch...@morganstanley.com> wrote:
> > We're not going to ditch SOAP because of the advantages of code
> > generation from WSDL (top-down methodology), WS-* standards and
> > features, etc. As long as our code only use JAX-WS APIs, we're not
> > tied to a specific implementation.
> >
> > RESTful invocation is a minor use-case. The HTTP headers idea is an
> > interesting idea, however, not workable if we want to invoke with a
> > browser. (although the browser invocation use-case is just for
> > testing, right now)
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > Brad
> > Sent: Friday, August 01, 2008 4:03 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > Hi,
> >
> > if you want to REST and a plain POST of an xml document then why not
> > ditch SOAP altogether and use HTTP headers for your metadata? Both
> > of your requirements are essentially XML over HTTP so why not use
> > their common ground to your advantage.
> >
> > The schema part of your WSDL will still be valid so your interface
> > "contract" is still there. Saves you have to do too much which ties
> > your code to a specific implementation too.
> >
> > Brad.
> >
> > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> > <Ch...@morganstanley.com> wrote:
> >> We want to deploy services that are consumable either via
> >> conventional
> >
> >> POST of a request document, or via RESTful invocation. It seems
> >> that
>
> >> wrapped-doc/literal has the feature of being able to do that
> >> without resorting to any extra work via the URIMappingInterceptor,
> >> which is wired in by default.
> >>
> >> The trouble is that our request has some meta data that must be
> >> added
>
> >> to the soap header, and in the case of conventional invocation via
> >> POST of a request document, all is fine.
> >>
> >> Now we want to also be able to pass this meta data when performing
> >> RESTful invocation, so the idea is to just tack on some extra query
> >> string parameters, in addition to the operation parameters defined
> >> in
>
> >> the WSDL.
> >>
> >> Ideally, the RESTful invocation processor would ignore the extra
> >> parameters which are not in the WSDL, unfortunately, before
> >> URIMappingInterceptor even gets a chance to complain, we get an
> >> array
>
> >> index error.
> >>
> >>
> >> protected MessageContentsList getParameters(Message message,
> >> BindingOperationInfo operation) {
> >> [...]
> >> int idx = 0;
> >> if (inf != null) {
> >> idx = inf.getIndex();
> >> }
> >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> >> (types is null for no-arg operation)
> >> [...]
> >> }
> >>
> >> I could subclass this interceptor and change the behavior of
> >> getParameters(...) by override,
> >> then somehow configure cxf to use the derived class. However, I
> >> thought I'd ask the list - is this idea of simulating the Envelope
> >> Header in RESTful invocation by exra parameters a good idea?
> >> Obviously, there are limitations to what can be represented
> >> compared to full hierarchical XML, but this can be partially
> >> compensated for by
> >
> >> a param name scheme such as:
> >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yan
> >> g
> >>
> >> I would hate to have to muddy up our contract definitions in the
> >> WSDL
>
> >> just to accommodate meta data that is only relevant to the
> >> infrastructure, rather then specific business functionality. I ask
> >> beause it might just be easier for me to patch
> >> URIMappingInterceptor directly, but I wonder if the patch would be
accepted.
> >>
> >> Thanks,
> >>
> >> -Chris W.
> >> --------------------------------------------------------
> >>
> >> NOTICE: If received in error, please destroy and notify sender.
> >> Sender
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> >>
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
> >
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by Benson Margulies <bi...@gmail.com>.
You're experiencing a bit of division-of-labor disease here. Inside CXF, I'm
the department of full-SOAP javascript clients, and others concentrate on
JAX-RS. I'm not standing in the way of the JAX-RS department making you
happy, I was just noting that your description suggested that perhaps the
SOAP client might be a option you would consider.
On Tue, Aug 12, 2008 at 11:20 AM, Wolf, Chris (IT) <
Chris.Wolf@morganstanley.com> wrote:
> Benson,
>
> We can look at that, but more generally, I was hoping to see the
> URIMappingInterceptor
> ignore GET parameters that were not in the WSDL.
>
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Friday, August 01, 2008 9:33 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> How about using our JavaScript client generator to talk SOAP from the
> browser?
>
> On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
> <Ch...@morganstanley.com> wrote:
> > We're not going to ditch SOAP because of the advantages of code
> > generation from WSDL (top-down methodology), WS-* standards and
> > features, etc. As long as our code only use JAX-WS APIs, we're not
> > tied to a specific implementation.
> >
> > RESTful invocation is a minor use-case. The HTTP headers idea is an
> > interesting idea, however, not workable if we want to invoke with a
> > browser. (although the browser invocation use-case is just for
> > testing, right now)
> >
> > Thanks,
> >
> > -Chris W.
> >
> > -----Original Message-----
> > From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> > Brad
> > Sent: Friday, August 01, 2008 4:03 AM
> > To: users@cxf.apache.org
> > Subject: Re: ArrayIndexOutOfRange exception problem in
> > URIMappingInterceptor
> >
> > Hi,
> >
> > if you want to REST and a plain POST of an xml document then why not
> > ditch SOAP altogether and use HTTP headers for your metadata? Both of
> > your requirements are essentially XML over HTTP so why not use their
> > common ground to your advantage.
> >
> > The schema part of your WSDL will still be valid so your interface
> > "contract" is still there. Saves you have to do too much which ties
> > your code to a specific implementation too.
> >
> > Brad.
> >
> > On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> > <Ch...@morganstanley.com> wrote:
> >> We want to deploy services that are consumable either via
> >> conventional
> >
> >> POST of a request document, or via RESTful invocation. It seems that
>
> >> wrapped-doc/literal has the feature of being able to do that without
> >> resorting to any extra work via the URIMappingInterceptor, which is
> >> wired in by default.
> >>
> >> The trouble is that our request has some meta data that must be added
>
> >> to the soap header, and in the case of conventional invocation via
> >> POST of a request document, all is fine.
> >>
> >> Now we want to also be able to pass this meta data when performing
> >> RESTful invocation, so the idea is to just tack on some extra query
> >> string parameters, in addition to the operation parameters defined in
>
> >> the WSDL.
> >>
> >> Ideally, the RESTful invocation processor would ignore the extra
> >> parameters which are not in the WSDL, unfortunately, before
> >> URIMappingInterceptor even gets a chance to complain, we get an array
>
> >> index error.
> >>
> >>
> >> protected MessageContentsList getParameters(Message message,
> >> BindingOperationInfo operation) {
> >> [...]
> >> int idx = 0;
> >> if (inf != null) {
> >> idx = inf.getIndex();
> >> }
> >> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> >> (types is null for no-arg operation)
> >> [...]
> >> }
> >>
> >> I could subclass this interceptor and change the behavior of
> >> getParameters(...) by override,
> >> then somehow configure cxf to use the derived class. However, I
> >> thought I'd ask the list - is this idea of simulating the Envelope
> >> Header in RESTful invocation by exra parameters a good idea?
> >> Obviously, there are limitations to what can be represented compared
> >> to full hierarchical XML, but this can be partially compensated for
> >> by
> >
> >> a param name scheme such as:
> >> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
> >>
> >> I would hate to have to muddy up our contract definitions in the WSDL
>
> >> just to accommodate meta data that is only relevant to the
> >> infrastructure, rather then specific business functionality. I ask
> >> beause it might just be easier for me to patch URIMappingInterceptor
> >> directly, but I wonder if the patch would be accepted.
> >>
> >> Thanks,
> >>
> >> -Chris W.
> >> --------------------------------------------------------
> >>
> >> NOTICE: If received in error, please destroy and notify sender.
> >> Sender
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
> >>
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.
> >
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
>
RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by "Wolf, Chris (IT)" <Ch...@morganstanley.com>.
Benson,
We can look at that, but more generally, I was hoping to see the
URIMappingInterceptor
ignore GET parameters that were not in the WSDL.
Thanks,
-Chris W.
-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: Friday, August 01, 2008 9:33 AM
To: users@cxf.apache.org
Subject: Re: ArrayIndexOutOfRange exception problem in
URIMappingInterceptor
How about using our JavaScript client generator to talk SOAP from the
browser?
On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
<Ch...@morganstanley.com> wrote:
> We're not going to ditch SOAP because of the advantages of code
> generation from WSDL (top-down methodology), WS-* standards and
> features, etc. As long as our code only use JAX-WS APIs, we're not
> tied to a specific implementation.
>
> RESTful invocation is a minor use-case. The HTTP headers idea is an
> interesting idea, however, not workable if we want to invoke with a
> browser. (although the browser invocation use-case is just for
> testing, right now)
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of
> Brad
> Sent: Friday, August 01, 2008 4:03 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> Hi,
>
> if you want to REST and a plain POST of an xml document then why not
> ditch SOAP altogether and use HTTP headers for your metadata? Both of
> your requirements are essentially XML over HTTP so why not use their
> common ground to your advantage.
>
> The schema part of your WSDL will still be valid so your interface
> "contract" is still there. Saves you have to do too much which ties
> your code to a specific implementation too.
>
> Brad.
>
> On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> <Ch...@morganstanley.com> wrote:
>> We want to deploy services that are consumable either via
>> conventional
>
>> POST of a request document, or via RESTful invocation. It seems that
>> wrapped-doc/literal has the feature of being able to do that without
>> resorting to any extra work via the URIMappingInterceptor, which is
>> wired in by default.
>>
>> The trouble is that our request has some meta data that must be added
>> to the soap header, and in the case of conventional invocation via
>> POST of a request document, all is fine.
>>
>> Now we want to also be able to pass this meta data when performing
>> RESTful invocation, so the idea is to just tack on some extra query
>> string parameters, in addition to the operation parameters defined in
>> the WSDL.
>>
>> Ideally, the RESTful invocation processor would ignore the extra
>> parameters which are not in the WSDL, unfortunately, before
>> URIMappingInterceptor even gets a chance to complain, we get an array
>> index error.
>>
>>
>> protected MessageContentsList getParameters(Message message,
>> BindingOperationInfo operation) {
>> [...]
>> int idx = 0;
>> if (inf != null) {
>> idx = inf.getIndex();
>> }
>> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
>> (types is null for no-arg operation)
>> [...]
>> }
>>
>> I could subclass this interceptor and change the behavior of
>> getParameters(...) by override,
>> then somehow configure cxf to use the derived class. However, I
>> thought I'd ask the list - is this idea of simulating the Envelope
>> Header in RESTful invocation by exra parameters a good idea?
>> Obviously, there are limitations to what can be represented compared
>> to full hierarchical XML, but this can be partially compensated for
>> by
>
>> a param name scheme such as:
>> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
>>
>> I would hate to have to muddy up our contract definitions in the WSDL
>> just to accommodate meta data that is only relevant to the
>> infrastructure, rather then specific business functionality. I ask
>> beause it might just be easier for me to patch URIMappingInterceptor
>> directly, but I wonder if the patch would be accepted.
>>
>> Thanks,
>>
>> -Chris W.
>> --------------------------------------------------------
>>
>> NOTICE: If received in error, please destroy and notify sender.
>> Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
>>
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error.
>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by Benson Margulies <bi...@gmail.com>.
How about using our JavaScript client generator to talk SOAP from the browser?
On Fri, Aug 1, 2008 at 9:25 AM, Wolf, Chris (IT)
<Ch...@morganstanley.com> wrote:
> We're not going to ditch SOAP because of the advantages of code
> generation
> from WSDL (top-down methodology), WS-* standards and features, etc. As
> long
> as our code only use JAX-WS APIs, we're not tied to a specific
> implementation.
>
> RESTful invocation is a minor use-case. The HTTP headers idea is an
> interesting idea,
> however, not workable if we want to invoke with a browser. (although the
> browser
> invocation use-case is just for testing, right now)
>
> Thanks,
>
> -Chris W.
>
> -----Original Message-----
> From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of Brad
> Sent: Friday, August 01, 2008 4:03 AM
> To: users@cxf.apache.org
> Subject: Re: ArrayIndexOutOfRange exception problem in
> URIMappingInterceptor
>
> Hi,
>
> if you want to REST and a plain POST of an xml document then why not
> ditch SOAP altogether and use HTTP headers for your metadata? Both of
> your requirements are essentially XML over HTTP so why not use their
> common ground to your advantage.
>
> The schema part of your WSDL will still be valid so your interface
> "contract" is still there. Saves you have to do too much which ties your
> code to a specific implementation too.
>
> Brad.
>
> On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
> <Ch...@morganstanley.com> wrote:
>> We want to deploy services that are consumable either via conventional
>
>> POST of a request document, or via RESTful invocation. It seems that
>> wrapped-doc/literal has the feature of being able to do that without
>> resorting to any extra work via the URIMappingInterceptor, which is
>> wired in by default.
>>
>> The trouble is that our request has some meta data that must be added
>> to the soap header, and in the case of conventional invocation via
>> POST of a request document, all is fine.
>>
>> Now we want to also be able to pass this meta data when performing
>> RESTful invocation, so the idea is to just tack on some extra query
>> string parameters, in addition to the operation parameters defined in
>> the WSDL.
>>
>> Ideally, the RESTful invocation processor would ignore the extra
>> parameters which are not in the WSDL, unfortunately, before
>> URIMappingInterceptor even gets a chance to complain, we get an array
>> index error.
>>
>>
>> protected MessageContentsList getParameters(Message message,
>> BindingOperationInfo operation) {
>> [...]
>> int idx = 0;
>> if (inf != null) {
>> idx = inf.getIndex();
>> }
>> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
>> (types is null for no-arg operation)
>> [...]
>> }
>>
>> I could subclass this interceptor and change the behavior of
>> getParameters(...) by override,
>> then somehow configure cxf to use the derived class. However, I
>> thought I'd ask the list - is this idea of simulating the Envelope
>> Header in RESTful invocation by exra parameters a good idea?
>> Obviously, there are limitations to what can be represented compared
>> to full hierarchical XML, but this can be partially compensated for by
>
>> a param name scheme such as:
>> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
>>
>> I would hate to have to muddy up our contract definitions in the WSDL
>> just to accommodate meta data that is only relevant to the
>> infrastructure, rather then specific business functionality. I ask
>> beause it might just be easier for me to patch URIMappingInterceptor
>> directly, but I wonder if the patch would be accepted.
>>
>> Thanks,
>>
>> -Chris W.
>> --------------------------------------------------------
>>
>> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.
>>
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
>
RE: ArrayIndexOutOfRange exception problem in URIMappingInterceptor
Posted by "Wolf, Chris (IT)" <Ch...@morganstanley.com>.
We're not going to ditch SOAP because of the advantages of code
generation
from WSDL (top-down methodology), WS-* standards and features, etc. As
long
as our code only use JAX-WS APIs, we're not tied to a specific
implementation.
RESTful invocation is a minor use-case. The HTTP headers idea is an
interesting idea,
however, not workable if we want to invoke with a browser. (although the
browser
invocation use-case is just for testing, right now)
Thanks,
-Chris W.
-----Original Message-----
From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of Brad
Sent: Friday, August 01, 2008 4:03 AM
To: users@cxf.apache.org
Subject: Re: ArrayIndexOutOfRange exception problem in
URIMappingInterceptor
Hi,
if you want to REST and a plain POST of an xml document then why not
ditch SOAP altogether and use HTTP headers for your metadata? Both of
your requirements are essentially XML over HTTP so why not use their
common ground to your advantage.
The schema part of your WSDL will still be valid so your interface
"contract" is still there. Saves you have to do too much which ties your
code to a specific implementation too.
Brad.
On Fri, Aug 1, 2008 at 3:05 AM, Wolf, Chris (IT)
<Ch...@morganstanley.com> wrote:
> We want to deploy services that are consumable either via conventional
> POST of a request document, or via RESTful invocation. It seems that
> wrapped-doc/literal has the feature of being able to do that without
> resorting to any extra work via the URIMappingInterceptor, which is
> wired in by default.
>
> The trouble is that our request has some meta data that must be added
> to the soap header, and in the case of conventional invocation via
> POST of a request document, all is fine.
>
> Now we want to also be able to pass this meta data when performing
> RESTful invocation, so the idea is to just tack on some extra query
> string parameters, in addition to the operation parameters defined in
> the WSDL.
>
> Ideally, the RESTful invocation processor would ignore the extra
> parameters which are not in the WSDL, unfortunately, before
> URIMappingInterceptor even gets a chance to complain, we get an array
> index error.
>
>
> protected MessageContentsList getParameters(Message message,
> BindingOperationInfo operation) {
> [...]
> int idx = 0;
> if (inf != null) {
> idx = inf.getIndex();
> }
> Class<?> type = types[idx]; <---- line #178, CXF-2.1.1
> (types is null for no-arg operation)
> [...]
> }
>
> I could subclass this interceptor and change the behavior of
> getParameters(...) by override,
> then somehow configure cxf to use the derived class. However, I
> thought I'd ask the list - is this idea of simulating the Envelope
> Header in RESTful invocation by exra parameters a good idea?
> Obviously, there are limitations to what can be represented compared
> to full hierarchical XML, but this can be partially compensated for by
> a param name scheme such as:
> group0.item0=foo&group0.item1=bar&group1.item0=yin&group1.item1=yang
>
> I would hate to have to muddy up our contract definitions in the WSDL
> just to accommodate meta data that is only relevant to the
> infrastructure, rather then specific business functionality. I ask
> beause it might just be easier for me to patch URIMappingInterceptor
> directly, but I wonder if the patch would be accepted.
>
> Thanks,
>
> -Chris W.
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error.
>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.