You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <ki...@hp.com> on 2002/02/07 23:22:18 UTC
Dispatcher/Adapter
Hi,
I feel that the tension of release is over, and we can return to the
discussion on my proposal. I propose to add to the Cocoon project
Dispatcher/Adapter concept. This set of interfaces and basic abstraction
allows building pluggable extensions in a more standardized way. The real
life example of such extension is our HP-SOAP Server. (You can download it
from http://www.hpmiddleware.com/download.) But it is just one example, the
imagination can bring much more.
To refresh your memory the proposal, demo , patches and additions can be
found at:
http://soap.bluestone.com/proposal. The real HP-SOAP server in action can be
accessed by:
http://soap.bluestone.com/hpws.
Please note the combination of Cocoon publishing techniques, XSP pages used
as client forms to access SOAP services, with processing capabilities.
Kinga
_________________________________
Kinga Dziembowski
Hewlett Packard
HP Bluestone Middleware Division
6000 Irwin Road
Mt. Laurel, NJ 08054
856.638.6065
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Dispatcher/Adapter
Posted by Vadim Gritsenko <va...@verizon.net>.
I have got an exception:
org.xml.sax.SAXException: Can't have more than one root on a DOM!
:)
BTW: Does this proposal based on DOM? Or is DOM used just in this
example?
Vadim
> -----Original Message-----
> From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)
[mailto:kinga_dziembowski@hp.com]
> Sent: Thursday, February 07, 2002 5:22 PM
> To: cocoon-dev@xml.apache.org
> Subject: Dispatcher/Adapter
>
> Hi,
> I feel that the tension of release is over, and we can return to the
> discussion on my proposal. I propose to add to the Cocoon project
> Dispatcher/Adapter concept. This set of interfaces and basic
abstraction
> allows building pluggable extensions in a more standardized way. The
real
> life example of such extension is our HP-SOAP Server. (You can
download it
> from http://www.hpmiddleware.com/download.) But it is just one
example, the
> imagination can bring much more.
>
> To refresh your memory the proposal, demo , patches and additions can
be
> found at:
> http://soap.bluestone.com/proposal. The real HP-SOAP server in action
can be
> accessed by:
> http://soap.bluestone.com/hpws.
> Please note the combination of Cocoon publishing techniques, XSP pages
used
> as client forms to access SOAP services, with processing capabilities.
>
> Kinga
>
>
>
>
> _________________________________
>
> Kinga Dziembowski
> Hewlett Packard
> HP Bluestone Middleware Division
> 6000 Irwin Road
> Mt. Laurel, NJ 08054
>
> 856.638.6065
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Dispatcher/Adapter
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> DZIEMBOWSKI,KINGA wrote:
>
> Hi,
> I feel that the tension of release is over, and we can return to the
> discussion on my proposal. I propose to add to the Cocoon project
> Dispatcher/Adapter concept. This set of interfaces and basic abstraction
> allows building pluggable extensions in a more standardized way. The real
> life example of such extension is our HP-SOAP Server. (You can download it
> from http://www.hpmiddleware.com/download.) But it is just one
> example, the
> imagination can bring much more.
>
> To refresh your memory the proposal, demo , patches and additions can be
> found at:
> http://soap.bluestone.com/proposal. The real HP-SOAP server in
> action can be
> accessed by:
> http://soap.bluestone.com/hpws.
> Please note the combination of Cocoon publishing techniques, XSP
> pages used
> as client forms to access SOAP services, with processing capabilities.
>
Hi Kinga,
yes we should now come back to this. As some of us here have already stated,
we are very happy about your donation and will accept it.
But, there is this *little* problem with HttpRequest vs Request problem.
If I remember it right, your solution requires some methods which are not
exposed
by the Request object (or Response object?).
I thought a little bit of this problem and I think this is a general problem
Cocoon has. So perhaps we can solve this on a higher level.
There are several custom libraries/projects which rely on the
HttpRequest/HttpResponse
interface exposed by the Java Servlet API. Cocoon decided not to use the
servlet
abstraction but an own one to easier integrate Cocoon into other
environments like CLI
or whatever.
To integrate all these custom libraries (like the HP donation, the PHP
generator
or the Deli component) there are currently two hacks used:
a) A custom component wraps the Cocoon Request/Response objects to provide
the full
Servlet API functionality
b) The HTTP environment puts not only the Cocoon Request/Response but also
the Servlet
variants into the objectModel, so they can directly used by custom
components.
Now, I would like to be able to use all these great custom projects inside
Cocoon
*without* the Servlet API even from CLI. So I think we need an *interface*
from Cocoon
to custom services using the Servlet API.
An easy solution would be to provide a HttpRequest/HttpResponse object in
the objectModel
by the environment as it is already the case today with the HTTP
environment.
Are there better solutions? Is this FS?
Regards,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Dispatcher/Adapter
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi Kinga,
>>
discussion on my proposal. I propose to add to the Cocoon project
Dispatcher/Adapter concept. This set of interfaces and basic abstraction
allows building pluggable extensions in a more standardized way.
<<
Carsten and I are definately +1 on this :-)
Regards
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
-----Ursprüngliche Nachricht-----
Von: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)
[mailto:kinga_dziembowski@hp.com]
Gesendet: Donnerstag, 7. Februar 2002 23:22
An: cocoon-dev@xml.apache.org
Betreff: Dispatcher/Adapter
Hi,
I feel that the tension of release is over, and we can return to the
discussion on my proposal. I propose to add to the Cocoon project
Dispatcher/Adapter concept. This set of interfaces and basic abstraction
allows building pluggable extensions in a more standardized way. The real
life example of such extension is our HP-SOAP Server. (You can download it
from http://www.hpmiddleware.com/download.) But it is just one example, the
imagination can bring much more.
To refresh your memory the proposal, demo , patches and additions can be
found at:
http://soap.bluestone.com/proposal. The real HP-SOAP server in action can be
accessed by:
http://soap.bluestone.com/hpws.
Please note the combination of Cocoon publishing techniques, XSP pages used
as client forms to access SOAP services, with processing capabilities.
Kinga
_________________________________
Kinga Dziembowski
Hewlett Packard
HP Bluestone Middleware Division
6000 Irwin Road
Mt. Laurel, NJ 08054
856.638.6065
---------------------------------------------------------------------
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: Dispatcher/Adapter
Posted by giacomo <gi...@apache.org>.
On Thu, 7 Feb 2002, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote:
> Hi,
> I feel that the tension of release is over, and we can return to the
> discussion on my proposal. I propose to add to the Cocoon project
> Dispatcher/Adapter concept. This set of interfaces and basic abstraction
> allows building pluggable extensions in a more standardized way. The real
> life example of such extension is our HP-SOAP Server. (You can download it
> from http://www.hpmiddleware.com/download.) But it is just one example, the
> imagination can bring much more.
I still have your previous mails marked as "important to answer" in my
mailbox, so expect some comments.
> To refresh your memory the proposal, demo , patches and additions can be
> found at:
> http://soap.bluestone.com/proposal. The real HP-SOAP server in action can be
> accessed by:
> http://soap.bluestone.com/hpws.
> Please note the combination of Cocoon publishing techniques, XSP pages used
> as client forms to access SOAP services, with processing capabilities.
This is exactly what I like Cocoon to be able: Act as a SOAP server as
well as an (Web)App Server and a publishing system and all parts can
communicate together. It doesn't make sense to me to have an isolated
SOAP Server built into Cocoon which from an XSP has to be called via
HTTP (you better deploy Axis for that solution).
I've looked at Axis since a while. What I like best is their client
infrastructure (WSDL2Java, custom transports, etc.). Thus I'd really
like to know what your answers to Sam's question about interoperability
is with your Cocoon SOAP implementation.
What I don't like is the server side architecture (from a Cocooners
point of view). If you look at the picture in
AXIS_HOME/java/docs/MessageServerPath.jpg you are likely to see a cocoon
pipeline from the Request to the Response. Axis calls them Input/Output
Chain of Handlers. But those Handlers don't have anything to do with SAX
ContentHandler (Axis hides SAX handling deep inside by a few calsses).
And thus I still cannot see how to integrate Axis into the Cocoon
architecture as I think they differ too much to be worth refactoring
Axis parts as much to make an Axis Server fit into Cocoon.
I'd also like to hear Dims and Berin (as they should know quite a bid
more than I do about Axis) if you guys see how to integrate it.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org