Which version of HttpServletRequest is injected?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Which version of HttpServletRequest is injected?

arjan tijms
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In 3.8 it says:

"A servlet container must provide the following built-in beans, all of which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by multiple artefacts. I.e. by a ServerAuthModule, Filter and a RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of the first ones", e.g. the one that happened to be current when e.g. a ServletRequestListener that initialises a specific CDI implementation is called.

I think this is a little confusing, as working with an injected request can now totally ignore the request wrapping that has been done and break an application badly.

Thoughts?

Kind regards,
Arjan Tijms


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Martin Kouba
Hi Arjan,

that's a good question. In Weld, the request object is captured during
request context activation, i.e. during
ServletRequestListener.requestInitialized() notification and before any
filter or servlet is invoked. So wrappers are ignored and the
original/first request is used.

But TBH I don't think we can fix this easily as I'm not aware of any
portable way to listen for "wrapping actions".

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):

> Hi,
>
> The CDI spec defines a built-in bean for the type HttpServletRequest. In
> 3.8 it says:
>
> "A servlet container must provide the following built-in beans, all of
> which have qualifier @Default:
>
> a bean with bean type javax.servlet.http.HttpServletRequest, allowing
> injection of a reference to the HttpServletRequest"
>
> An HttpServletRequest however can be wrapped multiple times and by
> multiple artefacts. I.e. by a ServerAuthModule, Filter and a
> RequestDispatcher.
>
> The question now is; which version of the HttpServletRequest is supposed
> to be injected?
>
> * The first one in the chain?
> * The last one in the chain?
> * The current one at a given point in the chain?
>
> A little bit of experimenting seems to indicate it's now often "one of
> the first ones", e.g. the one that happened to be current when e.g. a
> ServletRequestListener that initialises a specific CDI implementation is
> called.
>
> I think this is a little confusing, as working with an injected request
> can now totally ignore the request wrapping that has been done and break
> an application badly.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Romain Manni-Bucau
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app). Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Romain Manni-Bucau
AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it.


2016-09-08 13:31 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.




_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
Hi,

I see what you mean.

There's perhaps 2 solutions.

1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack)
2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, which is hopefully at least always the same for a given server), and introduce a qualifier @Current orso.

I don't think you'd ever need @Inject @Web(FilterX.class) Request, which would mean searching back through the stack. If users would want that, they have to make their own producer.

What we could do now is:

AuthModule
|
|
Filter1 (calls) ---> BeanX.foo() #1
|
|
Filter2 
|
|
Servlet1 (calls) ---> BeanX.foo() #2
|
|
(forward) ---> Servlet2 (calls) ---> BeanX.foo() #3



If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, then:


In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1

In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1

In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2



Since the request processing is strictly sequential here, a given thread always has the concept of the request that was passed it to the module/filter/servlet that's highest up the call stack. That one would IMHO be the most logical one that you want to work with.

Kind regards,
Arjan Tijms






































On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <[hidden email]> wrote:
AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it.


2016-09-08 13:31 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.





_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Romain Manni-Bucau
Well supposes @Current means something for the component getting the injection, I can see where you go starting from AuthModule but more your browse the chain less it makes sense IMO -> maybe something to work on auth side more than CDI?

That said CDI has a notion for conversions which is to define a provided filter. Maybe that's the easiest here: a user could define one or multiple filters ("CDI Filter" or whatever name) which would set CDI position in the filter chain, defining it N times would update "current" request and the produces one so we keep current default and enable the user to control it himself finely when needed.


2016-09-08 14:10 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

I see what you mean.

There's perhaps 2 solutions.

1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack)
2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, which is hopefully at least always the same for a given server), and introduce a qualifier @Current orso.

I don't think you'd ever need @Inject @Web(FilterX.class) Request, which would mean searching back through the stack. If users would want that, they have to make their own producer.

What we could do now is:

AuthModule
|
|
Filter1 (calls) ---> BeanX.foo() #1
|
|
Filter2 
|
|
Servlet1 (calls) ---> BeanX.foo() #2
|
|
(forward) ---> Servlet2 (calls) ---> BeanX.foo() #3



If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, then:


In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1

In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1

In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2



Since the request processing is strictly sequential here, a given thread always has the concept of the request that was passed it to the module/filter/servlet that's highest up the call stack. That one would IMHO be the most logical one that you want to work with.

Kind regards,
Arjan Tijms






































On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <[hidden email]> wrote:
AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it.


2016-09-08 13:31 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.






_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Martin Kouba
In reply to this post by arjan tijms
The best solution might be to let the servlet container provide the
beans for all the servlet artifacts (HttpServletRequest, HttpSession and
ServletContext).

But it's more complicated then it sounds. For example,
HttpServletRequest attibutes might be used as backing storage of the
request context. So that it cannot simply change...

Anyway, I think this problem deserves some attention from both the CDI
and the Servlet EG.

Martin

Dne 8.9.2016 v 13:31 arjan tijms napsal(a):

> Hi,
>
> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hit that issue as well several times.
>
>     It is more vicious than it looks like IMO cause CDI will *never* get
>     *the* right request for everybody, it is as simple as that. Any part
>     of the app can rely on the wrapper level N (of course N being
>     different for each mentionned parts of the app).
>
>
> What I was thinking, but maybe I'm wrong, is that the application never
> "just" wraps the request and uses it for itself. It always passes it to
> the container, which then passes it on to the next Filter, Servlet, or
> whatever. So at that point the container code has the opportunity to
> store the request as being the "current" one.
>
> E.g. if you do:
>
> RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
> dispatcher.forward(wrap(request), response);
>
> Then the RequestDispatcher, which is a container class, receives the
> wrapped request and can make it available.
>
> The other way around, eventually every AuthModule, Filter or Servlet has
> to be called by the container at some point. E.g. the "protected void
> service(HttpServletRequest req, HttpServletResponse resp)" is called by
> the container.
>
> So just before the container invokes the HttpServlet#service method, the
> container can store the request, and CDI (via an SPI) can pick it up
> from there.
>
> That way in every context you can always have the *current* request (the
> request that's passed in to the last Servlet or Filter call on the stack).
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     Best CDI can do is to provide the request it has (already the case
>     and cost pretty much nothing) and enable the user to produces very
>     easily its own request from its filter (or equivalent) for its usage
>     IMO - which is IMO already doable but maybe there is another
>     shortcut we can introduce I didnt think about. If you look one step
>     further any web framework built on top of CDI does it and therefore
>     runs in a well known context.
>
>
>     Romain Manni-Bucau
>     @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>     <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>     <http://rmannibucau.wordpress.com> | Github
>     <https://github.com/rmannibucau> | LinkedIn
>     <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>     <http://www.tomitribe.com> | JavaEE Factory
>     <https://javaeefactory-rmannibucau.rhcloud.com>
>
>     2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]
>     <mailto:[hidden email]>>:
>
>         Hi,
>
>         On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]
>         <mailto:[hidden email]>> wrote:
>
>             that's a good question. In Weld, the request object is
>             captured during request context activation, i.e. during
>             ServletRequestListener.requestInitialized() notification and
>             before any filter or servlet is invoked. So wrappers are
>             ignored and the original/first request is used.
>
>
>         Indeed, although do note that some servers (Liberty and WebLogic
>         I think) send the ServletRequestListener.requestInitialized()
>         notification rather late, and do that after the application
>         already has seen the request and has had a chance to wrap it.
>         This by itself is a separate problem. So on these servers, Weld
>         would receive an early request but not necessarily the earliest.
>
>
>             But TBH I don't think we can fix this easily as I'm not
>             aware of any portable way to listen for "wrapping actions".
>
>
>         This would have to happen with Server specific code I guess,
>         just as Weld now requires an SPI to obtain the current principal
>         for injection.
>
>         You could say that the Servlet container could store the request
>         "somewhere" on a stack structure, just before it invokes the
>         ServerAuthModule, Filter, Servlet and anything else I may have
>         forgotten, and then when control flows back to each Servlet,
>         Filter, etc unwind that stack.
>
>         At the very least the spec for now should perhaps clarify this?
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>             Martin
>
>             Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                 Hi,
>
>                 The CDI spec defines a built-in bean for the type
>                 HttpServletRequest. In
>                 3.8 it says:
>
>                 "A servlet container must provide the following built-in
>                 beans, all of
>                 which have qualifier @Default:
>
>                 a bean with bean type
>                 javax.servlet.http.HttpServletRequest, allowing
>                 injection of a reference to the HttpServletRequest"
>
>                 An HttpServletRequest however can be wrapped multiple
>                 times and by
>                 multiple artefacts. I.e. by a ServerAuthModule, Filter and a
>                 RequestDispatcher.
>
>                 The question now is; which version of the
>                 HttpServletRequest is supposed
>                 to be injected?
>
>                 * The first one in the chain?
>                 * The last one in the chain?
>                 * The current one at a given point in the chain?
>
>                 A little bit of experimenting seems to indicate it's now
>                 often "one of
>                 the first ones", e.g. the one that happened to be
>                 current when e.g. a
>                 ServletRequestListener that initialises a specific CDI
>                 implementation is
>                 called.
>
>                 I think this is a little confusing, as working with an
>                 injected request
>                 can now totally ignore the request wrapping that has
>                 been done and break
>                 an application badly.
>
>                 Thoughts?
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>                 _______________________________________________
>                 cdi-dev mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 https://lists.jboss.org/mailman/listinfo/cdi-dev
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
>                 Note that for all code provided on this list, the
>                 provider licenses the code under the Apache License,
>                 Version 2
>                 (http://www.apache.org/licenses/LICENSE-2.0.html
>                 <http://www.apache.org/licenses/LICENSE-2.0.html>). For
>                 all other ideas provided on this list, the provider
>                 waives all patent and other intellectual property rights
>                 inherent in such information.
>
>
>             --
>             Martin Kouba
>             Software Engineer
>             Red Hat, Czech Republic
>
>
>
>         _______________________________________________
>         cdi-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
>         Note that for all code provided on this list, the provider
>         licenses the code under the Apache License, Version 2
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>). For all
>         other ideas provided on this list, the provider waives all
>         patent and other intellectual property rights inherent in such
>         information.
>
>
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
In reply to this post by Romain Manni-Bucau
Hi,

Sorry, forget the AuthModule for now ;) I just put it there because it's often forgotten that it also gets to see the request and can wrap it, but for a change (I know, it's rare with me ;)) the issue here is primarily unrelated to auth.

Kind regards,
Arjan Tijms



On Thu, Sep 8, 2016 at 2:14 PM, Romain Manni-Bucau <[hidden email]> wrote:
Well supposes @Current means something for the component getting the injection, I can see where you go starting from AuthModule but more your browse the chain less it makes sense IMO -> maybe something to work on auth side more than CDI?

That said CDI has a notion for conversions which is to define a provided filter. Maybe that's the easiest here: a user could define one or multiple filters ("CDI Filter" or whatever name) which would set CDI position in the filter chain, defining it N times would update "current" request and the produces one so we keep current default and enable the user to control it himself finely when needed.


2016-09-08 14:10 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

I see what you mean.

There's perhaps 2 solutions.

1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack)
2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, which is hopefully at least always the same for a given server), and introduce a qualifier @Current orso.

I don't think you'd ever need @Inject @Web(FilterX.class) Request, which would mean searching back through the stack. If users would want that, they have to make their own producer.

What we could do now is:

AuthModule
|
|
Filter1 (calls) ---> BeanX.foo() #1
|
|
Filter2 
|
|
Servlet1 (calls) ---> BeanX.foo() #2
|
|
(forward) ---> Servlet2 (calls) ---> BeanX.foo() #3



If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, then:


In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1

In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1

In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2



Since the request processing is strictly sequential here, a given thread always has the concept of the request that was passed it to the module/filter/servlet that's highest up the call stack. That one would IMHO be the most logical one that you want to work with.

Kind regards,
Arjan Tijms






































On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <[hidden email]> wrote:
AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it.


2016-09-08 13:31 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.







_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
In reply to this post by Martin Kouba
Hi,

On Thu, Sep 8, 2016 at 2:14 PM, Martin Kouba <[hidden email]> wrote:
The best solution might be to let the servlet container provide the beans for all the servlet artifacts (HttpServletRequest, HttpSession and ServletContext).

+100 for that.

Several issues were already created for that in the past, but to my understanding it was misunderstood by some in the Servlet EG and subsequently closed. See https://java.net/jira/browse/SERVLET_SPEC-116

Specifically this comment was a little problematic:

GW> More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

I think this is missing the key insight that CDI extensions are portable and that it's "just" providing a 1 class extension that adds 3 orso build-in beans.

Kind regards,
Arjan Tijms



 

But it's more complicated then it sounds. For example, HttpServletRequest attibutes might be used as backing storage of the request context. So that it cannot simply change...

Anyway, I think this problem deserves some attention from both the CDI and the Servlet EG.

Martin

Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
<[hidden email] <mailto:[hidden email]>> wrote:

    Hit that issue as well several times.

    It is more vicious than it looks like IMO cause CDI will *never* get
    *the* right request for everybody, it is as simple as that. Any part
    of the app can rely on the wrapper level N (of course N being
    different for each mentionned parts of the app).


What I was thinking, but maybe I'm wrong, is that the application never
"just" wraps the request and uses it for itself. It always passes it to
the container, which then passes it on to the next Filter, Servlet, or
whatever. So at that point the container code has the opportunity to
store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the
wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has
to be called by the container at some point. E.g. the "protected void
service(HttpServletRequest req, HttpServletResponse resp)" is called by
the container.

So just before the container invokes the HttpServlet#service method, the
container can store the request, and CDI (via an SPI) can pick it up
from there.

That way in every context you can always have the *current* request (the
request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms















    Best CDI can do is to provide the request it has (already the case
    and cost pretty much nothing) and enable the user to produces very
    easily its own request from its filter (or equivalent) for its usage
    IMO - which is IMO already doable but maybe there is another
    shortcut we can introduce I didnt think about. If you look one step
    further any web framework built on top of CDI does it and therefore
    runs in a well known context.


    Romain Manni-Bucau
    @rmannibucau <https://twitter.com/rmannibucau> |  Blog
    <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
    <http://rmannibucau.wordpress.com> | Github
    <https://github.com/rmannibucau> | LinkedIn
    <https://www.linkedin.com/in/rmannibucau> | Tomitriber
    <http://www.tomitribe.com> | JavaEE Factory
    <https://javaeefactory-rmannibucau.rhcloud.com>

    2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]
    <mailto:[hidden email]>>:

        Hi,

        On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]
        <mailto:[hidden email]>> wrote:

            that's a good question. In Weld, the request object is
            captured during request context activation, i.e. during
            ServletRequestListener.requestInitialized() notification and
            before any filter or servlet is invoked. So wrappers are
            ignored and the original/first request is used.


        Indeed, although do note that some servers (Liberty and WebLogic
        I think) send the ServletRequestListener.requestInitialized()
        notification rather late, and do that after the application
        already has seen the request and has had a chance to wrap it.
        This by itself is a separate problem. So on these servers, Weld
        would receive an early request but not necessarily the earliest.


            But TBH I don't think we can fix this easily as I'm not
            aware of any portable way to listen for "wrapping actions".


        This would have to happen with Server specific code I guess,
        just as Weld now requires an SPI to obtain the current principal
        for injection.

        You could say that the Servlet container could store the request
        "somewhere" on a stack structure, just before it invokes the
        ServerAuthModule, Filter, Servlet and anything else I may have
        forgotten, and then when control flows back to each Servlet,
        Filter, etc unwind that stack.

        At the very least the spec for now should perhaps clarify this?

        Kind regards,
        Arjan Tijms





            Martin

            Dne 8.9.2016 v 11:02 arjan tijms napsal(a):

                Hi,

                The CDI spec defines a built-in bean for the type
                HttpServletRequest. In
                3.8 it says:

                "A servlet container must provide the following built-in
                beans, all of
                which have qualifier @Default:

                a bean with bean type
                javax.servlet.http.HttpServletRequest, allowing
                injection of a reference to the HttpServletRequest"

                An HttpServletRequest however can be wrapped multiple
                times and by
                multiple artefacts. I.e. by a ServerAuthModule, Filter and a
                RequestDispatcher.

                The question now is; which version of the
                HttpServletRequest is supposed
                to be injected?

                * The first one in the chain?
                * The last one in the chain?
                * The current one at a given point in the chain?

                A little bit of experimenting seems to indicate it's now
                often "one of
                the first ones", e.g. the one that happened to be
                current when e.g. a
                ServletRequestListener that initialises a specific CDI
                implementation is
                called.

                I think this is a little confusing, as working with an
                injected request
                can now totally ignore the request wrapping that has
                been done and break
                an application badly.

                Thoughts?

                Kind regards,
                Arjan Tijms



                _______________________________________________
                cdi-dev mailing list
                [hidden email] <mailto:[hidden email]>
                https://lists.jboss.org/mailman/listinfo/cdi-dev
                <https://lists.jboss.org/mailman/listinfo/cdi-dev>

                Note that for all code provided on this list, the
                provider licenses the code under the Apache License,
                Version 2
                (http://www.apache.org/licenses/LICENSE-2.0.html
                <http://www.apache.org/licenses/LICENSE-2.0.html>). For
                all other ideas provided on this list, the provider
                waives all patent and other intellectual property rights
                inherent in such information.


            --
            Martin Kouba
            Software Engineer
            Red Hat, Czech Republic



        _______________________________________________
        cdi-dev mailing list
        [hidden email] <mailto:[hidden email]>
        https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>

        Note that for all code provided on this list, the provider
        licenses the code under the Apache License, Version 2
        (http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>). For all
        other ideas provided on this list, the provider waives all
        patent and other intellectual property rights inherent in such
        information.





_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Romain Manni-Bucau
In reply to this post by arjan tijms


2016-09-08 14:21 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

Sorry, forget the AuthModule for now ;) I just put it there because it's often forgotten that it also gets to see the request and can wrap it, but for a change (I know, it's rare with me ;)) the issue here is primarily unrelated to auth.


ok, was not clear: point with AuthModule is it is not required to be in the servlet chain at all (can be before), that's why i pointed out it was maybe another topic and a small missing integration between 2 specs.
 
Kind regards,
Arjan Tijms



On Thu, Sep 8, 2016 at 2:14 PM, Romain Manni-Bucau <[hidden email]> wrote:
Well supposes @Current means something for the component getting the injection, I can see where you go starting from AuthModule but more your browse the chain less it makes sense IMO -> maybe something to work on auth side more than CDI?

That said CDI has a notion for conversions which is to define a provided filter. Maybe that's the easiest here: a user could define one or multiple filters ("CDI Filter" or whatever name) which would set CDI position in the filter chain, defining it N times would update "current" request and the produces one so we keep current default and enable the user to control it himself finely when needed.


2016-09-08 14:10 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

I see what you mean.

There's perhaps 2 solutions.

1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack)
2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, which is hopefully at least always the same for a given server), and introduce a qualifier @Current orso.

I don't think you'd ever need @Inject @Web(FilterX.class) Request, which would mean searching back through the stack. If users would want that, they have to make their own producer.

What we could do now is:

AuthModule
|
|
Filter1 (calls) ---> BeanX.foo() #1
|
|
Filter2 
|
|
Servlet1 (calls) ---> BeanX.foo() #2
|
|
(forward) ---> Servlet2 (calls) ---> BeanX.foo() #3



If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, then:


In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1

In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1

In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2



Since the request processing is strictly sequential here, a given thread always has the concept of the request that was passed it to the module/filter/servlet that's highest up the call stack. That one would IMHO be the most logical one that you want to work with.

Kind regards,
Arjan Tijms






































On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <[hidden email]> wrote:
AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it.


2016-09-08 13:31 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app).

What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one.

E.g. if you do:

RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
dispatcher.forward(wrap(request), response);

Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.

The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container.

So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there.

That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack).

Kind regards,
Arjan Tijms













 
Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context.


2016-09-08 13:03 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <[hidden email]> wrote:
that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.

Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest.
 
But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions".

This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection.

You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack.

At the very least the spec for now should perhaps clarify this?

Kind regards,
Arjan Tijms


 

Martin

Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
Hi,

The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:

"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"

An HttpServletRequest however can be wrapped multiple times and by
multiple artefacts. I.e. by a ServerAuthModule, Filter and a
RequestDispatcher.

The question now is; which version of the HttpServletRequest is supposed
to be injected?

* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?

A little bit of experimenting seems to indicate it's now often "one of
the first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.

I think this is a little confusing, as working with an injected request
can now totally ignore the request wrapping that has been done and break
an application badly.

Thoughts?

Kind regards,
Arjan Tijms



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.








_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Martin Kouba
In reply to this post by arjan tijms
Dne 8.9.2016 v 14:28 arjan tijms napsal(a):

> Hi,
>
> On Thu, Sep 8, 2016 at 2:14 PM, Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     The best solution might be to let the servlet container provide the
>     beans for all the servlet artifacts (HttpServletRequest, HttpSession
>     and ServletContext).
>
>
> +100 for that.
>
> Several issues were already created for that in the past, but to my
> understanding it was misunderstood by some in the Servlet EG and
> subsequently closed. See https://java.net/jira/browse/SERVLET_SPEC-116
>
> Specifically this comment was a little problematic:
>
> GW> More over,
> GW> I'm concerned that by making CDI to servlet mapping a responsibility
> GW> of the servlet container, then we are going to have to do a
> GW> container to CDI adaptation for every CDI implementation out there.
>
> I think this is missing the key insight that CDI extensions are portable
> and that it's "just" providing a 1 class extension that adds 3 orso
> build-in beans.

Stuart has a good point about backward compatibility. Servlet impl would
have to detect CDI version and skip registration if not 2.0+. I think
SERVLET_SPEC-116 should be reopened and the discussion restarted.

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>     But it's more complicated then it sounds. For example,
>     HttpServletRequest attibutes might be used as backing storage of the
>     request context. So that it cannot simply change...
>
>     Anyway, I think this problem deserves some attention from both the
>     CDI and the Servlet EG.
>
>     Martin
>
>     Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
>         Hi,
>
>         On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>
>         wrote:
>
>             Hit that issue as well several times.
>
>             It is more vicious than it looks like IMO cause CDI will
>         *never* get
>             *the* right request for everybody, it is as simple as that.
>         Any part
>             of the app can rely on the wrapper level N (of course N being
>             different for each mentionned parts of the app).
>
>
>         What I was thinking, but maybe I'm wrong, is that the
>         application never
>         "just" wraps the request and uses it for itself. It always
>         passes it to
>         the container, which then passes it on to the next Filter,
>         Servlet, or
>         whatever. So at that point the container code has the opportunity to
>         store the request as being the "current" one.
>
>         E.g. if you do:
>
>         RequestDispatcher dispatcher =
>         servletContext().getRequestDispatcher(...);
>         dispatcher.forward(wrap(request), response);
>
>         Then the RequestDispatcher, which is a container class, receives the
>         wrapped request and can make it available.
>
>         The other way around, eventually every AuthModule, Filter or
>         Servlet has
>         to be called by the container at some point. E.g. the "protected
>         void
>         service(HttpServletRequest req, HttpServletResponse resp)" is
>         called by
>         the container.
>
>         So just before the container invokes the HttpServlet#service
>         method, the
>         container can store the request, and CDI (via an SPI) can pick it up
>         from there.
>
>         That way in every context you can always have the *current*
>         request (the
>         request that's passed in to the last Servlet or Filter call on
>         the stack).
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>             Best CDI can do is to provide the request it has (already
>         the case
>             and cost pretty much nothing) and enable the user to
>         produces very
>             easily its own request from its filter (or equivalent) for
>         its usage
>             IMO - which is IMO already doable but maybe there is another
>             shortcut we can introduce I didnt think about. If you look
>         one step
>             further any web framework built on top of CDI does it and
>         therefore
>             runs in a well known context.
>
>
>             Romain Manni-Bucau
>             @rmannibucau <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>> |  Blog
>             <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>> | Old Wordpress Blog
>             <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>> | Github
>             <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>> | LinkedIn
>             <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>> | Tomitriber
>             <http://www.tomitribe.com> | JavaEE Factory
>             <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>>
>
>             2016-09-08 13:03 GMT+02:00 arjan tijms
>         <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>>:
>
>                 Hi,
>
>                 On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
>         <[hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email] <mailto:[hidden email]>>>
>         wrote:
>
>                     that's a good question. In Weld, the request object is
>                     captured during request context activation, i.e. during
>                     ServletRequestListener.requestInitialized()
>         notification and
>                     before any filter or servlet is invoked. So wrappers are
>                     ignored and the original/first request is used.
>
>
>                 Indeed, although do note that some servers (Liberty and
>         WebLogic
>                 I think) send the
>         ServletRequestListener.requestInitialized()
>                 notification rather late, and do that after the application
>                 already has seen the request and has had a chance to
>         wrap it.
>                 This by itself is a separate problem. So on these
>         servers, Weld
>                 would receive an early request but not necessarily the
>         earliest.
>
>
>                     But TBH I don't think we can fix this easily as I'm not
>                     aware of any portable way to listen for "wrapping
>         actions".
>
>
>                 This would have to happen with Server specific code I guess,
>                 just as Weld now requires an SPI to obtain the current
>         principal
>                 for injection.
>
>                 You could say that the Servlet container could store the
>         request
>                 "somewhere" on a stack structure, just before it invokes the
>                 ServerAuthModule, Filter, Servlet and anything else I
>         may have
>                 forgotten, and then when control flows back to each Servlet,
>                 Filter, etc unwind that stack.
>
>                 At the very least the spec for now should perhaps
>         clarify this?
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>
>
>                     Martin
>
>                     Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                         Hi,
>
>                         The CDI spec defines a built-in bean for the type
>                         HttpServletRequest. In
>                         3.8 it says:
>
>                         "A servlet container must provide the following
>         built-in
>                         beans, all of
>                         which have qualifier @Default:
>
>                         a bean with bean type
>                         javax.servlet.http.HttpServletRequest, allowing
>                         injection of a reference to the HttpServletRequest"
>
>                         An HttpServletRequest however can be wrapped
>         multiple
>                         times and by
>                         multiple artefacts. I.e. by a ServerAuthModule,
>         Filter and a
>                         RequestDispatcher.
>
>                         The question now is; which version of the
>                         HttpServletRequest is supposed
>                         to be injected?
>
>                         * The first one in the chain?
>                         * The last one in the chain?
>                         * The current one at a given point in the chain?
>
>                         A little bit of experimenting seems to indicate
>         it's now
>                         often "one of
>                         the first ones", e.g. the one that happened to be
>                         current when e.g. a
>                         ServletRequestListener that initialises a
>         specific CDI
>                         implementation is
>                         called.
>
>                         I think this is a little confusing, as working
>         with an
>                         injected request
>                         can now totally ignore the request wrapping that has
>                         been done and break
>                         an application badly.
>
>                         Thoughts?
>
>                         Kind regards,
>                         Arjan Tijms
>
>
>
>                         _______________________________________________
>                         cdi-dev mailing list
>                         [hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                         Note that for all code provided on this list, the
>                         provider licenses the code under the Apache License,
>                         Version 2
>                         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>). For
>                         all other ideas provided on this list, the provider
>                         waives all patent and other intellectual
>         property rights
>                         inherent in such information.
>
>
>                     --
>                     Martin Kouba
>                     Software Engineer
>                     Red Hat, Czech Republic
>
>
>
>                 _______________________________________________
>                 cdi-dev mailing list
>                 [hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                 https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                 Note that for all code provided on this list, the provider
>                 licenses the code under the Apache License, Version 2
>                 (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>). For all
>                 other ideas provided on this list, the provider waives all
>                 patent and other intellectual property rights inherent
>         in such
>                 information.
>
>
>
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
Hi,

On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]> wrote:
I think this is missing the key insight that CDI extensions are portable
and that it's "just" providing a 1 class extension that adds 3 orso
build-in beans.

Stuart has a good point about backward compatibility. Servlet impl would have to detect CDI version and skip registration if not 2.0+. I think SERVLET_SPEC-116 should be reopened and the discussion restarted.

Indeed, that is a good point, but that's basically part of the challenge of moving those build-in beans. If I'm not mistaken Antoine once mentioned in one of the other related issues something along the line that CDI 2.0 could provide something for that. So the "is 2.0+" check could be made easier or more straightforward.

Kind regards,
Arjan Tijms




 


Kind regards,
Arjan Tijms






    But it's more complicated then it sounds. For example,
    HttpServletRequest attibutes might be used as backing storage of the
    request context. So that it cannot simply change...

    Anyway, I think this problem deserves some attention from both the
    CDI and the Servlet EG.

    Martin

    Dne 8.9.2016 v 13:31 arjan tijms napsal(a):

        Hi,

        On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
        <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>>

        wrote:

            Hit that issue as well several times.

            It is more vicious than it looks like IMO cause CDI will
        *never* get
            *the* right request for everybody, it is as simple as that.
        Any part
            of the app can rely on the wrapper level N (of course N being
            different for each mentionned parts of the app).


        What I was thinking, but maybe I'm wrong, is that the
        application never
        "just" wraps the request and uses it for itself. It always
        passes it to
        the container, which then passes it on to the next Filter,
        Servlet, or
        whatever. So at that point the container code has the opportunity to
        store the request as being the "current" one.

        E.g. if you do:

        RequestDispatcher dispatcher =
        servletContext().getRequestDispatcher(...);
        dispatcher.forward(wrap(request), response);

        Then the RequestDispatcher, which is a container class, receives the
        wrapped request and can make it available.

        The other way around, eventually every AuthModule, Filter or
        Servlet has
        to be called by the container at some point. E.g. the "protected
        void
        service(HttpServletRequest req, HttpServletResponse resp)" is
        called by
        the container.

        So just before the container invokes the HttpServlet#service
        method, the
        container can store the request, and CDI (via an SPI) can pick it up
        from there.

        That way in every context you can always have the *current*
        request (the
        request that's passed in to the last Servlet or Filter call on
        the stack).

        Kind regards,
        Arjan Tijms















            Best CDI can do is to provide the request it has (already
        the case
            and cost pretty much nothing) and enable the user to
        produces very
            easily its own request from its filter (or equivalent) for
        its usage
            IMO - which is IMO already doable but maybe there is another
            shortcut we can introduce I didnt think about. If you look
        one step
            further any web framework built on top of CDI does it and
        therefore
            runs in a well known context.


            Romain Manni-Bucau
            @rmannibucau <https://twitter.com/rmannibucau
        <https://twitter.com/rmannibucau>> |  Blog
            <https://blog-rmannibucau.rhcloud.com
        <https://blog-rmannibucau.rhcloud.com>> | Old Wordpress Blog
            <http://rmannibucau.wordpress.com
        <http://rmannibucau.wordpress.com>> | Github
            <https://github.com/rmannibucau
        <https://github.com/rmannibucau>> | LinkedIn
            <https://www.linkedin.com/in/rmannibucau
        <https://www.linkedin.com/in/rmannibucau>> | Tomitriber
            <http://www.tomitribe.com> | JavaEE Factory
            <https://javaeefactory-rmannibucau.rhcloud.com
        <https://javaeefactory-rmannibucau.rhcloud.com>>

            2016-09-08 13:03 GMT+02:00 arjan tijms
        <[hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>>:

                Hi,

                On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
        <[hidden email] <mailto:[hidden email]>
                <mailto:[hidden email] <mailto:[hidden email]>>>

        wrote:

                    that's a good question. In Weld, the request object is
                    captured during request context activation, i.e. during
                    ServletRequestListener.requestInitialized()
        notification and
                    before any filter or servlet is invoked. So wrappers are
                    ignored and the original/first request is used.


                Indeed, although do note that some servers (Liberty and
        WebLogic
                I think) send the
        ServletRequestListener.requestInitialized()
                notification rather late, and do that after the application
                already has seen the request and has had a chance to
        wrap it.
                This by itself is a separate problem. So on these
        servers, Weld
                would receive an early request but not necessarily the
        earliest.


                    But TBH I don't think we can fix this easily as I'm not
                    aware of any portable way to listen for "wrapping
        actions".


                This would have to happen with Server specific code I guess,
                just as Weld now requires an SPI to obtain the current
        principal
                for injection.

                You could say that the Servlet container could store the
        request
                "somewhere" on a stack structure, just before it invokes the
                ServerAuthModule, Filter, Servlet and anything else I
        may have
                forgotten, and then when control flows back to each Servlet,
                Filter, etc unwind that stack.

                At the very least the spec for now should perhaps
        clarify this?

                Kind regards,
                Arjan Tijms





                    Martin

                    Dne 8.9.2016 v 11:02 arjan tijms napsal(a):

                        Hi,

                        The CDI spec defines a built-in bean for the type
                        HttpServletRequest. In
                        3.8 it says:

                        "A servlet container must provide the following
        built-in
                        beans, all of
                        which have qualifier @Default:

                        a bean with bean type
                        javax.servlet.http.HttpServletRequest, allowing
                        injection of a reference to the HttpServletRequest"

                        An HttpServletRequest however can be wrapped
        multiple
                        times and by
                        multiple artefacts. I.e. by a ServerAuthModule,
        Filter and a
                        RequestDispatcher.

                        The question now is; which version of the
                        HttpServletRequest is supposed
                        to be injected?

                        * The first one in the chain?
                        * The last one in the chain?
                        * The current one at a given point in the chain?

                        A little bit of experimenting seems to indicate
        it's now
                        often "one of
                        the first ones", e.g. the one that happened to be
                        current when e.g. a
                        ServletRequestListener that initialises a
        specific CDI
                        implementation is
                        called.

                        I think this is a little confusing, as working
        with an
                        injected request
                        can now totally ignore the request wrapping that has
                        been done and break
                        an application badly.

                        Thoughts?

                        Kind regards,
                        Arjan Tijms



                        _______________________________________________
                        cdi-dev mailing list
                        [hidden email]
        <mailto:[hidden email]> <mailto:[hidden email]
        <mailto:[hidden email]>>
                        https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>

        <https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>>

                        Note that for all code provided on this list, the
                        provider licenses the code under the Apache License,
                        Version 2
                        (http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>
                        <http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>>). For
                        all other ideas provided on this list, the provider
                        waives all patent and other intellectual
        property rights
                        inherent in such information.


                    --
                    Martin Kouba
                    Software Engineer
                    Red Hat, Czech Republic



                _______________________________________________
                cdi-dev mailing list
                [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
                https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>
                <https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>>

                Note that for all code provided on this list, the provider
                licenses the code under the Apache License, Version 2
                (http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>
                <http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>>). For all
                other ideas provided on this list, the provider waives all
                patent and other intellectual property rights inherent
        in such
                information.





--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
In reply to this post by Martin Kouba
p.s.

On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]> wrote:
Stuart has a good point about backward compatibility. Servlet impl would have to detect CDI version and skip registration if not 2.0+. I think SERVLET_SPEC-116 should be reopened and the discussion restarted.

Would you like to re-open that discussion on the Servlet list? Would be good to have someone from the CDI EG explaining the case I think.

Kind regards,
Arjan Tijms

 


Kind regards,
Arjan Tijms






    But it's more complicated then it sounds. For example,
    HttpServletRequest attibutes might be used as backing storage of the
    request context. So that it cannot simply change...

    Anyway, I think this problem deserves some attention from both the
    CDI and the Servlet EG.

    Martin

    Dne 8.9.2016 v 13:31 arjan tijms napsal(a):

        Hi,

        On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
        <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>>

        wrote:

            Hit that issue as well several times.

            It is more vicious than it looks like IMO cause CDI will
        *never* get
            *the* right request for everybody, it is as simple as that.
        Any part
            of the app can rely on the wrapper level N (of course N being
            different for each mentionned parts of the app).


        What I was thinking, but maybe I'm wrong, is that the
        application never
        "just" wraps the request and uses it for itself. It always
        passes it to
        the container, which then passes it on to the next Filter,
        Servlet, or
        whatever. So at that point the container code has the opportunity to
        store the request as being the "current" one.

        E.g. if you do:

        RequestDispatcher dispatcher =
        servletContext().getRequestDispatcher(...);
        dispatcher.forward(wrap(request), response);

        Then the RequestDispatcher, which is a container class, receives the
        wrapped request and can make it available.

        The other way around, eventually every AuthModule, Filter or
        Servlet has
        to be called by the container at some point. E.g. the "protected
        void
        service(HttpServletRequest req, HttpServletResponse resp)" is
        called by
        the container.

        So just before the container invokes the HttpServlet#service
        method, the
        container can store the request, and CDI (via an SPI) can pick it up
        from there.

        That way in every context you can always have the *current*
        request (the
        request that's passed in to the last Servlet or Filter call on
        the stack).

        Kind regards,
        Arjan Tijms















            Best CDI can do is to provide the request it has (already
        the case
            and cost pretty much nothing) and enable the user to
        produces very
            easily its own request from its filter (or equivalent) for
        its usage
            IMO - which is IMO already doable but maybe there is another
            shortcut we can introduce I didnt think about. If you look
        one step
            further any web framework built on top of CDI does it and
        therefore
            runs in a well known context.


            Romain Manni-Bucau
            @rmannibucau <https://twitter.com/rmannibucau
        <https://twitter.com/rmannibucau>> |  Blog
            <https://blog-rmannibucau.rhcloud.com
        <https://blog-rmannibucau.rhcloud.com>> | Old Wordpress Blog
            <http://rmannibucau.wordpress.com
        <http://rmannibucau.wordpress.com>> | Github
            <https://github.com/rmannibucau
        <https://github.com/rmannibucau>> | LinkedIn
            <https://www.linkedin.com/in/rmannibucau
        <https://www.linkedin.com/in/rmannibucau>> | Tomitriber
            <http://www.tomitribe.com> | JavaEE Factory
            <https://javaeefactory-rmannibucau.rhcloud.com
        <https://javaeefactory-rmannibucau.rhcloud.com>>

            2016-09-08 13:03 GMT+02:00 arjan tijms
        <[hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>>:

                Hi,

                On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
        <[hidden email] <mailto:[hidden email]>
                <mailto:[hidden email] <mailto:[hidden email]>>>

        wrote:

                    that's a good question. In Weld, the request object is
                    captured during request context activation, i.e. during
                    ServletRequestListener.requestInitialized()
        notification and
                    before any filter or servlet is invoked. So wrappers are
                    ignored and the original/first request is used.


                Indeed, although do note that some servers (Liberty and
        WebLogic
                I think) send the
        ServletRequestListener.requestInitialized()
                notification rather late, and do that after the application
                already has seen the request and has had a chance to
        wrap it.
                This by itself is a separate problem. So on these
        servers, Weld
                would receive an early request but not necessarily the
        earliest.


                    But TBH I don't think we can fix this easily as I'm not
                    aware of any portable way to listen for "wrapping
        actions".


                This would have to happen with Server specific code I guess,
                just as Weld now requires an SPI to obtain the current
        principal
                for injection.

                You could say that the Servlet container could store the
        request
                "somewhere" on a stack structure, just before it invokes the
                ServerAuthModule, Filter, Servlet and anything else I
        may have
                forgotten, and then when control flows back to each Servlet,
                Filter, etc unwind that stack.

                At the very least the spec for now should perhaps
        clarify this?

                Kind regards,
                Arjan Tijms





                    Martin

                    Dne 8.9.2016 v 11:02 arjan tijms napsal(a):

                        Hi,

                        The CDI spec defines a built-in bean for the type
                        HttpServletRequest. In
                        3.8 it says:

                        "A servlet container must provide the following
        built-in
                        beans, all of
                        which have qualifier @Default:

                        a bean with bean type
                        javax.servlet.http.HttpServletRequest, allowing
                        injection of a reference to the HttpServletRequest"

                        An HttpServletRequest however can be wrapped
        multiple
                        times and by
                        multiple artefacts. I.e. by a ServerAuthModule,
        Filter and a
                        RequestDispatcher.

                        The question now is; which version of the
                        HttpServletRequest is supposed
                        to be injected?

                        * The first one in the chain?
                        * The last one in the chain?
                        * The current one at a given point in the chain?

                        A little bit of experimenting seems to indicate
        it's now
                        often "one of
                        the first ones", e.g. the one that happened to be
                        current when e.g. a
                        ServletRequestListener that initialises a
        specific CDI
                        implementation is
                        called.

                        I think this is a little confusing, as working
        with an
                        injected request
                        can now totally ignore the request wrapping that has
                        been done and break
                        an application badly.

                        Thoughts?

                        Kind regards,
                        Arjan Tijms



                        _______________________________________________
                        cdi-dev mailing list
                        [hidden email]
        <mailto:[hidden email]> <mailto:[hidden email]
        <mailto:[hidden email]>>
                        https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>

        <https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>>

                        Note that for all code provided on this list, the
                        provider licenses the code under the Apache License,
                        Version 2
                        (http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>
                        <http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>>). For
                        all other ideas provided on this list, the provider
                        waives all patent and other intellectual
        property rights
                        inherent in such information.


                    --
                    Martin Kouba
                    Software Engineer
                    Red Hat, Czech Republic



                _______________________________________________
                cdi-dev mailing list
                [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
                https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>
                <https://lists.jboss.org/mailman/listinfo/cdi-dev
        <https://lists.jboss.org/mailman/listinfo/cdi-dev>>

                Note that for all code provided on this list, the provider
                licenses the code under the Apache License, Version 2
                (http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>
                <http://www.apache.org/licenses/LICENSE-2.0.html
        <http://www.apache.org/licenses/LICENSE-2.0.html>>). For all
                other ideas provided on this list, the provider waives all
                patent and other intellectual property rights inherent
        in such
                information.





--
Martin Kouba
Software Engineer
Red Hat, Czech Republic


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Martin Kouba
Dne 13.9.2016 v 09:46 arjan tijms napsal(a):

> p.s.
>
> On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Stuart has a good point about backward compatibility. Servlet impl
>     would have to detect CDI version and skip registration if not 2.0+.
>     I think SERVLET_SPEC-116 should be reopened and the discussion
>     restarted.
>
>
> Would you like to re-open that discussion on the Servlet list? Would be
> good to have someone from the CDI EG explaining the case I think.

Yes, that would be good. Antoine, you could meet some Servlet EG members
on J1 and discuss the topic over a beer ;-)

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>             But it's more complicated then it sounds. For example,
>             HttpServletRequest attibutes might be used as backing
>         storage of the
>             request context. So that it cannot simply change...
>
>             Anyway, I think this problem deserves some attention from
>         both the
>             CDI and the Servlet EG.
>
>             Martin
>
>             Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
>                 Hi,
>
>                 On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                     Hit that issue as well several times.
>
>                     It is more vicious than it looks like IMO cause CDI will
>                 *never* get
>                     *the* right request for everybody, it is as simple
>         as that.
>                 Any part
>                     of the app can rely on the wrapper level N (of
>         course N being
>                     different for each mentionned parts of the app).
>
>
>                 What I was thinking, but maybe I'm wrong, is that the
>                 application never
>                 "just" wraps the request and uses it for itself. It always
>                 passes it to
>                 the container, which then passes it on to the next Filter,
>                 Servlet, or
>                 whatever. So at that point the container code has the
>         opportunity to
>                 store the request as being the "current" one.
>
>                 E.g. if you do:
>
>                 RequestDispatcher dispatcher =
>                 servletContext().getRequestDispatcher(...);
>                 dispatcher.forward(wrap(request), response);
>
>                 Then the RequestDispatcher, which is a container class,
>         receives the
>                 wrapped request and can make it available.
>
>                 The other way around, eventually every AuthModule, Filter or
>                 Servlet has
>                 to be called by the container at some point. E.g. the
>         "protected
>                 void
>                 service(HttpServletRequest req, HttpServletResponse
>         resp)" is
>                 called by
>                 the container.
>
>                 So just before the container invokes the HttpServlet#service
>                 method, the
>                 container can store the request, and CDI (via an SPI)
>         can pick it up
>                 from there.
>
>                 That way in every context you can always have the *current*
>                 request (the
>                 request that's passed in to the last Servlet or Filter
>         call on
>                 the stack).
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                     Best CDI can do is to provide the request it has
>         (already
>                 the case
>                     and cost pretty much nothing) and enable the user to
>                 produces very
>                     easily its own request from its filter (or
>         equivalent) for
>                 its usage
>                     IMO - which is IMO already doable but maybe there is
>         another
>                     shortcut we can introduce I didnt think about. If
>         you look
>                 one step
>                     further any web framework built on top of CDI does
>         it and
>                 therefore
>                     runs in a well known context.
>
>
>                     Romain Manni-Bucau
>                     @rmannibucau <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>
>                 <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>>> |  Blog
>                     <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>
>                 <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>>> | Old Wordpress Blog
>                     <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>
>                 <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>>> | Github
>                     <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>
>                 <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>>> | LinkedIn
>                     <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>
>                 <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>>> | Tomitriber
>                     <http://www.tomitribe.com> | JavaEE Factory
>                     <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>
>                 <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>>>
>
>                     2016-09-08 13:03 GMT+02:00 arjan tijms
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                     <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>:
>
>                         Hi,
>
>                         On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                         <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                             that's a good question. In Weld, the request
>         object is
>                             captured during request context activation,
>         i.e. during
>                             ServletRequestListener.requestInitialized()
>                 notification and
>                             before any filter or servlet is invoked. So
>         wrappers are
>                             ignored and the original/first request is used.
>
>
>                         Indeed, although do note that some servers
>         (Liberty and
>                 WebLogic
>                         I think) send the
>                 ServletRequestListener.requestInitialized()
>                         notification rather late, and do that after the
>         application
>                         already has seen the request and has had a chance to
>                 wrap it.
>                         This by itself is a separate problem. So on these
>                 servers, Weld
>                         would receive an early request but not
>         necessarily the
>                 earliest.
>
>
>                             But TBH I don't think we can fix this easily
>         as I'm not
>                             aware of any portable way to listen for
>         "wrapping
>                 actions".
>
>
>                         This would have to happen with Server specific
>         code I guess,
>                         just as Weld now requires an SPI to obtain the
>         current
>                 principal
>                         for injection.
>
>                         You could say that the Servlet container could
>         store the
>                 request
>                         "somewhere" on a stack structure, just before it
>         invokes the
>                         ServerAuthModule, Filter, Servlet and anything
>         else I
>                 may have
>                         forgotten, and then when control flows back to
>         each Servlet,
>                         Filter, etc unwind that stack.
>
>                         At the very least the spec for now should perhaps
>                 clarify this?
>
>                         Kind regards,
>                         Arjan Tijms
>
>
>
>
>
>                             Martin
>
>                             Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                                 Hi,
>
>                                 The CDI spec defines a built-in bean for
>         the type
>                                 HttpServletRequest. In
>                                 3.8 it says:
>
>                                 "A servlet container must provide the
>         following
>                 built-in
>                                 beans, all of
>                                 which have qualifier @Default:
>
>                                 a bean with bean type
>                                 javax.servlet.http.HttpServletRequest,
>         allowing
>                                 injection of a reference to the
>         HttpServletRequest"
>
>                                 An HttpServletRequest however can be wrapped
>                 multiple
>                                 times and by
>                                 multiple artefacts. I.e. by a
>         ServerAuthModule,
>                 Filter and a
>                                 RequestDispatcher.
>
>                                 The question now is; which version of the
>                                 HttpServletRequest is supposed
>                                 to be injected?
>
>                                 * The first one in the chain?
>                                 * The last one in the chain?
>                                 * The current one at a given point in
>         the chain?
>
>                                 A little bit of experimenting seems to
>         indicate
>                 it's now
>                                 often "one of
>                                 the first ones", e.g. the one that
>         happened to be
>                                 current when e.g. a
>                                 ServletRequestListener that initialises a
>                 specific CDI
>                                 implementation is
>                                 called.
>
>                                 I think this is a little confusing, as
>         working
>                 with an
>                                 injected request
>                                 can now totally ignore the request
>         wrapping that has
>                                 been done and break
>                                 an application badly.
>
>                                 Thoughts?
>
>                                 Kind regards,
>                                 Arjan Tijms
>
>
>
>
>         _______________________________________________
>                                 cdi-dev mailing list
>                                 [hidden email]
>         <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         <mailto:[hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                                 Note that for all code provided on this
>         list, the
>                                 provider licenses the code under the
>         Apache License,
>                                 Version 2
>
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>
>         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For
>                                 all other ideas provided on this list,
>         the provider
>                                 waives all patent and other intellectual
>                 property rights
>                                 inherent in such information.
>
>
>                             --
>                             Martin Kouba
>                             Software Engineer
>                             Red Hat, Czech Republic
>
>
>
>                         _______________________________________________
>                         cdi-dev mailing list
>                         [hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                         Note that for all code provided on this list,
>         the provider
>                         licenses the code under the Apache License,
>         Version 2
>                         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>                         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For all
>                         other ideas provided on this list, the provider
>         waives all
>                         patent and other intellectual property rights
>         inherent
>                 in such
>                         information.
>
>
>
>
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Antoine Sabot-Durand
Administrator
Hi guys,

I'd be more than happy to convince our friends of the Servlet spec to re-open this ticket. I'll talk with Ed next week.
All the input you can give me to answer their objection are welcome.

Antoine

Le mar. 13 sept. 2016 à 15:40, Martin Kouba <[hidden email]> a écrit :
Dne 13.9.2016 v 09:46 arjan tijms napsal(a):
> p.s.
>
> On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Stuart has a good point about backward compatibility. Servlet impl
>     would have to detect CDI version and skip registration if not 2.0+.
>     I think SERVLET_SPEC-116 should be reopened and the discussion
>     restarted.
>
>
> Would you like to re-open that discussion on the Servlet list? Would be
> good to have someone from the CDI EG explaining the case I think.

Yes, that would be good. Antoine, you could meet some Servlet EG members
on J1 and discuss the topic over a beer ;-)

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>             But it's more complicated then it sounds. For example,
>             HttpServletRequest attibutes might be used as backing
>         storage of the
>             request context. So that it cannot simply change...
>
>             Anyway, I think this problem deserves some attention from
>         both the
>             CDI and the Servlet EG.
>
>             Martin
>
>             Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
>                 Hi,
>
>                 On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                     Hit that issue as well several times.
>
>                     It is more vicious than it looks like IMO cause CDI will
>                 *never* get
>                     *the* right request for everybody, it is as simple
>         as that.
>                 Any part
>                     of the app can rely on the wrapper level N (of
>         course N being
>                     different for each mentionned parts of the app).
>
>
>                 What I was thinking, but maybe I'm wrong, is that the
>                 application never
>                 "just" wraps the request and uses it for itself. It always
>                 passes it to
>                 the container, which then passes it on to the next Filter,
>                 Servlet, or
>                 whatever. So at that point the container code has the
>         opportunity to
>                 store the request as being the "current" one.
>
>                 E.g. if you do:
>
>                 RequestDispatcher dispatcher =
>                 servletContext().getRequestDispatcher(...);
>                 dispatcher.forward(wrap(request), response);
>
>                 Then the RequestDispatcher, which is a container class,
>         receives the
>                 wrapped request and can make it available.
>
>                 The other way around, eventually every AuthModule, Filter or
>                 Servlet has
>                 to be called by the container at some point. E.g. the
>         "protected
>                 void
>                 service(HttpServletRequest req, HttpServletResponse
>         resp)" is
>                 called by
>                 the container.
>
>                 So just before the container invokes the HttpServlet#service
>                 method, the
>                 container can store the request, and CDI (via an SPI)
>         can pick it up
>                 from there.
>
>                 That way in every context you can always have the *current*
>                 request (the
>                 request that's passed in to the last Servlet or Filter
>         call on
>                 the stack).
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                     Best CDI can do is to provide the request it has
>         (already
>                 the case
>                     and cost pretty much nothing) and enable the user to
>                 produces very
>                     easily its own request from its filter (or
>         equivalent) for
>                 its usage
>                     IMO - which is IMO already doable but maybe there is
>         another
>                     shortcut we can introduce I didnt think about. If
>         you look
>                 one step
>                     further any web framework built on top of CDI does
>         it and
>                 therefore
>                     runs in a well known context.
>
>
>                     Romain Manni-Bucau
>                     @rmannibucau <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>
>                 <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>>> |  Blog
>                     <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>
>                 <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>>> | Old Wordpress Blog
>                     <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>
>                 <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>>> | Github
>                     <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>
>                 <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>>> | LinkedIn
>                     <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>
>                 <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>>> | Tomitriber
>                     <http://www.tomitribe.com> | JavaEE Factory
>                     <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>
>                 <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>>>
>
>                     2016-09-08 13:03 GMT+02:00 arjan tijms
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                     <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>:
>
>                         Hi,
>
>                         On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                         <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                             that's a good question. In Weld, the request
>         object is
>                             captured during request context activation,
>         i.e. during
>                             ServletRequestListener.requestInitialized()
>                 notification and
>                             before any filter or servlet is invoked. So
>         wrappers are
>                             ignored and the original/first request is used.
>
>
>                         Indeed, although do note that some servers
>         (Liberty and
>                 WebLogic
>                         I think) send the
>                 ServletRequestListener.requestInitialized()
>                         notification rather late, and do that after the
>         application
>                         already has seen the request and has had a chance to
>                 wrap it.
>                         This by itself is a separate problem. So on these
>                 servers, Weld
>                         would receive an early request but not
>         necessarily the
>                 earliest.
>
>
>                             But TBH I don't think we can fix this easily
>         as I'm not
>                             aware of any portable way to listen for
>         "wrapping
>                 actions".
>
>
>                         This would have to happen with Server specific
>         code I guess,
>                         just as Weld now requires an SPI to obtain the
>         current
>                 principal
>                         for injection.
>
>                         You could say that the Servlet container could
>         store the
>                 request
>                         "somewhere" on a stack structure, just before it
>         invokes the
>                         ServerAuthModule, Filter, Servlet and anything
>         else I
>                 may have
>                         forgotten, and then when control flows back to
>         each Servlet,
>                         Filter, etc unwind that stack.
>
>                         At the very least the spec for now should perhaps
>                 clarify this?
>
>                         Kind regards,
>                         Arjan Tijms
>
>
>
>
>
>                             Martin
>
>                             Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                                 Hi,
>
>                                 The CDI spec defines a built-in bean for
>         the type
>                                 HttpServletRequest. In
>                                 3.8 it says:
>
>                                 "A servlet container must provide the
>         following
>                 built-in
>                                 beans, all of
>                                 which have qualifier @Default:
>
>                                 a bean with bean type
>                                 javax.servlet.http.HttpServletRequest,
>         allowing
>                                 injection of a reference to the
>         HttpServletRequest"
>
>                                 An HttpServletRequest however can be wrapped
>                 multiple
>                                 times and by
>                                 multiple artefacts. I.e. by a
>         ServerAuthModule,
>                 Filter and a
>                                 RequestDispatcher.
>
>                                 The question now is; which version of the
>                                 HttpServletRequest is supposed
>                                 to be injected?
>
>                                 * The first one in the chain?
>                                 * The last one in the chain?
>                                 * The current one at a given point in
>         the chain?
>
>                                 A little bit of experimenting seems to
>         indicate
>                 it's now
>                                 often "one of
>                                 the first ones", e.g. the one that
>         happened to be
>                                 current when e.g. a
>                                 ServletRequestListener that initialises a
>                 specific CDI
>                                 implementation is
>                                 called.
>
>                                 I think this is a little confusing, as
>         working
>                 with an
>                                 injected request
>                                 can now totally ignore the request
>         wrapping that has
>                                 been done and break
>                                 an application badly.
>
>                                 Thoughts?
>
>                                 Kind regards,
>                                 Arjan Tijms
>
>
>
>
>         _______________________________________________
>                                 cdi-dev mailing list
>                                 [hidden email]
>         <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         <mailto:[hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                                 Note that for all code provided on this
>         list, the
>                                 provider licenses the code under the
>         Apache License,
>                                 Version 2
>
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>
>         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For
>                                 all other ideas provided on this list,
>         the provider
>                                 waives all patent and other intellectual
>                 property rights
>                                 inherent in such information.
>
>
>                             --
>                             Martin Kouba
>                             Software Engineer
>                             Red Hat, Czech Republic
>
>
>
>                         _______________________________________________
>                         cdi-dev mailing list
>                         [hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                         Note that for all code provided on this list,
>         the provider
>                         licenses the code under the Apache License,
>         Version 2
>                         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>                         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For all
>                         other ideas provided on this list, the provider
>         waives all
>                         patent and other intellectual property rights
>         inherent
>                 in such
>                         information.
>
>
>
>
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

arjan tijms
Hi,

On Tue, Sep 13, 2016 at 4:37 PM, Antoine Sabot-Durand <[hidden email]> wrote:
I'd be more than happy to convince our friends of the Servlet spec to re-open this ticket. I'll talk with Ed next week.
All the input you can give me to answer their objection are welcome.

The most problematic objection IMHO was this one:

GW> More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

Ed called among others this one an "excellent point".

But it's simply not true. In no version of what's being asked is there any "container to CDI adaptation for every CDI implementation out there". Extensions are portable in CDI, as you of course know.

"CDI to servlet mapping" also makes me wonder if it's fully understood what was being asked, which is essentially a portable extension that registers a Bean<T>.

Perhaps helping in taking any further objections away is the fact that one of the oldest, lowest level and arguably most conservative specs out there (JTA), did something quite similar. Implementations provide a small extension that registers an interceptor and a scope. The existence of this extension does not hurt nor influence JTA is situations where CDI is not used.

Backwards compatibility (in non EE environments) should be taken into account as Stuart mentioned. I.e. if an application that bundles CDI 1.x is run on a Servlet 4 container. For Java EE environments it's not an issue.

Kind regards,
Arjan Tijms








 

Antoine

Le mar. 13 sept. 2016 à 15:40, Martin Kouba <[hidden email]> a écrit :
Dne 13.9.2016 v 09:46 arjan tijms napsal(a):
> p.s.
>
> On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Stuart has a good point about backward compatibility. Servlet impl
>     would have to detect CDI version and skip registration if not 2.0+.
>     I think SERVLET_SPEC-116 should be reopened and the discussion
>     restarted.
>
>
> Would you like to re-open that discussion on the Servlet list? Would be
> good to have someone from the CDI EG explaining the case I think.

Yes, that would be good. Antoine, you could meet some Servlet EG members
on J1 and discuss the topic over a beer ;-)

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>             But it's more complicated then it sounds. For example,
>             HttpServletRequest attibutes might be used as backing
>         storage of the
>             request context. So that it cannot simply change...
>
>             Anyway, I think this problem deserves some attention from
>         both the
>             CDI and the Servlet EG.
>
>             Martin
>
>             Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
>                 Hi,
>
>                 On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                     Hit that issue as well several times.
>
>                     It is more vicious than it looks like IMO cause CDI will
>                 *never* get
>                     *the* right request for everybody, it is as simple
>         as that.
>                 Any part
>                     of the app can rely on the wrapper level N (of
>         course N being
>                     different for each mentionned parts of the app).
>
>
>                 What I was thinking, but maybe I'm wrong, is that the
>                 application never
>                 "just" wraps the request and uses it for itself. It always
>                 passes it to
>                 the container, which then passes it on to the next Filter,
>                 Servlet, or
>                 whatever. So at that point the container code has the
>         opportunity to
>                 store the request as being the "current" one.
>
>                 E.g. if you do:
>
>                 RequestDispatcher dispatcher =
>                 servletContext().getRequestDispatcher(...);
>                 dispatcher.forward(wrap(request), response);
>
>                 Then the RequestDispatcher, which is a container class,
>         receives the
>                 wrapped request and can make it available.
>
>                 The other way around, eventually every AuthModule, Filter or
>                 Servlet has
>                 to be called by the container at some point. E.g. the
>         "protected
>                 void
>                 service(HttpServletRequest req, HttpServletResponse
>         resp)" is
>                 called by
>                 the container.
>
>                 So just before the container invokes the HttpServlet#service
>                 method, the
>                 container can store the request, and CDI (via an SPI)
>         can pick it up
>                 from there.
>
>                 That way in every context you can always have the *current*
>                 request (the
>                 request that's passed in to the last Servlet or Filter
>         call on
>                 the stack).
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                     Best CDI can do is to provide the request it has
>         (already
>                 the case
>                     and cost pretty much nothing) and enable the user to
>                 produces very
>                     easily its own request from its filter (or
>         equivalent) for
>                 its usage
>                     IMO - which is IMO already doable but maybe there is
>         another
>                     shortcut we can introduce I didnt think about. If
>         you look
>                 one step
>                     further any web framework built on top of CDI does
>         it and
>                 therefore
>                     runs in a well known context.
>
>
>                     Romain Manni-Bucau
>                     @rmannibucau <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>
>                 <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>>> |  Blog
>                     <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>
>                 <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>>> | Old Wordpress Blog
>                     <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>
>                 <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>>> | Github
>                     <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>
>                 <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>>> | LinkedIn
>                     <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>
>                 <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>>> | Tomitriber
>                     <http://www.tomitribe.com> | JavaEE Factory
>                     <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>
>                 <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>>>
>
>                     2016-09-08 13:03 GMT+02:00 arjan tijms
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                     <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>:
>
>                         Hi,
>
>                         On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                         <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                             that's a good question. In Weld, the request
>         object is
>                             captured during request context activation,
>         i.e. during
>                             ServletRequestListener.requestInitialized()
>                 notification and
>                             before any filter or servlet is invoked. So
>         wrappers are
>                             ignored and the original/first request is used.
>
>
>                         Indeed, although do note that some servers
>         (Liberty and
>                 WebLogic
>                         I think) send the
>                 ServletRequestListener.requestInitialized()
>                         notification rather late, and do that after the
>         application
>                         already has seen the request and has had a chance to
>                 wrap it.
>                         This by itself is a separate problem. So on these
>                 servers, Weld
>                         would receive an early request but not
>         necessarily the
>                 earliest.
>
>
>                             But TBH I don't think we can fix this easily
>         as I'm not
>                             aware of any portable way to listen for
>         "wrapping
>                 actions".
>
>
>                         This would have to happen with Server specific
>         code I guess,
>                         just as Weld now requires an SPI to obtain the
>         current
>                 principal
>                         for injection.
>
>                         You could say that the Servlet container could
>         store the
>                 request
>                         "somewhere" on a stack structure, just before it
>         invokes the
>                         ServerAuthModule, Filter, Servlet and anything
>         else I
>                 may have
>                         forgotten, and then when control flows back to
>         each Servlet,
>                         Filter, etc unwind that stack.
>
>                         At the very least the spec for now should perhaps
>                 clarify this?
>
>                         Kind regards,
>                         Arjan Tijms
>
>
>
>
>
>                             Martin
>
>                             Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                                 Hi,
>
>                                 The CDI spec defines a built-in bean for
>         the type
>                                 HttpServletRequest. In
>                                 3.8 it says:
>
>                                 "A servlet container must provide the
>         following
>                 built-in
>                                 beans, all of
>                                 which have qualifier @Default:
>
>                                 a bean with bean type
>                                 javax.servlet.http.HttpServletRequest,
>         allowing
>                                 injection of a reference to the
>         HttpServletRequest"
>
>                                 An HttpServletRequest however can be wrapped
>                 multiple
>                                 times and by
>                                 multiple artefacts. I.e. by a
>         ServerAuthModule,
>                 Filter and a
>                                 RequestDispatcher.
>
>                                 The question now is; which version of the
>                                 HttpServletRequest is supposed
>                                 to be injected?
>
>                                 * The first one in the chain?
>                                 * The last one in the chain?
>                                 * The current one at a given point in
>         the chain?
>
>                                 A little bit of experimenting seems to
>         indicate
>                 it's now
>                                 often "one of
>                                 the first ones", e.g. the one that
>         happened to be
>                                 current when e.g. a
>                                 ServletRequestListener that initialises a
>                 specific CDI
>                                 implementation is
>                                 called.
>
>                                 I think this is a little confusing, as
>         working
>                 with an
>                                 injected request
>                                 can now totally ignore the request
>         wrapping that has
>                                 been done and break
>                                 an application badly.
>
>                                 Thoughts?
>
>                                 Kind regards,
>                                 Arjan Tijms
>
>
>
>
>         _______________________________________________
>                                 cdi-dev mailing list
>                                 [hidden email]
>         <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         <mailto:[hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                                 Note that for all code provided on this
>         list, the
>                                 provider licenses the code under the
>         Apache License,
>                                 Version 2
>
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>
>         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For
>                                 all other ideas provided on this list,
>         the provider
>                                 waives all patent and other intellectual
>                 property rights
>                                 inherent in such information.
>
>
>                             --
>                             Martin Kouba
>                             Software Engineer
>                             Red Hat, Czech Republic
>
>
>
>                         _______________________________________________
>                         cdi-dev mailing list
>                         [hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                         Note that for all code provided on this list,
>         the provider
>                         licenses the code under the Apache License,
>         Version 2
>                         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>                         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For all
>                         other ideas provided on this list, the provider
>         waives all
>                         patent and other intellectual property rights
>         inherent
>                 in such
>                         information.
>
>
>
>
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Which version of HttpServletRequest is injected?

Romain Manni-Bucau
think that if CDI (as a spec) can extract a "servlet tck" and weld and/or OWB a quick impl of that, it would help servlet containers to see what it would look like. Does that sound feasable? Then we could point out jaxrs, bean validation, jpa, etc as doing it.


2016-09-13 16:56 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Tue, Sep 13, 2016 at 4:37 PM, Antoine Sabot-Durand <[hidden email]> wrote:
I'd be more than happy to convince our friends of the Servlet spec to re-open this ticket. I'll talk with Ed next week.
All the input you can give me to answer their objection are welcome.

The most problematic objection IMHO was this one:

GW> More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

Ed called among others this one an "excellent point".

But it's simply not true. In no version of what's being asked is there any "container to CDI adaptation for every CDI implementation out there". Extensions are portable in CDI, as you of course know.

"CDI to servlet mapping" also makes me wonder if it's fully understood what was being asked, which is essentially a portable extension that registers a Bean<T>.

Perhaps helping in taking any further objections away is the fact that one of the oldest, lowest level and arguably most conservative specs out there (JTA), did something quite similar. Implementations provide a small extension that registers an interceptor and a scope. The existence of this extension does not hurt nor influence JTA is situations where CDI is not used.

Backwards compatibility (in non EE environments) should be taken into account as Stuart mentioned. I.e. if an application that bundles CDI 1.x is run on a Servlet 4 container. For Java EE environments it's not an issue.

Kind regards,
Arjan Tijms








 

Antoine

Le mar. 13 sept. 2016 à 15:40, Martin Kouba <[hidden email]> a écrit :
Dne 13.9.2016 v 09:46 arjan tijms napsal(a):
> p.s.
>
> On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Stuart has a good point about backward compatibility. Servlet impl
>     would have to detect CDI version and skip registration if not 2.0+.
>     I think SERVLET_SPEC-116 should be reopened and the discussion
>     restarted.
>
>
> Would you like to re-open that discussion on the Servlet list? Would be
> good to have someone from the CDI EG explaining the case I think.

Yes, that would be good. Antoine, you could meet some Servlet EG members
on J1 and discuss the topic over a beer ;-)

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>             But it's more complicated then it sounds. For example,
>             HttpServletRequest attibutes might be used as backing
>         storage of the
>             request context. So that it cannot simply change...
>
>             Anyway, I think this problem deserves some attention from
>         both the
>             CDI and the Servlet EG.
>
>             Martin
>
>             Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
>                 Hi,
>
>                 On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                     Hit that issue as well several times.
>
>                     It is more vicious than it looks like IMO cause CDI will
>                 *never* get
>                     *the* right request for everybody, it is as simple
>         as that.
>                 Any part
>                     of the app can rely on the wrapper level N (of
>         course N being
>                     different for each mentionned parts of the app).
>
>
>                 What I was thinking, but maybe I'm wrong, is that the
>                 application never
>                 "just" wraps the request and uses it for itself. It always
>                 passes it to
>                 the container, which then passes it on to the next Filter,
>                 Servlet, or
>                 whatever. So at that point the container code has the
>         opportunity to
>                 store the request as being the "current" one.
>
>                 E.g. if you do:
>
>                 RequestDispatcher dispatcher =
>                 servletContext().getRequestDispatcher(...);
>                 dispatcher.forward(wrap(request), response);
>
>                 Then the RequestDispatcher, which is a container class,
>         receives the
>                 wrapped request and can make it available.
>
>                 The other way around, eventually every AuthModule, Filter or
>                 Servlet has
>                 to be called by the container at some point. E.g. the
>         "protected
>                 void
>                 service(HttpServletRequest req, HttpServletResponse
>         resp)" is
>                 called by
>                 the container.
>
>                 So just before the container invokes the HttpServlet#service
>                 method, the
>                 container can store the request, and CDI (via an SPI)
>         can pick it up
>                 from there.
>
>                 That way in every context you can always have the *current*
>                 request (the
>                 request that's passed in to the last Servlet or Filter
>         call on
>                 the stack).
>
>                 Kind regards,
>                 Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                     Best CDI can do is to provide the request it has
>         (already
>                 the case
>                     and cost pretty much nothing) and enable the user to
>                 produces very
>                     easily its own request from its filter (or
>         equivalent) for
>                 its usage
>                     IMO - which is IMO already doable but maybe there is
>         another
>                     shortcut we can introduce I didnt think about. If
>         you look
>                 one step
>                     further any web framework built on top of CDI does
>         it and
>                 therefore
>                     runs in a well known context.
>
>
>                     Romain Manni-Bucau
>                     @rmannibucau <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>
>                 <https://twitter.com/rmannibucau
>         <https://twitter.com/rmannibucau>>> |  Blog
>                     <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>
>                 <https://blog-rmannibucau.rhcloud.com
>         <https://blog-rmannibucau.rhcloud.com>>> | Old Wordpress Blog
>                     <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>
>                 <http://rmannibucau.wordpress.com
>         <http://rmannibucau.wordpress.com>>> | Github
>                     <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>
>                 <https://github.com/rmannibucau
>         <https://github.com/rmannibucau>>> | LinkedIn
>                     <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>
>                 <https://www.linkedin.com/in/rmannibucau
>         <https://www.linkedin.com/in/rmannibucau>>> | Tomitriber
>                     <http://www.tomitribe.com> | JavaEE Factory
>                     <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>
>                 <https://javaeefactory-rmannibucau.rhcloud.com
>         <https://javaeefactory-rmannibucau.rhcloud.com>>>
>
>                     2016-09-08 13:03 GMT+02:00 arjan tijms
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                     <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>:
>
>                         Hi,
>
>                         On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
>                 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>                         <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>
>                 wrote:
>
>                             that's a good question. In Weld, the request
>         object is
>                             captured during request context activation,
>         i.e. during
>                             ServletRequestListener.requestInitialized()
>                 notification and
>                             before any filter or servlet is invoked. So
>         wrappers are
>                             ignored and the original/first request is used.
>
>
>                         Indeed, although do note that some servers
>         (Liberty and
>                 WebLogic
>                         I think) send the
>                 ServletRequestListener.requestInitialized()
>                         notification rather late, and do that after the
>         application
>                         already has seen the request and has had a chance to
>                 wrap it.
>                         This by itself is a separate problem. So on these
>                 servers, Weld
>                         would receive an early request but not
>         necessarily the
>                 earliest.
>
>
>                             But TBH I don't think we can fix this easily
>         as I'm not
>                             aware of any portable way to listen for
>         "wrapping
>                 actions".
>
>
>                         This would have to happen with Server specific
>         code I guess,
>                         just as Weld now requires an SPI to obtain the
>         current
>                 principal
>                         for injection.
>
>                         You could say that the Servlet container could
>         store the
>                 request
>                         "somewhere" on a stack structure, just before it
>         invokes the
>                         ServerAuthModule, Filter, Servlet and anything
>         else I
>                 may have
>                         forgotten, and then when control flows back to
>         each Servlet,
>                         Filter, etc unwind that stack.
>
>                         At the very least the spec for now should perhaps
>                 clarify this?
>
>                         Kind regards,
>                         Arjan Tijms
>
>
>
>
>
>                             Martin
>
>                             Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>
>                                 Hi,
>
>                                 The CDI spec defines a built-in bean for
>         the type
>                                 HttpServletRequest. In
>                                 3.8 it says:
>
>                                 "A servlet container must provide the
>         following
>                 built-in
>                                 beans, all of
>                                 which have qualifier @Default:
>
>                                 a bean with bean type
>                                 javax.servlet.http.HttpServletRequest,
>         allowing
>                                 injection of a reference to the
>         HttpServletRequest"
>
>                                 An HttpServletRequest however can be wrapped
>                 multiple
>                                 times and by
>                                 multiple artefacts. I.e. by a
>         ServerAuthModule,
>                 Filter and a
>                                 RequestDispatcher.
>
>                                 The question now is; which version of the
>                                 HttpServletRequest is supposed
>                                 to be injected?
>
>                                 * The first one in the chain?
>                                 * The last one in the chain?
>                                 * The current one at a given point in
>         the chain?
>
>                                 A little bit of experimenting seems to
>         indicate
>                 it's now
>                                 often "one of
>                                 the first ones", e.g. the one that
>         happened to be
>                                 current when e.g. a
>                                 ServletRequestListener that initialises a
>                 specific CDI
>                                 implementation is
>                                 called.
>
>                                 I think this is a little confusing, as
>         working
>                 with an
>                                 injected request
>                                 can now totally ignore the request
>         wrapping that has
>                                 been done and break
>                                 an application badly.
>
>                                 Thoughts?
>
>                                 Kind regards,
>                                 Arjan Tijms
>
>
>
>
>         _______________________________________________
>                                 cdi-dev mailing list
>                                 [hidden email]
>         <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         <mailto:[hidden email] <mailto:[hidden email]>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                                 Note that for all code provided on this
>         list, the
>                                 provider licenses the code under the
>         Apache License,
>                                 Version 2
>
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>
>         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For
>                                 all other ideas provided on this list,
>         the provider
>                                 waives all patent and other intellectual
>                 property rights
>                                 inherent in such information.
>
>
>                             --
>                             Martin Kouba
>                             Software Engineer
>                             Red Hat, Czech Republic
>
>
>
>                         _______________________________________________
>                         cdi-dev mailing list
>                         [hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                 <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>
>
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>                 <https://lists.jboss.org/mailman/listinfo/cdi-dev
>         <https://lists.jboss.org/mailman/listinfo/cdi-dev>>>
>
>                         Note that for all code provided on this list,
>         the provider
>                         licenses the code under the Apache License,
>         Version 2
>                         (http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>
>                         <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>
>                 <http://www.apache.org/licenses/LICENSE-2.0.html
>         <http://www.apache.org/licenses/LICENSE-2.0.html>>>). For all
>                         other ideas provided on this list, the provider
>         waives all
>                         patent and other intellectual property rights
>         inherent
>                 in such
>                         information.
>
>
>
>
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.