RE: [C2] SOAP - Scanned for virus
Hi, If you mean the stuff I sent to the mailing list: it ended up in the cvs bij mistake. They were just meant as an example to show what could be done with soap. In my opinion, an implementation of soap in C2 should not just be a logicsheet, but an extra channel in the interface with cocoon (both serving soap requests and performing soap requests on other servers). This way it should be easier to implement xml based services in a cocoon application instead of only xml based publishing. I think Giacomo has some great ideas on the subject. You can also check my previous posts on the subject. Greetings, Michael Homeijer -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED]] Sent: vrijdag 13 juli 2001 21:50 To: [EMAIL PROTECTED] Subject: Re: [C2] SOAP - Scanned for virus Drasko Kokic wrote: Berin, Who is the maintainer of the SOAP addition to C2.1 ? Is it possible to extract SOAP part out of the C2.1 and try to make it working on C2.0? I need to implement it rather soon and could just about wait for C2.0 to be released (C2.1 would probably be far too late). I'm not sure. Cocoon 2.1 is simply the same as Cocoon 2.0 with some extra stuff. Try just pulling 2.1 from CVS, and extract what you need. TIA Drasko --- Berin Loritsch [EMAIL PROTECTED] wrote: Drasko Kokic wrote: Uli, have you thought about redesigning the SOAP taglib (logicsheet?) so that it is portable to C2? I would need to have it running fairly soon and am ready to put in some eforts :-) With regards to the auth taglib, I would still suggest that you look into the RequestIntercepter implementation of the Context Based Security spec. It is 100% portable (between C1 and C2 of course :-) I believe the CVS for Cocoon 2.1 has SOAP support using the Axis jar. You may want to verify It was included in Cocoon 2.1 due to its newness and it not being tested yet. As to the Context Based Security spec, do you have a URL? I am interested in looking at it. Drasko --- Uli Mayring [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2001, Berin Loritsch wrote: I think you may already be used to not getting the output stream in Cocoon 1. In Cocoon1 it is actually possible to get the OutputStream, I'm using that in my soap taglib. My auth taglib makes heavy use of redirects (such as redirecting you to the login page, if you try to access a protected page and have not authenticated). So these two taglibs, which I use a lot in my Cocoon1 apps, are not portable to Cocoon2. Back when XSP taglibs first appeared, it was said that their advantage is that implementations can change, the interface remains the same. Of course now that XSP itself works differently, this advantage is gone. It's always a trade-off between backwards compatibility and new features. I'm sorry to hear that the XSP model was not deemed fit to last across different versions of Cocoon - I wonder if it will change again for Cocoon3. Perhaps the answer lies elsewhere: implement XSP as an Avalon block, add some parts of Tomcat, Xerces and Xalan as blocks and I won't need Cocoon anymore to build web applications. That's the beauty of OpenSource, that these things are possible. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. Ok, thanks for the info, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [C2] SOAP - Scanned for virus
Quoting Michael Homeijer [EMAIL PROTECTED]: Hi, If you mean the stuff I sent to the mailing list: it ended up in the cvs bij mistake. They were just meant as an example to show what could be done with soap. In my opinion, an implementation of soap in C2 should not just be a logicsheet, but an extra channel in the interface with cocoon (both serving soap requests and performing soap requests on other servers). This way it should be easier to implement xml based services in a cocoon application instead of only xml based publishing. I think Giacomo has some great ideas on the subject. You can also check my previous posts on the subject. We had to write a C2 app that is able to serve SOAP clients as well as browsers so the approach we've take is that we've put the application logic into beans that are XML'izable themselfs (I've mentioned our toolkit to produce the beans in another mail earlier). The way we do it is that we have ConnectorActions that sits on top of the different URIs to accept the requests. So we ended up with a SOAPConnectorAction and a HttpConnectorAction. The responsability they have is simply build a bean that represents the request either out of the SOAP message of from the GET/POST. This bean is simply used as a Command that is processed by other components/Actions before the final response bean is created. This response bean is depending on the requesting client xml'ized down the pipeline by a BeanSOAPGenerator (very simple) for the SOAP client or processed in an XSP page to present the content together with aggregated stuff (header, navbar, footer, etc.) for the browser clients. Giacomo Greetings, Michael Homeijer -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED]] Sent: vrijdag 13 juli 2001 21:50 To: [EMAIL PROTECTED] Subject: Re: [C2] SOAP - Scanned for virus Drasko Kokic wrote: Berin, Who is the maintainer of the SOAP addition to C2.1 ? Is it possible to extract SOAP part out of the C2.1 and try to make it working on C2.0? I need to implement it rather soon and could just about wait for C2.0 to be released (C2.1 would probably be far too late). I'm not sure. Cocoon 2.1 is simply the same as Cocoon 2.0 with some extra stuff. Try just pulling 2.1 from CVS, and extract what you need. TIA Drasko --- Berin Loritsch [EMAIL PROTECTED] wrote: Drasko Kokic wrote: Uli, have you thought about redesigning the SOAP taglib (logicsheet?) so that it is portable to C2? I would need to have it running fairly soon and am ready to put in some eforts :-) With regards to the auth taglib, I would still suggest that you look into the RequestIntercepter implementation of the Context Based Security spec. It is 100% portable (between C1 and C2 of course :-) I believe the CVS for Cocoon 2.1 has SOAP support using the Axis jar. You may want to verify It was included in Cocoon 2.1 due to its newness and it not being tested yet. As to the Context Based Security spec, do you have a URL? I am interested in looking at it. Drasko --- Uli Mayring [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2001, Berin Loritsch wrote: I think you may already be used to not getting the output stream in Cocoon 1. In Cocoon1 it is actually possible to get the OutputStream, I'm using that in my soap taglib. My auth taglib makes heavy use of redirects (such as redirecting you to the login page, if you try to access a protected page and have not authenticated). So these two taglibs, which I use a lot in my Cocoon1 apps, are not portable to Cocoon2. Back when XSP taglibs first appeared, it was said that their advantage is that implementations can change, the interface remains the same. Of course now that XSP itself works differently, this advantage is gone. It's always a trade-off between backwards compatibility and new features. I'm sorry to hear that the XSP model was not deemed fit to last across different versions of Cocoon - I wonder if it will change again for Cocoon3. Perhaps the answer lies elsewhere: implement XSP as an Avalon block, add some parts of Tomcat, Xerces and Xalan as blocks and I won't need Cocoon anymore to build web applications. That's the beauty of OpenSource, that these things are possible. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. Ok, thanks
