You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2003/02/10 17:36:27 UTC
WSProxyGenerator
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Stefano Mazzocchi <st...@apache.org>.
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
>
>
> They changed the matrix ;)
LOL :)
Watch out, they're gomingagetcha :)
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10/2/03 17:03, "Torsten Curdt" <tc...@dff.st> 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
>
> They changed the matrix ;)
Nah, it's just Pier being utterly idiotic as usual! :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Torsten Curdt <tc...@dff.st>.
>> 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 ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pier Fumagalli wrote, On 10/02/2003 20.13:
> On 10/2/03 18:30, "Vadim Gritsenko" <va...@verizon.net> 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 for Buzzword"...
>
> - If I say "web service", Goddard will again reply "too complicated, we
> don't want to use that J2EE thing"
>
> - If I say "XML over HTTP via a proxy", Goddard will reply: "Ah, ok, why
> didn't you say so in the first place, you muppet?"
I use the "Andy Compliancy Test for Buzzword"...
- If I say "Inversion o Control", Andy will again reply
"too complicated, we don't want to use that Avalon thing"
- If I say "container sets up the object ", Andy will reply:
"Ah, ok, why didn't you say so in the first place, you winblows?"
;-P
> Forgot to mention, Mr Goddard is my boss! :-)
Tup, Andy is the nearest thing I have to a boss... hehehe ;-P
>>OTOH, may be ProxyGenerator should go into the core... Dunno.
>
>
> It might make sense because it's basically a file generator but it gets
> "files" off somewhere else (It's like the file generator + steroids), but it
> relies on two external things: commons-httpclient and commons-logkit (hey'
> it's not me! :-) It's httpclient).
Then it makes perfectly sense to put it out of the core.
The core should have the least possible dependencies: JDK, Avalon,
Xml-stuff.
That's also why I want to separate the environments too as done with blocks.
> Shall I put it now alongside the WebServiceProxyGenerator, then I refactor
> all samples, and then once that step is done and we're all happy with it, we
> decide to either keep it in there or separate it out as a block, and "get
> rid" of the old version???
Rule of the thumb: in a block we have classes that have:
- roughly same jar dependencies
- they are used in exclusion for the same task
- they are used together for a single goal
We also have generic blocks and specific blocks.
"database" is generic.
"batik" is specific.
Eventually we will have a generic database block and specific sublocks,
but that's inheritance, and a later thing to do.
> (I'm new to the game,
suuuuuureeeee ;-P
> so, it's your call folks)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10/2/03 18:30, "Vadim Gritsenko" <va...@verizon.net> 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 for Buzzword"...
- If I say "web service", Goddard will again reply "too complicated, we
don't want to use that J2EE thing"
- If I say "XML over HTTP via a proxy", Goddard will reply: "Ah, ok, why
didn't you say so in the first place, you muppet?"
Forgot to mention, Mr Goddard is my boss! :-)
> OTOH, may be ProxyGenerator should go into the core... Dunno.
It might make sense because it's basically a file generator but it gets
"files" off somewhere else (It's like the file generator + steroids), but it
relies on two external things: commons-httpclient and commons-logkit (hey'
it's not me! :-) It's httpclient).
Shall I put it now alongside the WebServiceProxyGenerator, then I refactor
all samples, and then once that step is done and we're all happy with it, we
decide to either keep it in there or separate it out as a block, and "get
rid" of the old version???
(I'm new to the game, so, it's your call folks)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:
>On 10/2/03 17:37, "Vadim Gritsenko" <va...@verizon.net> 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 writing anything even _close_ to some WSDL markup! :-)
>IMO, the problem of accessing XML remotely over an HTTP connection is quite
>different from doing the whole "web-services" thing... They should be two
>separate blocks, IMVVVVHO...
>
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.
OTOH, may be ProxyGenerator should go into the core... Dunno.
Vadim
> Pier
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10/2/03 17:37, "Vadim Gritsenko" <va...@verizon.net> 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, I basically have a
Cocoon instance which (behind some tons of firewalls), deals with databases
and search engines... All this data is then "presented" in XML (mainly RSS
and some proprietary doctypes) to a "front-end" rendering-only cocoon
instance, caching the backend when needed, and presenting the requested
content to the client (we are going to have several of those)...
Basically:
+--------+ JDBC
| Oracle | ------+
+--------+ | +------------------+
+---> | "Backend" Cocoon |
+--------+ | +------------------+
| Lucene | ------+ |
+--------+ FILES | XML over HTTP (RSS + Proprietary)
|
+--------------------+--------------------+
| | |
V V V
+------------------+ +------------------+ +------------------+
| Rendering Cocoon | | Rendering Cocoon | | Rendering Cocoon |
+------------------+ +------------------+ +------------------+
| | |
| HTML | WAP | Feed (proprietary)
| | |
V V V
+--------+ +--------+ +--------+
| Client | | Client | | Client |
+--------+ +--------+ +--------+
In other words, the "Backend" instance deals with the databases and our
search indexes, caching the data (for example an article) locally. When one
of the front-ends requires an article, I don't have to think about
replicating the same database-magic in the front-end, I simply say that my
article resides on the backend, and I use the HTTP Proxy to get it.
So, literally, for me an article is that XML document found at
http://backend/article?id=xyz
This is what concerns _me_. The graphics team have their all set of stuff in
the front-end that they can deal with (and which I don't really care about).
They only know that the article is at that given URL...
But that's far from writing anything even _close_ to some WSDL markup! :-)
IMO, the problem of accessing XML remotely over an HTTP connection is quite
different from doing the whole "web-services" thing... They should be two
separate blocks, IMVVVVHO...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:
>On 10/2/03 16:56, "Vadim Gritsenko" <va...@verizon.net> 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
>>>
>>>
>>>
>>>
>>Deja vu?
>>
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104399362409715&w=2
>>
>>
>
>Awww... F*** me... I missed the first reply :-( I should be more careful
>(sound of Pier beating himself with a huge cluestick)...
>
>
:)))
>Anyhow, I stretched it and partially rewrote it to handle the "new" commons
>httpclient, to parse straight from the response inputstream and to be a
>little bit more customizable in terms of configuration...
>
>Since I don't think it's that appropriate to keep it in the "core"
>distribution, I wanted to make a block out of it (and I can try figuring it
>out how to make it! :-) it ain't obvious)...
>
>Point is, since it's quite different, where should I put it? In "src/blocks"
>and refactor all examples and documentation or in "src/scratchpad" and work
>my way out of there?
>
>
How about webservices (ws?) block? We have axis stuff in the scratchpad
which also could be thrown into it.
Vadim
> Pier
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10/2/03 16:56, "Vadim Gritsenko" <va...@verizon.net> 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
>>
>>
>
> Deja vu?
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104399362409715&w=2
Awww... F*** me... I missed the first reply :-( I should be more careful
(sound of Pier beating himself with a huge cluestick)...
Anyhow, I stretched it and partially rewrote it to handle the "new" commons
httpclient, to parse straight from the response inputstream and to be a
little bit more customizable in terms of configuration...
Since I don't think it's that appropriate to keep it in the "core"
distribution, I wanted to make a block out of it (and I can try figuring it
out how to make it! :-) it ain't obvious)...
Point is, since it's quite different, where should I put it? In "src/blocks"
and refactor all examples and documentation or in "src/scratchpad" and work
my way out of there?
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WSProxyGenerator
Posted by Vadim Gritsenko <va...@verizon.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org