You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2001/10/10 23:31:32 UTC
Re: [C2.1] new SOAP logicsheet
On Wed, 10 Oct 2001 14:01:33 -0700 (PDT), Davanum Srinivas <di...@yahoo.com> wrote:
> Thanks a ton for your contribution. Checked it in. Please cross check.
> - I have added it to the main page too for better visibility.
> - Fixed hard coded /home/ovidiu strings.
> - Fixed imports in URLSource that went bad after the merge.
Oops, sorry about this, I forgot to remove them ;-)
> One Request, If we can get rid of the HTTPClient dependency it will be great!!! Please take a loo
> k
> at http://www.javaworld.com/javaworld/javatips/jw-javatip34.html.
Yes, I know about URL and URLConnection. However they are rather badly
implemented in Sun's JDK. They throw exceptions if the response code
from the server is not "200 OK", and as a result I can't obtain the
SOAP response from the server. The HTTPClient library gives this
ability, plus it provides many more features, like transparent
HTTP/1.1 support, proxies (both HTTP proxy and SOCKS), SSL etc. I
don't want to reinvent the wheel and write them in SOAPHelper again.
I've also looked at the httpClient from Jakarta common's, but it's
still far from being usable. I'll check it out in a few months, and if
I have time work a little bit on it.
BTW, did you incorporate the HTTPClient.jar in CVS?
Thanks,
Ovidiu
> --- Ovidiu Predescu <ov...@cup.hp.com> wrote:
> > I sent this patch yesterday, but it bounced back because it was bigger than
> > 100,000 bytes. I've placed the jar file mentioned below at:
> >
> > http://www.geocities.com/SiliconValley/Monitor/7464/HTTPClient.jar
> >
> > Cheers,
> > Ovidiu
> >
> > --
> >
> > Hi,
> >
> > This patch adds implements a SOAP logicsheet entirely using Cocoon concepts. It
> > doesn't depend on any SOAP client library to do the marshaling and unmarshaling
> > of the SOAP body.
> >
> > The SOAP logicsheet is based on another concept, which I called XScript. This
> > allows one to define pseudo-variables in XSP, whose value can be inline XML or
> > any XML content obtained from an URL resource. Such a value is an
> > XScriptObject, and can contain in general case any content, not only XML.
> >
> > <xscript:variable name="var1">
> > <b>this is a title</b>
> > </xscript:variable>
> >
> > <xscript:variable name="var2" href="docs/samples/data.xml"/>
> >
> > Once a variable is defined, you can refer to it by name, and have its XML
> > content inserted in the generated XML.
> >
> > <xscript:get name="var1"/>
> >
> > You can transform the value of an XScript variable using XSLT stylesheets.
> > Since an XSLT stylesheet is an XML document, it can be represented as an
> > XScript object. XScript provides ways to transform an XScript object into
> > another XScript variable.
> >
> > Example:
> >
> > // Transform the content of "var1" through "mystyle.xsl" and insert the
> > // resulting XML in the generated XML document.
> > <xscript:variable name="mystyle" href="stylesheets/mystyle.xsl"/>
> > <xscript:transform name="var1" stylesheet="mystyle"/>
> >
> > // Similarly as above, but assign the result of the transformation to another
> > // XScript object
> > <xscript:variable name="result">
> > <xscript:transform name="var1" stylesheet="mystyle"/>
> > </xscript:variable>
> >
> > Each XScript variable can be declared to be visible in a particular scope. The
> > available scopes are:
> >
> > - global, you can access the variable from any page, by any user.
> >
> > - session, the variable is visible only in the scope of the session it was
> > created in.
> >
> > - page, the variable is visible only in the page it was created in.
> >
> > The scope is specified using the "scope" attribute:
> >
> > <xscript:variable name="var1" scope="session"/>
> > <xscript:variable name="mystyle" scope="global"/>
> > <xscript:variable name="page-var" scope="page"/>
> >
> > The default scope is "session".
> >
> > You can create XScript variables using the content of other XScript variables,
> > or using a mixture of inline XML and values of different XScript variables:
> >
> > <xscript:variable name="var3">
> > <body>
> > <title><xscript:get name="var1"/></title>
> > <content><xscript:get name="result"/></content>
> > </body>
> > </xscript:variable>
> >
> > The SOAP logicsheet is implemented using XScript. It collects in an XScript
> > variable the inline XML fragment representing the SOAP body, and then it posts
> > it to the specified URL.
> >
> > I don't have much documentation for it, but I hope I'll come with something in
> > the next few days.
> >
> > Besides the patch attached, you also need to place the HTTPClient.jar library
> > from
> >
> > http://www.innovation.ch/java/HTTPClient/
> >
> > in the lib/ directory. For your convenience I attached the jar file to this
> > email. I tried playing with the jakarta-commons httpClient library, but I
> > didn't get too far with it.
> >
> > Regards,
> > --
> > Ovidiu Predescu <ov...@cup.hp.com>
> > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
> >
> >
>
> > ATTACHMENT part 2 application/x-gzip name=cocoon.diff.gz
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
> =====
> Davanum Srinivas - http://jguru.com/dims/
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2.1] new SOAP logicsheet
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
> > Hi Ovidiu,
> >
> > due to the problems with HTTPClient library, I removed it
> > from cvs and commented out the using functions in the SOAPHelper
> > class. This of course breaks your logicsheet.
> >
> > Could you please take care of this? Another problem with
> > your could is that it requires jdk 1.3. Until now, we still
> > want to be compatible with 1.2, so you can't use URL.getPath().
>
> Um, The Batik project requires JDK 1.3--I don't know if this has
> bearing on us, but I found that out when I was trying to find info
> on extending it to use our protocols. (They have hooks...).
>
I personally would love if we *update* to JDK 1.3 - but until now
we didn't have a vote on it and the last time we discussed this
(it might be in June or July this year) we decided to stick to JDK 1.2.
(That's actually why the URLSource uses reflection).
Carsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2.1] new SOAP logicsheet
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi Ovidiu,
>
> due to the problems with HTTPClient library, I removed it
> from cvs and commented out the using functions in the SOAPHelper
> class. This of course breaks your logicsheet.
>
> Could you please take care of this? Another problem with
> your could is that it requires jdk 1.3. Until now, we still
> want to be compatible with 1.2, so you can't use URL.getPath().
Um, The Batik project requires JDK 1.3--I don't know if this has
bearing on us, but I found that out when I was trying to find info
on extending it to use our protocols. (They have hooks...).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2.1] new SOAP logicsheet
Posted by Davanum Srinivas <di...@yahoo.com>.
My Mistake Stefano. Thanks for the catch.
-- dims
--- Carsten Ziegeler <cz...@sundn.de> wrote:
> Hi Ovidiu,
>
> due to the problems with HTTPClient library, I removed it
> from cvs and commented out the using functions in the SOAPHelper
> class. This of course breaks your logicsheet.
>
> Could you please take care of this? Another problem with
> your could is that it requires jdk 1.3. Until now, we still
> want to be compatible with 1.2, so you can't use URL.getPath().
>
> If your code really requires one or both we should think of
> making it optional.
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> > Gesendet: Mittwoch, 10. Oktober 2001 23:32
> > An: Davanum Srinivas
> > Cc: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2.1] new SOAP logicsheet
> >
> >
> > On Wed, 10 Oct 2001 14:01:33 -0700 (PDT), Davanum Srinivas
> > <di...@yahoo.com> wrote:
> >
> > > Thanks a ton for your contribution. Checked it in. Please cross check.
> > > - I have added it to the main page too for better visibility.
> > > - Fixed hard coded /home/ovidiu strings.
> > > - Fixed imports in URLSource that went bad after the merge.
> >
> > Oops, sorry about this, I forgot to remove them ;-)
> >
> > > One Request, If we can get rid of the HTTPClient dependency it
> > will be great!!! Please take a loo
> > > k
> > > at http://www.javaworld.com/javaworld/javatips/jw-javatip34.html.
> >
> > Yes, I know about URL and URLConnection. However they are rather badly
> > implemented in Sun's JDK. They throw exceptions if the response code
> > from the server is not "200 OK", and as a result I can't obtain the
> > SOAP response from the server. The HTTPClient library gives this
> > ability, plus it provides many more features, like transparent
> > HTTP/1.1 support, proxies (both HTTP proxy and SOCKS), SSL etc. I
> > don't want to reinvent the wheel and write them in SOAPHelper again.
> >
> > I've also looked at the httpClient from Jakarta common's, but it's
> > still far from being usable. I'll check it out in a few months, and if
> > I have time work a little bit on it.
> >
> > BTW, did you incorporate the HTTPClient.jar in CVS?
> >
> > Thanks,
> > Ovidiu
> >
> > > --- Ovidiu Predescu <ov...@cup.hp.com> wrote:
> > > > I sent this patch yesterday, but it bounced back because it
> > was bigger than
> > > > 100,000 bytes. I've placed the jar file mentioned below at:
> > > >
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/HTTPClient.jar
> > > >
> > > > Cheers,
> > > > Ovidiu
> > > >
> > > > --
> > > >
> > > > Hi,
> > > >
> > > > This patch adds implements a SOAP logicsheet entirely using
> > Cocoon concepts. It
> > > > doesn't depend on any SOAP client library to do the
> > marshaling and unmarshaling
> > > > of the SOAP body.
> > > >
> > > > The SOAP logicsheet is based on another concept, which I
> > called XScript. This
> > > > allows one to define pseudo-variables in XSP, whose value can
> > be inline XML or
> > > > any XML content obtained from an URL resource. Such a value is an
> > > > XScriptObject, and can contain in general case any content,
> > not only XML.
> > > >
> > > > <xscript:variable name="var1">
> > > > <b>this is a title</b>
> > > > </xscript:variable>
> > > >
> > > > <xscript:variable name="var2" href="docs/samples/data.xml"/>
> > > >
> > > > Once a variable is defined, you can refer to it by name, and
> > have its XML
> > > > content inserted in the generated XML.
> > > >
> > > > <xscript:get name="var1"/>
> > > >
> > > > You can transform the value of an XScript variable using XSLT
> > stylesheets.
> > > > Since an XSLT stylesheet is an XML document, it can be
> > represented as an
> > > > XScript object. XScript provides ways to transform an XScript
> > object into
> > > > another XScript variable.
> > > >
> > > > Example:
> > > >
> > > > // Transform the content of "var1" through "mystyle.xsl" and
> > insert the
> > > > // resulting XML in the generated XML document.
> > > > <xscript:variable name="mystyle" href="stylesheets/mystyle.xsl"/>
> > > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > >
> > > > // Similarly as above, but assign the result of the
> > transformation to another
> > > > // XScript object
> > > > <xscript:variable name="result">
> > > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > > </xscript:variable>
> > > >
> > > > Each XScript variable can be declared to be visible in a
> > particular scope. The
> > > > available scopes are:
> > > >
> > > > - global, you can access the variable from any page, by any user.
> > > >
> > > > - session, the variable is visible only in the scope of the
> > session it was
> > > > created in.
> > > >
> > > > - page, the variable is visible only in the page it was created in.
> > > >
> > > > The scope is specified using the "scope" attribute:
> > > >
> > > > <xscript:variable name="var1" scope="session"/>
> > > > <xscript:variable name="mystyle" scope="global"/>
> > > > <xscript:variable name="page-var" scope="page"/>
> > > >
> > > > The default scope is "session".
> > > >
> > > > You can create XScript variables using the content of other
> > XScript variables,
> > > > or using a mixture of inline XML and values of different
> > XScript variables:
> > > >
> > > > <xscript:variable name="var3">
> > > > <body>
> > > > <title><xscript:get name="var1"/></title>
> > > > <content><xscript:get name="result"/></content>
> > > > </body>
> > > > </xscript:variable>
> > > >
> > > > The SOAP logicsheet is implemented using XScript. It collects
> > in an XScript
> > > > variable the inline XML fragment representing the SOAP body,
> > and then it posts
> > > > it to the specified URL.
> > > >
> > > > I don't have much documentation for it, but I hope I'll come
> > with something in
> > > > the next few days.
> > > >
> > > > Besides the patch attached, you also need to place the
> > HTTPClient.jar library
> > > > from
> > > >
> > > > http://www.innovation.ch/java/HTTPClient/
> > > >
> > > > in the lib/ directory. For your convenience I attached the
> > jar file to this
> > > > email. I tried playing with the jakarta-commons httpClient
> > library, but I
> > > > didn't get too far with it.
> > > >
> > > > Regards,
> > > > --
> > > > Ovidiu Predescu <ov...@cup.hp.com>
> > > > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > > > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU,
> > Emacs, other stuff)
> > > >
> > > >
> > >
> > > > ATTACHMENT part 2 application/x-gzip name=cocoon.diff.gz
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > >
> > > =====
> > > Davanum Srinivas - http://jguru.com/dims/
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
>
=== message truncated ===
=====
Davanum Srinivas - http://jguru.com/dims/
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2.1] new SOAP logicsheet
Posted by Davanum Srinivas <di...@yahoo.com>.
Ovidiu,
Since "We have to eat our own dog-food". See attached Test.java that uses httpClient from Jakarta
commons to post the SOAP request and gets the output successfully. I'd really appreciate it if you
could take some time to post a patch for switching to httpClient from Jakarta commons.....
Thanks,
dims
--- Carsten Ziegeler <cz...@sundn.de> wrote:
> Hi Ovidiu,
>
> due to the problems with HTTPClient library, I removed it
> from cvs and commented out the using functions in the SOAPHelper
> class. This of course breaks your logicsheet.
>
> Could you please take care of this? Another problem with
> your could is that it requires jdk 1.3. Until now, we still
> want to be compatible with 1.2, so you can't use URL.getPath().
>
> If your code really requires one or both we should think of
> making it optional.
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> > Gesendet: Mittwoch, 10. Oktober 2001 23:32
> > An: Davanum Srinivas
> > Cc: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2.1] new SOAP logicsheet
> >
> >
> > On Wed, 10 Oct 2001 14:01:33 -0700 (PDT), Davanum Srinivas
> > <di...@yahoo.com> wrote:
> >
> > > Thanks a ton for your contribution. Checked it in. Please cross check.
> > > - I have added it to the main page too for better visibility.
> > > - Fixed hard coded /home/ovidiu strings.
> > > - Fixed imports in URLSource that went bad after the merge.
> >
> > Oops, sorry about this, I forgot to remove them ;-)
> >
> > > One Request, If we can get rid of the HTTPClient dependency it
> > will be great!!! Please take a loo
> > > k
> > > at http://www.javaworld.com/javaworld/javatips/jw-javatip34.html.
> >
> > Yes, I know about URL and URLConnection. However they are rather badly
> > implemented in Sun's JDK. They throw exceptions if the response code
> > from the server is not "200 OK", and as a result I can't obtain the
> > SOAP response from the server. The HTTPClient library gives this
> > ability, plus it provides many more features, like transparent
> > HTTP/1.1 support, proxies (both HTTP proxy and SOCKS), SSL etc. I
> > don't want to reinvent the wheel and write them in SOAPHelper again.
> >
> > I've also looked at the httpClient from Jakarta common's, but it's
> > still far from being usable. I'll check it out in a few months, and if
> > I have time work a little bit on it.
> >
> > BTW, did you incorporate the HTTPClient.jar in CVS?
> >
> > Thanks,
> > Ovidiu
> >
> > > --- Ovidiu Predescu <ov...@cup.hp.com> wrote:
> > > > I sent this patch yesterday, but it bounced back because it
> > was bigger than
> > > > 100,000 bytes. I've placed the jar file mentioned below at:
> > > >
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/HTTPClient.jar
> > > >
> > > > Cheers,
> > > > Ovidiu
> > > >
> > > > --
> > > >
> > > > Hi,
> > > >
> > > > This patch adds implements a SOAP logicsheet entirely using
> > Cocoon concepts. It
> > > > doesn't depend on any SOAP client library to do the
> > marshaling and unmarshaling
> > > > of the SOAP body.
> > > >
> > > > The SOAP logicsheet is based on another concept, which I
> > called XScript. This
> > > > allows one to define pseudo-variables in XSP, whose value can
> > be inline XML or
> > > > any XML content obtained from an URL resource. Such a value is an
> > > > XScriptObject, and can contain in general case any content,
> > not only XML.
> > > >
> > > > <xscript:variable name="var1">
> > > > <b>this is a title</b>
> > > > </xscript:variable>
> > > >
> > > > <xscript:variable name="var2" href="docs/samples/data.xml"/>
> > > >
> > > > Once a variable is defined, you can refer to it by name, and
> > have its XML
> > > > content inserted in the generated XML.
> > > >
> > > > <xscript:get name="var1"/>
> > > >
> > > > You can transform the value of an XScript variable using XSLT
> > stylesheets.
> > > > Since an XSLT stylesheet is an XML document, it can be
> > represented as an
> > > > XScript object. XScript provides ways to transform an XScript
> > object into
> > > > another XScript variable.
> > > >
> > > > Example:
> > > >
> > > > // Transform the content of "var1" through "mystyle.xsl" and
> > insert the
> > > > // resulting XML in the generated XML document.
> > > > <xscript:variable name="mystyle" href="stylesheets/mystyle.xsl"/>
> > > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > >
> > > > // Similarly as above, but assign the result of the
> > transformation to another
> > > > // XScript object
> > > > <xscript:variable name="result">
> > > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > > </xscript:variable>
> > > >
> > > > Each XScript variable can be declared to be visible in a
> > particular scope. The
> > > > available scopes are:
> > > >
> > > > - global, you can access the variable from any page, by any user.
> > > >
> > > > - session, the variable is visible only in the scope of the
> > session it was
> > > > created in.
> > > >
> > > > - page, the variable is visible only in the page it was created in.
> > > >
> > > > The scope is specified using the "scope" attribute:
> > > >
> > > > <xscript:variable name="var1" scope="session"/>
> > > > <xscript:variable name="mystyle" scope="global"/>
> > > > <xscript:variable name="page-var" scope="page"/>
> > > >
> > > > The default scope is "session".
> > > >
> > > > You can create XScript variables using the content of other
> > XScript variables,
> > > > or using a mixture of inline XML and values of different
> > XScript variables:
> > > >
> > > > <xscript:variable name="var3">
> > > > <body>
> > > > <title><xscript:get name="var1"/></title>
> > > > <content><xscript:get name="result"/></content>
> > > > </body>
> > > > </xscript:variable>
> > > >
> > > > The SOAP logicsheet is implemented using XScript. It collects
> > in an XScript
> > > > variable the inline XML fragment representing the SOAP body,
> > and then it posts
> > > > it to the specified URL.
> > > >
> > > > I don't have much documentation for it, but I hope I'll come
> > with something in
> > > > the next few days.
> > > >
> > > > Besides the patch attached, you also need to place the
> > HTTPClient.jar library
> > > > from
> > > >
> > > > http://www.innovation.ch/java/HTTPClient/
> > > >
> > > > in the lib/ directory. For your convenience I attached the
> > jar file to this
> > > > email. I tried playing with the jakarta-commons httpClient
> > library, but I
> > > > didn't get too far with it.
> > > >
> > > > Regards,
> > > > --
> > > > Ovidiu Predescu <ov...@cup.hp.com>
> > > > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > > > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU,
> > Emacs, other stuff)
> > > >
> > > >
> > >
> > > > ATTACHMENT part 2 application/x-gzip name=cocoon.diff.gz
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > >
> > > =====
> > > Davanum Srinivas - http://jguru.com/dims/
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
>
=== message truncated ===
=====
Davanum Srinivas - http://jguru.com/dims/
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
AW: [C2.1] new SOAP logicsheet
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Ovidiu,
due to the problems with HTTPClient library, I removed it
from cvs and commented out the using functions in the SOAPHelper
class. This of course breaks your logicsheet.
Could you please take care of this? Another problem with
your could is that it requires jdk 1.3. Until now, we still
want to be compatible with 1.2, so you can't use URL.getPath().
If your code really requires one or both we should think of
making it optional.
Carsten
> -----Ursprungliche Nachricht-----
> Von: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> Gesendet: Mittwoch, 10. Oktober 2001 23:32
> An: Davanum Srinivas
> Cc: cocoon-dev@xml.apache.org
> Betreff: Re: [C2.1] new SOAP logicsheet
>
>
> On Wed, 10 Oct 2001 14:01:33 -0700 (PDT), Davanum Srinivas
> <di...@yahoo.com> wrote:
>
> > Thanks a ton for your contribution. Checked it in. Please cross check.
> > - I have added it to the main page too for better visibility.
> > - Fixed hard coded /home/ovidiu strings.
> > - Fixed imports in URLSource that went bad after the merge.
>
> Oops, sorry about this, I forgot to remove them ;-)
>
> > One Request, If we can get rid of the HTTPClient dependency it
> will be great!!! Please take a loo
> > k
> > at http://www.javaworld.com/javaworld/javatips/jw-javatip34.html.
>
> Yes, I know about URL and URLConnection. However they are rather badly
> implemented in Sun's JDK. They throw exceptions if the response code
> from the server is not "200 OK", and as a result I can't obtain the
> SOAP response from the server. The HTTPClient library gives this
> ability, plus it provides many more features, like transparent
> HTTP/1.1 support, proxies (both HTTP proxy and SOCKS), SSL etc. I
> don't want to reinvent the wheel and write them in SOAPHelper again.
>
> I've also looked at the httpClient from Jakarta common's, but it's
> still far from being usable. I'll check it out in a few months, and if
> I have time work a little bit on it.
>
> BTW, did you incorporate the HTTPClient.jar in CVS?
>
> Thanks,
> Ovidiu
>
> > --- Ovidiu Predescu <ov...@cup.hp.com> wrote:
> > > I sent this patch yesterday, but it bounced back because it
> was bigger than
> > > 100,000 bytes. I've placed the jar file mentioned below at:
> > >
> > > http://www.geocities.com/SiliconValley/Monitor/7464/HTTPClient.jar
> > >
> > > Cheers,
> > > Ovidiu
> > >
> > > --
> > >
> > > Hi,
> > >
> > > This patch adds implements a SOAP logicsheet entirely using
> Cocoon concepts. It
> > > doesn't depend on any SOAP client library to do the
> marshaling and unmarshaling
> > > of the SOAP body.
> > >
> > > The SOAP logicsheet is based on another concept, which I
> called XScript. This
> > > allows one to define pseudo-variables in XSP, whose value can
> be inline XML or
> > > any XML content obtained from an URL resource. Such a value is an
> > > XScriptObject, and can contain in general case any content,
> not only XML.
> > >
> > > <xscript:variable name="var1">
> > > <b>this is a title</b>
> > > </xscript:variable>
> > >
> > > <xscript:variable name="var2" href="docs/samples/data.xml"/>
> > >
> > > Once a variable is defined, you can refer to it by name, and
> have its XML
> > > content inserted in the generated XML.
> > >
> > > <xscript:get name="var1"/>
> > >
> > > You can transform the value of an XScript variable using XSLT
> stylesheets.
> > > Since an XSLT stylesheet is an XML document, it can be
> represented as an
> > > XScript object. XScript provides ways to transform an XScript
> object into
> > > another XScript variable.
> > >
> > > Example:
> > >
> > > // Transform the content of "var1" through "mystyle.xsl" and
> insert the
> > > // resulting XML in the generated XML document.
> > > <xscript:variable name="mystyle" href="stylesheets/mystyle.xsl"/>
> > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > >
> > > // Similarly as above, but assign the result of the
> transformation to another
> > > // XScript object
> > > <xscript:variable name="result">
> > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > </xscript:variable>
> > >
> > > Each XScript variable can be declared to be visible in a
> particular scope. The
> > > available scopes are:
> > >
> > > - global, you can access the variable from any page, by any user.
> > >
> > > - session, the variable is visible only in the scope of the
> session it was
> > > created in.
> > >
> > > - page, the variable is visible only in the page it was created in.
> > >
> > > The scope is specified using the "scope" attribute:
> > >
> > > <xscript:variable name="var1" scope="session"/>
> > > <xscript:variable name="mystyle" scope="global"/>
> > > <xscript:variable name="page-var" scope="page"/>
> > >
> > > The default scope is "session".
> > >
> > > You can create XScript variables using the content of other
> XScript variables,
> > > or using a mixture of inline XML and values of different
> XScript variables:
> > >
> > > <xscript:variable name="var3">
> > > <body>
> > > <title><xscript:get name="var1"/></title>
> > > <content><xscript:get name="result"/></content>
> > > </body>
> > > </xscript:variable>
> > >
> > > The SOAP logicsheet is implemented using XScript. It collects
> in an XScript
> > > variable the inline XML fragment representing the SOAP body,
> and then it posts
> > > it to the specified URL.
> > >
> > > I don't have much documentation for it, but I hope I'll come
> with something in
> > > the next few days.
> > >
> > > Besides the patch attached, you also need to place the
> HTTPClient.jar library
> > > from
> > >
> > > http://www.innovation.ch/java/HTTPClient/
> > >
> > > in the lib/ directory. For your convenience I attached the
> jar file to this
> > > email. I tried playing with the jakarta-commons httpClient
> library, but I
> > > didn't get too far with it.
> > >
> > > Regards,
> > > --
> > > Ovidiu Predescu <ov...@cup.hp.com>
> > > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU,
> Emacs, other stuff)
> > >
> > >
> >
> > > ATTACHMENT part 2 application/x-gzip name=cocoon.diff.gz
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> > =====
> > Davanum Srinivas - http://jguru.com/dims/
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make a great connection at Yahoo! Personals.
> > http://personals.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org