On 11/2/03 4:00, "ivelin" <[EMAIL PROTECTED]> wrote:
>
> Pier,
>
> Can you explain how do you plan to pass the parameters from the Http Request
> to the target URL?
> Do they override the once in the sitemap configuration for the generator?
> The idea of the WSProxy is to be used in its simplest
On 11/2/03 8:56, "Sylvain Wallez" <[EMAIL PROTECTED]> wrote:
> Tony Collen wrote:
>> On Mon, 10 Feb 2003, Nathaniel Alfred wrote:
>>
>>> Why not use plain old FileGenerator? At least with 2.1's URLSource
>>>
>>> http://backend/article?id=xyz"/>
>>>
>>> works like a charm. Am I missing someth
Tony Collen wrote:
On Mon, 10 Feb 2003, Nathaniel Alfred wrote:
Why not use plain old FileGenerator? At least with 2.1's URLSource
http://backend/article?id=xyz"/>
works like a charm. Am I missing something?
The WSP also passes any POST or GET parameters to the remote host
ROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 10, 2003 5:09 PM
Subject: Re: WSProxyGenerator
> On 10/2/03 21:00, "Tony Collen" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 10 Feb 2003, Nathaniel Alfred wrote:
> >
> >> Wh
On 10/2/03 21:00, "Tony Collen" <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Feb 2003, Nathaniel Alfred wrote:
>
>> Why not use plain old FileGenerator? At least with 2.1's URLSource
>>
>
>>http://backend/article?id=xyz"/>
>>
>> works like a charm. Am I missing something?
>
> The WSP also pa
On Mon, 10 Feb 2003, Nathaniel Alfred wrote:
> Why not use plain old FileGenerator? At least with 2.1's URLSource
>
>http://backend/article?id=xyz"/>
>
> works like a charm. Am I missing something?
The WSP also passes any POST or GET parameters to the remote host, which
is something the Fi
>-Original Message-
>From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Montag, 10. Februar 2003 19:04
>To: [EMAIL PROTECTED]
>Subject: Re: WSProxyGenerator
>
...
>
>So, literally, for me an article is that XML document found at
>
>http://backend/article?i
Pier Fumagalli wrote, On 10/02/2003 20.13:
On 10/2/03 18:30, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
IMHO, web service != WSDL.
IMHO, web service = transport + xml, thus HTTP+XML is a web service.
AFAIU, WSDL is the way to describe (formalize) web service. But it
perfectly works without i
On 10/2/03 18:30, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
> IMHO, web service != WSDL.
> IMHO, web service = transport + xml, thus HTTP+XML is a web service.
> AFAIU, WSDL is the way to describe (formalize) web service. But it
> perfectly works without it.
I use the "Goddard Compliancy Test
Pier Fumagalli wrote:
On 10/2/03 17:37, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
How about webservices (ws?) block? We have axis stuff in the scratchpad
which also could be thrown into it.
Well, I don't know... But, I _do_not_like_ web services... :-)
...
But that's far from wri
On 10/2/03 17:37, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
>
> How about webservices (ws?) block? We have axis stuff in the scratchpad
> which also could be thrown into it.
Well, I don't know... But, I _do_not_like_ web services... :-)
I need, though, an HttpProxyGenerator: in my application
Torsten Curdt wrote:
Is there a reason why the WebServiceProxyGenerator reads the entire
response
into a String and then parses _that_ instead of parsing the
InputStream of
the HTTP connection???
Pier
>
Deja vu?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104399362409715&w=2
The
Pier Fumagalli wrote:
On 10/2/03 16:56, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
Pier Fumagalli wrote:
Is there a reason why the WebServiceProxyGenerator reads the entire response
into a String and then parses _that_ instead of parsing the InputStream of
the HTTP connection???
Pi
On 10/2/03 17:03, "Torsten Curdt" <[EMAIL PROTECTED]> wrote:
>>> Is there a reason why the WebServiceProxyGenerator reads the entire
>>> response
>>> into a String and then parses _that_ instead of parsing the
>>> InputStream of
>>> the HTTP connection???
>>>
>>>Pier
>>
>> Deja vu?
>>
>> ht
On 10/2/03 16:56, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>
>> Is there a reason why the WebServiceProxyGenerator reads the entire response
>> into a String and then parses _that_ instead of parsing the InputStream of
>> the HTTP connection???
>>
>>Pier
>>
>>
Is there a reason why the WebServiceProxyGenerator reads the entire
response
into a String and then parses _that_ instead of parsing the
InputStream of
the HTTP connection???
Pier
>
Deja vu?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104399362409715&w=2
They changed the matrix ;)
--
Pier Fumagalli wrote:
Is there a reason why the WebServiceProxyGenerator reads the entire response
into a String and then parses _that_ instead of parsing the InputStream of
the HTTP connection???
Pier
Deja vu?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104399362409715&w=2
Vadim
Is there a reason why the WebServiceProxyGenerator reads the entire response
into a String and then parses _that_ instead of parsing the InputStream of
the HTTP connection???
Pier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
18 matches
Mail list logo