Hi Claus,

OK, I will create a JIRA task for it and start working. As these are seven 
components to extend (and test), it might take a little time...

Best regards
Stephan

-----Original Message-----
From: Claus Ibsen [mailto:claus.ib...@gmail.com] 
Sent: Montag, 17. Oktober 2016 12:28
To: dev <dev@camel.apache.org>
Subject: Re: [DISCUSS] HTTP session handling in Camel routes

Hi

Yeah that would work. The only downside is that camel-http-common has
a dependency on the servlet API which not all the HTTP components are
using. However its just one extra JAR on the classpath.


On Mon, Oct 17, 2016 at 10:58 AM, Siano, Stephan <stephan.si...@sap.com> wrote:
> Hi Claus,
>
> Having the interface (and implementations) in camel-http-common makes sense 
> to me. This means that all the components below would have a dependency to 
> camel-http-common. Does this make sense?
>
> I would implement the support for cookies in the producer endpoints for
> camel-ahc
> camel-cxf
> camel-jetty
> camel-http4
> camel-netty4-http
> camel-restlet
> camel-undertow
>
> camel-spark-rest does not support producer endpoints
> I don't actually understand how camel-spring-ws handles HTTP protocol 
> headers, so I would like to leave the session handling support in there for 
> someone else (who does understand that component better than me). Anyway the 
> change will be big enough as it is touching so many components (and 
> especially the tests for this are probably different for all these 
> components).
>
> Is this a way to go?
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ib...@gmail.com]
> Sent: Montag, 17. Oktober 2016 10:08
> To: dev <dev@camel.apache.org>
> Subject: Re: [DISCUSS] HTTP session handling in Camel routes
>
> Hi
>
> I dont think cookie belongs in camel-core, and a better place is
> likely something like camel-http-common.
>
> And there are other http client components such as camel-nett4-http,
> camel-jetty, camel-undertow as well. And then for REST based there is
> camel-restlet and maybe camel-spark-rest.
> And for WS there is also camel-spring-ws.
>
> So if anything like cookie is attempted to be something that is a
> cross functionality in http components then you would need to
> implement this in more of them, and not only a limited set.
>
>
>
>
> On Fri, Oct 14, 2016 at 7:24 AM, Siano, Stephan <stephan.si...@sap.com> wrote:
>> Hi,
>>
>> I have not received any feedback so far, so I assume that there is at least 
>> nobody strongly against this feature. Maybe I can sketch what I would like 
>> to implement and ask some questions about implementation details.
>>
>> I would create an interface (CamelCookieHandler and two implementation 
>> classes InstanceCookieHandler and ExchangeCookieHandler. The former keeps 
>> the cookie store with its instance, the latter stores them with the Exchange.
>>
>> Furthermore I would extend some HTTP based producer endpoints with a 
>> parameter allowing to set one of these cookie handlers.
>>
>> Questions:
>> 1. The interface goes to package org.apache.camel. Where do the 
>> implementation classes go? org.apache.camel.impl? Someone building a Camel 
>> route is supposed to instantiate these classes.
>> 2. Where do I document the general concept behind this? It's obviously cross 
>> component, so adding it to the component documentation does not make too 
>> much sense. Is the Javadoc for the interface and the implementation classes 
>> sufficient or should I add a Wiki page somewhere else?
>> 3. I would add support for this to the camel-ahc, camel-cxf, and camel-http4 
>> component. Is the camel-http component still alive? Does it make sense to 
>> add it to other components I overlooked?
>>
>> Best regards
>> Stephan
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Reply via email to