Thank you very much Martin, I'll try this asap! :)

On Tue, Oct 28, 2014 at 3:38 PM, Martin Grigorov <[email protected]>
wrote:

> I've applied the improvement.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Oct 28, 2014 at 12:05 PM, Martin Grigorov <[email protected]>
> wrote:
>
> > Same for org.apache.wicket.atmosphere.AtmosphereRequestHandler
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Tue, Oct 28, 2014 at 11:59 AM, Martin Grigorov <[email protected]>
> > wrote:
> >
> >> Hi,
> >>
> >> I see a simple way to improve this.
> >> At
> >>
> https://github.com/apache/wicket/blob/master/wicket-cdi-1.1/src/main/java/org/apache/wicket/cdi/ConversationPropagator.java#L207
> >> there is a logic to not activate conversation
> >> for BufferedResponseRequestHandler.
> >>
> >> With the following check we can disable it for WebSocketRequestHandler
> >> too:
> >>
> >> diff --git
> >>
> i/wicket-cdi-1.1/src/main/java/org/apache/wicket/cdi/ConversationPropagator.java
> >>
> w/wicket-cdi-1.1/src/main/java/org/apache/wicket/cdi/ConversationPropagator.java
> >> index 7a85d98..738a7bc 100644
> >> ---
> >>
> i/wicket-cdi-1.1/src/main/java/org/apache/wicket/cdi/ConversationPropagator.java
> >> +++
> >>
> w/wicket-cdi-1.1/src/main/java/org/apache/wicket/cdi/ConversationPropagator.java
> >> @@ -36,6 +36,7 @@ import
> >>
> org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandle
> >>  import org.apache.wicket.request.mapper.parameter.PageParameters;
> >>  import org.apache.wicket.request.resource.PackageResourceReference;
> >>  import org.apache.wicket.util.lang.Args;
> >> +import org.apache.wicket.util.lang.Classes;
> >>  import org.slf4j.Logger;
> >>  import org.slf4j.LoggerFactory;
> >>
> >> @@ -209,6 +210,8 @@ public class ConversationPropagator extends
> >> AbstractRequestCycleListener
> >>                                 // we do not care about pages that are
> >> being rendered from a
> >>                                 // buffer
> >>                                 return false;
> >> +                       } else if
> >>
> ("org.apache.wicket.protocol.ws.api.WebSocketRequestHandler".equals(Classes.name(handler.getClass())))
> >> {
> >> +                               return false;
> >>                         }
> >>                 }
> >>                 return true;
> >>
> >> It is error prone for refactoring but there won't be dependency to
> >> websocket-core.jar. I don't expect renaming WSRH anytime soon!
> >>
> >> WDYT ?
> >>
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Sat, Oct 25, 2014 at 8:09 AM, Martin Grigorov <[email protected]>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Thanks for the investigation, John!
> >>>
> >>> WebSocket communication is not intercepted by servlet filters and DI
> >>> frameworks cannot prepare their proxies for request and session scoped
> >>> beans.
> >>>
> >>> This is documented in the guide.
> >>>
> >>> With ver. 4.1.0 Spring introduced support for scoped beans in their
> impl
> >>> of web sockets. But it works on a higher level...
> >>> On Oct 24, 2014 11:17 PM, "John Sarman" <[email protected]> wrote:
> >>>
> >>>> The last comment on that issue states:
> >>>> It’s the responsibility of Websocket spec to implement these scopes.
> We
> >>>> should ensure they take the point before closing the ticket.
> >>>>
> >>>> I personally would down vote the suggestion that
> wicket-native-websocket
> >>>> should assume responsibility to implement the scopes, and just
> >>>> explicitly
> >>>> state this feature is not supported.
> >>>> Thanks for the current status of why this does not work.
> >>>>
> >>>> John
> >>>>
> >>>> On Fri, Oct 24, 2014 at 4:05 PM, Emond Papegaaij <
> >>>> [email protected]>
> >>>> wrote:
> >>>>
> >>>> > As far as I know, combining CDI's RequestScoped and SessionScoped
> >>>> beans
> >>>> > with websockets is stil not supported by the spec. You can find
> >>>> progress on
> >>>> > this here: https://issues.jboss.org/browse/CDI-370
> >>>> >
> >>>> > Best regards,
> >>>> > Emond
> >>>> >
> >>>> > On Fri, Oct 24, 2014 at 9:54 PM, John Sarman <[email protected]>
> >>>> wrote:
> >>>> >
> >>>> > > Ok I was able to trigger a ContextNotActiveException.  This
> >>>> exception
> >>>> > > occurs in both M3 and snapshot.  What I did to create the issue
> was
> >>>> to
> >>>> > > create a SessionScoped service. This is the CDI part.  I then
> >>>> Injected
> >>>> > that
> >>>> > > in to the HomePage.class.  The service was simple, has two methods
> >>>> > > increment and getCount.  When I call increment inside an
> overridden
> >>>> event
> >>>> > > method of the WebSocketBehavior such as onMessage, I
> >>>> > > get: org.jboss.weld.context.ContextNotActiveException:
> WELD-001303:
> >>>> No
> >>>> > > active contexts for scope type
> >>>> javax.enterprise.context.SessionScoped.
> >>>> > >
> >>>> > > This proves the divorce claim, that is an Injected Scope based
> >>>> service
> >>>> > will
> >>>> > > not have an active context of said scope during a WebSocketEvent.
> >>>> > > Just to confirm this I changed the Service scope to
> >>>> ApplicationScoped and
> >>>> > > it works fine.  ApplicationScoped does not require a scope
> (request,
> >>>> > > session, or conversation).
> >>>> > >
> >>>> > > At the surface what I found is that either the
> >>>> wicket-native-websocket
> >>>> > > needs to depend on wicket-cdi-1.1 and setup the contexts during
> the
> >>>> > > events(not recommended), or wicket-cdi-1.1 needs to somehow
> >>>> intercept the
> >>>> > > websocket events and activate the contexts (not even sure if this
> is
> >>>> > > plausible), or (my recommendation) is that emond papegaaij and
> Igor
> >>>> > > Vaynberg
> >>>> > > look into this issue and come up with a proper solution.
> >>>> > >
> >>>> > > When cdi-1.1 was initially introduced into the codebase, the
> >>>> activation
> >>>> > of
> >>>> > > scope was initially solved by requiring a dependency on weld.
> >>>> Ultimately
> >>>> > > Emond simplified this in the current commit of cdi-1.1 and added
> >>>> code
> >>>> > > earlier in the cdi core to allow whatever cdi implementation
> >>>> framework to
> >>>> > > trigger the activation mechanism.
> >>>> > >
> >>>> > > Somehow this same triggering of context activation needs to occur
> >>>> in the
> >>>> > > websockets code so that if a javax.inject annotation service is
> >>>> called
> >>>> > > during a websocket event that the proper context has been
> activated.
> >>>> > >
> >>>> > > Input is definitely needed from the Wicket team to prevent the two
> >>>> > packages
> >>>> > > from divorcing :)
> >>>> > >
> >>>> > >
> >>>> > > --
> >>>> > > John
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > > On Fri, Oct 24, 2014 at 3:02 PM, Sebastien <[email protected]>
> >>>> wrote:
> >>>> > >
> >>>> > > > Hi John, I will give you an example on monday...
> >>>> > > > On Oct 24, 2014 8:46 PM, "John Sarman" <[email protected]>
> >>>> wrote:
> >>>> > > >
> >>>> > > > > This works fine by overriding onMessage in your test class and
> >>>> adding
> >>>> > > > this
> >>>> > > > > crude html to your html.
> >>>> > > > >
> >>>> > > > > java:
> >>>> > > > > protected void onMessage(WebSocketRequestHandler handler,
> >>>> TextMessage
> >>>> > > > > message)
> >>>> > > > > {
> >>>> > > > >                         LOG.info(message.getText());
> >>>> > > > >
> >>>> > > > > }
> >>>> > > > >
> >>>> > > > > html:
> >>>> > > > >
> >>>> > > > > <button onclick="Wicket.WebSocket.send('message');">PRESS
> >>>> ME</button>
> >>>> > > > >
> >>>> > > > >
> >>>> > > > > Long story longer, I was able to use chrome console to hack a
> >>>> bad
> >>>> > test,
> >>>> > > > > Martin or other contributors, is there an up to date example
> >>>> for the
> >>>> > > > native
> >>>> > > > > websockets, or a simple point me into the right direction to
> >>>> better
> >>>> > > > > understand how to implement a better real world use case, both
> >>>> to
> >>>> > test
> >>>> > > > the
> >>>> > > > > WICKET-5733 and just to learn about the wicket way to
> implement
> >>>> > native
> >>>> > > > > websocket code.
> >>>> > > > >
> >>>> > > > > Thanks,
> >>>> > > > > John
> >>>> > > > >
> >>>> > > > >
> >>>> > > > > On Fri, Oct 24, 2014 at 2:17 PM, John Sarman <
> >>>> [email protected]>
> >>>> > > > wrote:
> >>>> > > > >
> >>>> > > > > > Yeah, I am just trying to trigger the onMessage at this
> point
> >>>> > mainly
> >>>> > > > just
> >>>> > > > > > to learn more about the native websocket package at the
> >>>> moment.
> >>>> > So I
> >>>> > > > am
> >>>> > > > > > just adding a button in html and adding some inline js to
> the
> >>>> > > onclick.
> >>>> > > > > > First attempt I copy pasted var ws = new Wicket.WebSocket();
> >>>> > > > > > ws.send('message'); from the wiki into the onclick and got a
> >>>> > > exception
> >>>> > > > in
> >>>> > > > > > the chrome console stating cannot send message while in the
> >>>> > > connecting
> >>>> > > > > > state.  Assuming I need to learn more here, but I will keep
> >>>> probing
> >>>> > > at
> >>>> > > > > this
> >>>> > > > > > mainly as an effort to learn how to use the wicket native
> >>>> > websockets.
> >>>> > > > > >
> >>>> > > > > >
> >>>> > > > > >
> >>>> > > > > > On Fri, Oct 24, 2014 at 2:11 PM, Sebastien <
> [email protected]>
> >>>> > wrote:
> >>>> > > > > >
> >>>> > > > > >> Hi John,
> >>>> > > > > >>
> >>>> > > > > >> If you get the "client connected" message and no
> stacktrace,
> >>>> we
> >>>> > are
> >>>> > > > > good I
> >>>> > > > > >> guess :)
> >>>> > > > > >>
> >>>> > > > > >> I will investigate on my side given your previous answer...
> >>>> > > > > >>
> >>>> > > > > >> Thanks again,
> >>>> > > > > >> Sebastien
> >>>> > > > > >> On Oct 24, 2014 7:58 PM, "John Sarman" <
> [email protected]
> >>>> >
> >>>> > > wrote:
> >>>> > > > > >>
> >>>> > > > > >> > Sebastian,
> >>>> > > > > >> > Just updated my snapshots, clean built wicket, changed
> the
> >>>> > > > dependency
> >>>> > > > > to
> >>>> > > > > >> > 7.0.0-SNAPSHOT and all seems well running on Wildfly.  Is
> >>>> there
> >>>> > > > > >> something
> >>>> > > > > >> > else I need to do to trigger your error.  Currently page
> >>>> comes
> >>>> > up
> >>>> > > > with
> >>>> > > > > >> the
> >>>> > > > > >> > label  7.0.0-SNAPSHOT. I even checked my .m2 repo to
> >>>> verify my
> >>>> > jar
> >>>> > > > > files
> >>>> > > > > >> > had proper timestamp, which they did.  I went so far as
> to
> >>>> clone
> >>>> > > > > wicket,
> >>>> > > > > >> > build, and test app.  Is there a way to trigger the
> >>>> websocket
> >>>> > > push,
> >>>> > > > > >> because
> >>>> > > > > >> > currently log file only states:
> >>>> > > > > >> >
> >>>> > > > > >> > 13:40:19,258 ERROR [stderr] (default task-1)
> >>>> > > > > >> >
> >>>> > >
> ********************************************************************
> >>>> > > > > >> > 13:40:19,259 ERROR [stderr] (default task-1) *** WARNING:
> >>>> Wicket
> >>>> > > is
> >>>> > > > > >> running
> >>>> > > > > >> > in DEVELOPMENT mode.              ***
> >>>> > > > > >> > 13:40:19,259 ERROR [stderr] (default task-1) ***
> >>>> > > > > >> >     ^^^^^^^^^^^                    ***
> >>>> > > > > >> > 13:40:19,259 ERROR [stderr] (default task-1) *** Do NOT
> >>>> deploy
> >>>> > to
> >>>> > > > your
> >>>> > > > > >> live
> >>>> > > > > >> > server(s) without changing this.  ***
> >>>> > > > > >> > 13:40:19,259 ERROR [stderr] (default task-1) *** See
> >>>> > > > > >> > Application#getConfigurationType() for more information.
> >>>> ***
> >>>> > > > > >> > 13:40:19,259 ERROR [stderr] (default task-1)
> >>>> > > > > >> >
> >>>> > >
> ********************************************************************
> >>>> > > > > >> > 13:40:21,592 INFO  [com.mycompany.HomePage] (default
> >>>> task-7)
> >>>> > > Client
> >>>> > > > > >> > connected
> >>>> > > > > >> >
> >>>> > > > > >> > where the relevant part is the last log statement stating
> >>>> > > websocket
> >>>> > > > is
> >>>> > > > > >> > connected to client.
> >>>> > > > > >> >
> >>>> > > > > >> > I would like to see if the log message from onPush works
> >>>> fine,
> >>>> > but
> >>>> > > > > >> unsure
> >>>> > > > > >> > how to test this ATM.
> >>>> > > > > >> >
> >>>> > > > > >> > Hope this helps,
> >>>> > > > > >> > John
> >>>> > > > > >> >
> >>>> > > > > >> >
> >>>> > > > > >> >
> >>>> > > > > >> > On Fri, Oct 24, 2014 at 12:03 PM, Sebastien <
> >>>> [email protected]>
> >>>> > > > wrote:
> >>>> > > > > >> >
> >>>> > > > > >> > > Hi,
> >>>> > > > > >> > >
> >>>> > > > > >> > > On Fri, Oct 24, 2014 at 6:00 PM, Martin Grigorov <
> >>>> > > > > >> [email protected]>
> >>>> > > > > >> > > wrote:
> >>>> > > > > >> > >
> >>>> > > > > >> > > > John,
> >>>> > > > > >> > > >
> >>>> > > > > >> > > > The quickstart uses 7.0.0-M3.
> >>>> > > > > >> > > >
> >>>> > > > > >> > >
> >>>> > > > > >> > > Oops, right! I'm really sorry for that! I probably
> >>>> wanted to
> >>>> > > test
> >>>> > > > a
> >>>> > > > > >> last
> >>>> > > > > >> > > time it was not repro in -M3...
> >>>> > > > > >> > >
> >>>> > > > > >> > >
> >>>> > > > > >> > >
> >>>> > > > > >> > > > Sebastien said that the problem is in 7.0.0-SNAPSHOT.
> >>>> > > > > >> > > >
> >>>> > > > > >> > > > Martin Grigorov
> >>>> > > > > >> > > > Wicket Training and Consulting
> >>>> > > > > >> > > > https://twitter.com/mtgrigorov
> >>>> > > > > >> > > >
> >>>> > > > > >> > > > On Fri, Oct 24, 2014 at 6:51 PM, John Sarman <
> >>>> > > > > [email protected]>
> >>>> > > > > >> > > wrote:
> >>>> > > > > >> > > >
> >>>> > > > > >> > > > > Sebastian,
> >>>> > > > > >> > > > > I also deployed your quickstart in wildfly-8.0Final
> >>>> with
> >>>> > no
> >>>> > > > > >> changes,
> >>>> > > > > >> > > and
> >>>> > > > > >> > > > > all seems well.  As for the quickstart test, you
> >>>> would
> >>>> > need
> >>>> > > to
> >>>> > > > > use
> >>>> > > > > >> > > > cdi-unit
> >>>> > > > > >> > > > > as a test dependency to enable the cdi aspects for
> >>>> the
> >>>> > > > > >> wicket-tester.
> >>>> > > > > >> > > To
> >>>> > > > > >> > > > > successfully add that please look at the test
> >>>> section in
> >>>> > the
> >>>> > > > > >> > > > wicket-cdi-1.1
> >>>> > > > > >> > > > > code.  In there you will find an extended version
> of
> >>>> > > > > WicketTester
> >>>> > > > > >> > that
> >>>> > > > > >> > > > > properly starts and stops the different contexts.
> >>>> Without
> >>>> > > > > using a
> >>>> > > > > >> > > > package
> >>>> > > > > >> > > > > like cdi-unit or arquillian, I am afraid you will
> >>>> always
> >>>> > > get a
> >>>> > > > > >> > Context
> >>>> > > > > >> > > > > based exception because there is no cdi service
> >>>> provider
> >>>> > > > > >> activated.
> >>>> > > > > >> > > > >
> >>>> > > > > >> > > > > On Fri, Oct 24, 2014 at 11:15 AM, John Sarman <
> >>>> > > > > >> [email protected]>
> >>>> > > > > >> > > > > wrote:
> >>>> > > > > >> > > > >
> >>>> > > > > >> > > > > > I was able to start your test app in Glassfish4
> >>>> without
> >>>> > > > > changes.
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > For Tomcat I added
> >>>> > > > > >> > > > > >                  <dependency>
> >>>> > > > > >> > > > > > <groupId>org.jboss.weld</groupId>
> >>>> > > > > >> > > > > > <artifactId>weld-core</artifactId>
> >>>> > > > > >> > > > > > <version>2.1.2.Final</version>
> >>>> > > > > >> > > > > > </dependency>
> >>>> > > > > >> > > > > > <dependency>
> >>>> > > > > >> > > > > > <groupId>org.jboss.weld.servlet</groupId>
> >>>> > > > > >> > > > > > <artifactId>weld-servlet-core</artifactId>
> >>>> > > > > >> > > > > > <version>2.1.2.Final</version>
> >>>> > > > > >> > > > > > </dependency>
> >>>> > > > > >> > > > > > to the pom.
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > I then added
> >>>> > > > > >> > > > > > <listener>
> >>>> > > > > >> > > > > > <!-- initialize Weld in servlet environment -->
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > >
> >>>> > > > > >> > > >
> >>>> > > > > >> > >
> >>>> > > > > >> >
> >>>> > > > > >>
> >>>> > > > >
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
> >>>> > > > > >> > > > > > </listener>
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > to web.xml
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > The homepage then loaded fine as well.  If you
> >>>> look in
> >>>> > > > > >> > > wicket-examples
> >>>> > > > > >> > > > > you
> >>>> > > > > >> > > > > > can find these CDI related additions to the
> >>>> pom.xml and
> >>>> > > the
> >>>> > > > > >> > web.xml.
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > Hope this helps
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > John Sarman
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > > On Fri, Oct 24, 2014 at 4:12 AM, Sebastien <
> >>>> > > > [email protected]>
> >>>> > > > > >> > wrote:
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >> Hi Martin,
> >>>> > > > > >> > > > > >>
> >>>> > > > > >> > > > > >> On Thu, Oct 23, 2014 at 8:27 PM, Martin
> Grigorov <
> >>>> > > > > >> > > > [email protected]>
> >>>> > > > > >> > > > > >> wrote:
> >>>> > > > > >> > > > > >>
> >>>> > > > > >> > > > > >> > Ticket please.
> >>>> > > > > >> > > > > >> > With quickstart will be processed sooner ;-)
> >>>> > > > > >> > > > > >> >
> >>>> > > > > >> > > > > >>
> >>>> > > > > >> > > > > >> Fair :)
> >>>> > > > > >> > > > > >>
> https://issues.apache.org/jira/browse/WICKET-5733
> >>>> > > > > >> > > > > >>
> >>>> > > > > >> > > > > >> Best regards,
> >>>> > > > > >> > > > > >> Sebastien.
> >>>> > > > > >> > > > > >>
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > > >
> >>>> > > > > >> > > > >
> >>>> > > > > >> > > >
> >>>> > > > > >> > >
> >>>> > > > > >> >
> >>>> > > > > >>
> >>>> > > > > >
> >>>> > > > > >
> >>>> > > > >
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>
> >
>

Reply via email to