You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2014/08/23 21:01:15 UTC

Re: cdictrl-servlet breaks cdi-1.1 and 1.2

Actually I don't get this module

why doing:

servletContextEvent.getServletContext().addListener(CdiServletRequestListener.class);
in a ServletContextListener instead of decorating the request listener
with @WebListener? - think addListener should be a
ServletContainerInitializer method only and not allowed in a
ServletContextListener.

Spec says:

UnsupportedOperationException - if this ServletContext was passed to
the ServletContextListener#contextInitialized method of a
ServletContextListener

+ the request filter itself is just starting/stopping request scope
which can be done by all impl so the gain of using deltaspike here is
not obvious (in particular since we handle less than impl -
@SessionScoped for instance).





Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-23 20:51 GMT+02:00 Mark Struberg <st...@yahoo.de>:
> Hi!
>
> cdictrl-servlet directly defines cdi-1.0 artifacts. This breaks Weld-1.2 and OWB-2.x.
>
> The whole module is actually pretty weird.
>
> It is a submodule of cdictrl but I seems to have not much to do with cdictrl. Instead it even has dependencies to deltaspike-core...
>
> How do we proceed?
> Sorry that this slipped through our quality control.
>
>
> LieGrue,
> strub

Re: cdictrl-servlet breaks cdi-1.1 and 1.2

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well you used a hack which will not be supported in few weeks so I think it
should be at least reworked.

I don't get the embedded argument btw, it should work, if not it needs to
be fixed.

Last point: why not using cdi container filters instead?
Le 23 août 2014 22:52, "John D. Ament" <jo...@gmail.com> a écrit :

> Hi Romain,
>
> Actually, that was added specifically for Tomcat.  Only in Tomcat could I
> not directly register the request listener, instead you need to implement
> two listeners to make Tomcat bind it in embedded mode.  It's silly, in my
> opinion, but I think it's because of how Tomcat ships (standalone servlet
> container + libraries for building embedded apps).
>
> The reason to not use @WebListener? Well, this is targeted for embedded
> runtimes.  Typically, app servers only process annotations, embedded
> runtimes (Jetty/Undertow) don't typically do any annotation processing and
> want the app to register everything on embedded boot.  Tomcat seems to
> support it in a mixed fashion for embedded (some annotations work, others
> don't).  Hence I figured the safest bet was to include two listeners and
> provide instructions (via sample boot code) on how to register.
>
>
> On Sat, Aug 23, 2014 at 3:01 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Actually I don't get this module
> >
> > why doing:
> >
> >
> >
> servletContextEvent.getServletContext().addListener(CdiServletRequestListener.class);
> > in a ServletContextListener instead of decorating the request listener
> > with @WebListener? - think addListener should be a
> > ServletContainerInitializer method only and not allowed in a
> > ServletContextListener.
> >
> > Spec says:
> >
> > UnsupportedOperationException - if this ServletContext was passed to
> > the ServletContextListener#contextInitialized method of a
> > ServletContextListener
> >
> > + the request filter itself is just starting/stopping request scope
> > which can be done by all impl so the gain of using deltaspike here is
> > not obvious (in particular since we handle less than impl -
> > @SessionScoped for instance).
> >
> >
> >
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> > 2014-08-23 20:51 GMT+02:00 Mark Struberg <st...@yahoo.de>:
> > > Hi!
> > >
> > > cdictrl-servlet directly defines cdi-1.0 artifacts. This breaks
> Weld-1.2
> > and OWB-2.x.
> > >
> > > The whole module is actually pretty weird.
> > >
> > > It is a submodule of cdictrl but I seems to have not much to do with
> > cdictrl. Instead it even has dependencies to deltaspike-core...
> > >
> > > How do we proceed?
> > > Sorry that this slipped through our quality control.
> > >
> > >
> > > LieGrue,
> > > strub
> >
>

Re: cdictrl-servlet breaks cdi-1.1 and 1.2

Posted by "John D. Ament" <jo...@gmail.com>.
Hi Romain,

Actually, that was added specifically for Tomcat.  Only in Tomcat could I
not directly register the request listener, instead you need to implement
two listeners to make Tomcat bind it in embedded mode.  It's silly, in my
opinion, but I think it's because of how Tomcat ships (standalone servlet
container + libraries for building embedded apps).

The reason to not use @WebListener? Well, this is targeted for embedded
runtimes.  Typically, app servers only process annotations, embedded
runtimes (Jetty/Undertow) don't typically do any annotation processing and
want the app to register everything on embedded boot.  Tomcat seems to
support it in a mixed fashion for embedded (some annotations work, others
don't).  Hence I figured the safest bet was to include two listeners and
provide instructions (via sample boot code) on how to register.


On Sat, Aug 23, 2014 at 3:01 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Actually I don't get this module
>
> why doing:
>
>
> servletContextEvent.getServletContext().addListener(CdiServletRequestListener.class);
> in a ServletContextListener instead of decorating the request listener
> with @WebListener? - think addListener should be a
> ServletContainerInitializer method only and not allowed in a
> ServletContextListener.
>
> Spec says:
>
> UnsupportedOperationException - if this ServletContext was passed to
> the ServletContextListener#contextInitialized method of a
> ServletContextListener
>
> + the request filter itself is just starting/stopping request scope
> which can be done by all impl so the gain of using deltaspike here is
> not obvious (in particular since we handle less than impl -
> @SessionScoped for instance).
>
>
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-08-23 20:51 GMT+02:00 Mark Struberg <st...@yahoo.de>:
> > Hi!
> >
> > cdictrl-servlet directly defines cdi-1.0 artifacts. This breaks Weld-1.2
> and OWB-2.x.
> >
> > The whole module is actually pretty weird.
> >
> > It is a submodule of cdictrl but I seems to have not much to do with
> cdictrl. Instead it even has dependencies to deltaspike-core...
> >
> > How do we proceed?
> > Sorry that this slipped through our quality control.
> >
> >
> > LieGrue,
> > strub
>