You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by alu <an...@acision.com> on 2008/08/04 13:30:15 UTC
HttpExchange changes to DefaultExchange - expected?
I noticed that Camel passes an HttpExchange from a Jetty endpoint to the
attached Processor, but that subsequent Processors get a DefaultExchange.
First question: is this designed/expected behaviour?
Then: would it be possible to keep the HttpExchange (instead of a
DefaultExchange) in subsequent Processors? What is needed to achieve this?
The problem is, I need access to the HttpServletRequest and
HttpServletResponse stuff in subsequent Processors, but only HttpExchange
provides this.
See the attached test HttpExchangeTest.java which yields
#1: class org.apache.camel.component.http.HttpExchange
#2: class org.apache.camel.impl.DefaultExchange
http://www.nabble.com/file/p18809523/HttpExchangeTest.java
HttpExchangeTest.java
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18809523.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HttpExchange changes to DefaultExchange - expected?
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
Just mind thought that it is not all transport types (e.g. JMS) that can safely propagate headers over the wire. So if you send the exchange to a JMS queue and then retrieve it later from the JMS queue then the HttpSession object is not there anymore. The JMS spec doesn't allow sending objects as JMS headers.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Claus Ibsen [mailto:ci@silverbullet.dk]
Sent: 5. august 2008 05:58
To: camel-user@activemq.apache.org
Subject: RE: HttpExchange changes to DefaultExchange - expected?
Hi
Yes you can also store the HttpSession object itself as a property or header on the exchange itself. When you need it later you can you get it as a HttpSession object
// store it
exchange.getIn().setHeder("session", the http session object);
// later get it
HttpSession myHttpSession = exchange.getIn().getHeader("session", HttpSession.class);
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Bela Vizy [mailto:magyardude@yahoo.com]
Sent: 5. august 2008 00:25
To: camel-user@activemq.apache.org
Subject: RE: HttpExchange changes to DefaultExchange - expected?
André,
alu wrote:
>
> However, I want to call exchange.getResponse().encodeURL(...) to encode a
> URL that includes the session ID. So it's not just the session ID that
> needs propagating, my endpoint really want access to the session context
> through an HttpExchange instance... Is this possible in those subsequent
> Processors, or should I try a complete different design direction?
>
It sounds you want to respond to a form submission from a browser. Camel is
no a web server. It's a messaging system. I don't think there is a reason to
maintain sessions either with url rewriting or cookies for that matter, but
if you really need it, you have full control over the response headers,
basically whatever you set as an output header will go into the response
(with exceptions you can define).
Bela
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18821081.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HttpExchange changes to DefaultExchange - expected?
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
Yes you can also store the HttpSession object itself as a property or header on the exchange itself. When you need it later you can you get it as a HttpSession object
// store it
exchange.getIn().setHeder("session", the http session object);
// later get it
HttpSession myHttpSession = exchange.getIn().getHeader("session", HttpSession.class);
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Bela Vizy [mailto:magyardude@yahoo.com]
Sent: 5. august 2008 00:25
To: camel-user@activemq.apache.org
Subject: RE: HttpExchange changes to DefaultExchange - expected?
André,
alu wrote:
>
> However, I want to call exchange.getResponse().encodeURL(...) to encode a
> URL that includes the session ID. So it's not just the session ID that
> needs propagating, my endpoint really want access to the session context
> through an HttpExchange instance... Is this possible in those subsequent
> Processors, or should I try a complete different design direction?
>
It sounds you want to respond to a form submission from a browser. Camel is
no a web server. It's a messaging system. I don't think there is a reason to
maintain sessions either with url rewriting or cookies for that matter, but
if you really need it, you have full control over the response headers,
basically whatever you set as an output header will go into the response
(with exceptions you can define).
Bela
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18821081.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HttpExchange changes to DefaultExchange - expected?
Posted by Bela Vizy <ma...@yahoo.com>.
André,
alu wrote:
>
> However, I want to call exchange.getResponse().encodeURL(...) to encode a
> URL that includes the session ID. So it's not just the session ID that
> needs propagating, my endpoint really want access to the session context
> through an HttpExchange instance... Is this possible in those subsequent
> Processors, or should I try a complete different design direction?
>
It sounds you want to respond to a form submission from a browser. Camel is
no a web server. It's a messaging system. I don't think there is a reason to
maintain sessions either with url rewriting or cookies for that matter, but
if you really need it, you have full control over the response headers,
basically whatever you set as an output header will go into the response
(with exceptions you can define).
Bela
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18821081.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HttpExchange changes to DefaultExchange - expected?
Posted by alu <an...@acision.com>.
Hi,
Thanks so far. Using a property or header to propagate data like HTTP
session is a good idea.
However, I want to call exchange.getResponse().encodeURL(...) to encode a
URL that includes the session ID. So it's not just the session ID that needs
propagating, my endpoint really want access to the session context through
an HttpExchange instance... Is this possible in those subsequent Processors,
or should I try a complete different design direction?
Regards,
André
Claus Ibsen wrote:
>
> Hi
>
> I think you can front all your jetty endpoints with a processor that
> copies the HttpSession to a header key on the in message, or as a property
> on the exchange itself.
>
> Then it should be propagated to the other processors later in the route
> chain.
>
> from("jetty:xxx").processRef("frontJettyThatCopiesHttpSessionToHeader")...
> then what you normally do in your route builder
>
>
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18819049.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HttpExchange changes to DefaultExchange - expected?
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
I think you can front all your jetty endpoints with a processor that copies the HttpSession to a header key on the in message, or as a property on the exchange itself.
Then it should be propagated to the other processors later in the route chain.
from("jetty:xxx").processRef("frontJettyThatCopiesHttpSessionToHeader")... then what you normally do in your route builder
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: alu [mailto:andre.van.der.lugt@acision.com]
Sent: 4. august 2008 17:02
To: camel-user@activemq.apache.org
Subject: Re: HttpExchange changes to DefaultExchange - expected?
Hi,
Bela Vizy wrote:
>
> Hi,
>
>
> alu wrote:
>>
>> The problem is, I need access to the HttpServletRequest and
>> HttpServletResponse stuff in subsequent Processors, but only HttpExchange
>> provides this.
>>
>
> Exchange is an abstraction to "exchange" messages. It is related to the
> communication technology. So it doesn't "travel" down the pipe ...
>
> What exactly are you trying to accomplish?
>
> Bela
>
I'm looking for a messaging architecture in which a single Processor, call
it a Responder, creates a response for diverse HTTP requests coming from
multiple Jetty endpoints, with possibly some intermediate message
transformation and routing in between. The Responder knows how to create the
response for the various requests using the business logic, this Responder
needs to be HTTP session aware as well so needs access to an HttpExchange.
André
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18813010.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HttpExchange changes to DefaultExchange - expected?
Posted by alu <an...@acision.com>.
Hi,
Bela Vizy wrote:
>
> Hi,
>
>
> alu wrote:
>>
>> The problem is, I need access to the HttpServletRequest and
>> HttpServletResponse stuff in subsequent Processors, but only HttpExchange
>> provides this.
>>
>
> Exchange is an abstraction to "exchange" messages. It is related to the
> communication technology. So it doesn't "travel" down the pipe ...
>
> What exactly are you trying to accomplish?
>
> Bela
>
I'm looking for a messaging architecture in which a single Processor, call
it a Responder, creates a response for diverse HTTP requests coming from
multiple Jetty endpoints, with possibly some intermediate message
transformation and routing in between. The Responder knows how to create the
response for the various requests using the business logic, this Responder
needs to be HTTP session aware as well so needs access to an HttpExchange.
André
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18813010.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HttpExchange changes to DefaultExchange - expected?
Posted by Bela Vizy <ma...@yahoo.com>.
Hi,
alu wrote:
>
> The problem is, I need access to the HttpServletRequest and
> HttpServletResponse stuff in subsequent Processors, but only HttpExchange
> provides this.
>
Exchange is an abstraction to "exchange" messages. It is related to the
communication technology. So it doesn't "travel" down the pipe ...
What exactly are you trying to accomplish?
Bela
--
View this message in context: http://www.nabble.com/HttpExchange-changes-to-DefaultExchange---expected--tp18809523s22882p18812487.html
Sent from the Camel - Users mailing list archive at Nabble.com.