how to implement a decorator
I'm trying to figure out how to implement a decorator tag. Here's what I
mean:
I want:
wicket:modBox style=1
span wicket:id=modBoxText/span
/wicket:modBox
to render to:
div class=mod-style-1
spanFOO!/span
/div
with nothing more than the usual add( new Label( modBoxText, FOO! ) )
in the panel class. Note that this is different than a border since there
is no add() for the decorator. The goal of this is to create reusable ui
elements that can be inserted into markup without requiring any wiring in
the java class. From what I understand, this _should_ be possible.
I tried to do this with an IComponentResolver by creating an instance of a
border, but I quickly ran into trouble with the component hierarchy when I
did this and tried to add components to the content of the decorator (such
as span wicket:id=modBoxText/span). Here are the artifacts for this
to get an idea:
ModBoxBorderResolver.java
public class ModBoxBorderResolver implements IComponentResolver {
@Override
public Component resolve( MarkupContainer container, MarkupStream
markupStream, ComponentTag tag ) {
if( tag instanceof WicketTag ) {
String tagName = tag.getName();
if( tag.getName().equalsIgnoreCase( modBox ) ) {
return ModBoxBorder( modBox );
}
}
return null;
}
}
ModBoxBorder.java
public class ModBoxBorder extends Border {
...
}
ModBoxBorder.html
wicket:border xmlns:wicket=http://wicket.apache.org;
div wicket:id=div class=${mod-style}
wicket:body /
/div
/wicket:border
I also notice BorderBehavior whihc might be another avenue, but I'm not
sure exactly how I could get this to work simply by adding tags to the
markup and an IComponentResolver.
Has anyone done anything like this already? Perhaps there is something
already in Wicket that I'm overlooking.
Re: problem with page refresh
Hi Ale. I had a very similar problem, and I was able to get the behavior I
expected by changing the render strategy to ONE_PASS_RENDER in
Application.init(). Have a look at this
http://apache-wicket.1842946.n4.nabble.com/refresh-and-AjaxFallbackDefaultDataTable-td4384935.html
On Wed, Apr 18, 2012 at 7:12 AM, alezx superdelpi...@gmail.com wrote:
Hi guys, I ran into a problem lately,
I have an instance variable in my panel and an ajax behaviour
public final class ScrollLoader extends Panel implements IHeaderContributor
{
int number = 0;
private AbstractDefaultAjaxBehavior b;
..
//constructor
public Scrolloader (...){
b = new AbstractDefaultAjaxBehavior() {
@Override
protected void respond(AjaxRequestTarget target) {
System.out.println(number is +number);
number++;
}
}
..
}
}
when I click a button on the page, with ajax I call this behaviour and the
number is incremented.
if I click on the buttons 5 times, the number increments to 0,1,2,3,4,
then if I refresh the page and than click on the button other 5 times, the
number goes to 9 (5,6,7,8,9)
//so far, so good!
but now if I refresh the page again, and I click on the button the number
starts incrementing from 4 and not from 9!! (so If I press the button 5
times I see again 5,6,7,8,9 and not 10,11,12..)
same problem when I load the page for the first time:
If I *refresh * the page before incrementing the value, the number starts
incrementing from 0
so i get 0,1,2,3,4
if I refresh again, the number starts incrementing from 0 again..
in other words when I refresh the page 2, 3, 4 times, the number starts
incrementing from the value reached before the first refresh, after that
first refresh any change to the number is lost..
so what do I do wrong?
sorry if this is a bit confusing,
and thanks for your help!
ale
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/problem-with-page-refresh-tp4567392p4567392.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
A stateless bean is injected into the home page class. Load the page in two tabs (so twice in the same session), then on the first tab, press the button. The error occurs every time in this scenario. On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas jtou...@gmail.com wrote: I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the mix. In certain cases when Wicket deserializes a Page containing a reference to a CDI bean, I get this exception: In what cases exactly ? Because the problem is Caused by: java.lang.ClassNotFoundException: org.jboss.msc.service.ServiceName from [Module deployment.wicket.war:main from Service Module Loader] In what cases this class is no more loadable by the current class loader ? 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] (http--127.0.0.1-8080-1) Error detaching RequestHandler: java.lang.RuntimeException: Could not deserialize object using: class org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.PageLogData.init(PageLogData.java:51) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.init(ListenerInterfaceLogData.java:56) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) [wicket-request-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) [wicket-core-1.5.5.jar:1.5.5] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I'm not familiar with the Wicketopia source, but doing a quick scan I can't find any EJBs in there. The problem in this case occurs if the FooStateless class is @Stateless. Changing this to @ApplicationScoped, the problem goes away. On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas jtou...@gmail.com wrote: A stateless bean is injected into the home page class. Load the page in two tabs (so twice in the same session), then on the first tab, press the button. The error occurs every time in this scenario. On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas jtou...@gmail.com wrote: I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the mix. In certain cases when Wicket deserializes a Page containing a reference to a CDI bean, I get this exception: In what cases exactly ? Because the problem is Caused by: java.lang.ClassNotFoundException: org.jboss.msc.service.ServiceName from [Module deployment.wicket.war:main from Service Module Loader] In what cases this class is no more loadable by the current class loader ? 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] (http--127.0.0.1-8080-1) Error detaching RequestHandler: java.lang.RuntimeException: Could not deserialize object using: class org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.PageLogData.init(PageLogData.java:51) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.init(ListenerInterfaceLogData.java:56) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) [wicket-request-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) [wicket-core-1.5.5.jar:1.5.5] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
@Override
protected void onBeforeRender() {
System.out.println( foo );
System.out.println( foo.getClass() );
super.onBeforeRender();
}
When using @Stateless, the output is :
08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view class:
com.foo.FooStateless of EJB: FooStateless
08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
when using @ApplicationScoped, the output is:
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
com.foo.FooStateless@201a6e9
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
com.foo.FooStateless$Proxy$_$$_WeldClientProxy
On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov mgrigo...@apache.orgwrote:
The difference is that scoped beans are represented by proxy.
I guess there is no proxy for the stateless EJB. You can verify this
by putting a breakpoint in your page's #onBeforeRender() and checking
the type of the injected value.
Later during deserialization the current class loader cannot load
class org.jboss.msc.service.ServiceName.
In the case with scoped bean the proxy is loaded without problems and
it seems the proxy itself deals with the class loading of the
underlying bean.
On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas jtou...@gmail.com
wrote:
I'm not familiar with the Wicketopia source, but doing a quick scan I
can't
find any EJBs in there. The problem in this case occurs if the
FooStateless
class is @Stateless. Changing this to @ApplicationScoped, the problem
goes
away.
On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas jtou...@gmail.com
wrote:
A stateless bean is injected into the home page class. Load the page in
two tabs (so twice in the same session), then on the first tab, press
the
button. The error occurs every time in this scenario.
On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas jtou...@gmail.com
wrote:
I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the
mix.
In certain cases when Wicket deserializes a Page containing a
reference
to
a CDI bean, I get this exception:
In what cases exactly ?
Because the problem is
Caused by: java.lang.ClassNotFoundException:
org.jboss.msc.service.ServiceName from [Module
deployment.wicket.war:main
from Service Module Loader]
In what cases this class is no more loadable by the current class
loader ?
15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack]
(http--127.0.0.1-8080-1) Error detaching RequestHandler:
java.lang.RuntimeException: Could not deserialize object using: class
org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.logger.PageLogData.init(PageLogData.java:51)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.init(ListenerInterfaceLogData.java:56)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792)
[wicket-core-1.5.5.jar:1.5.5
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I'll check it out thanks!
On Thu, Apr 12, 2012 at 11:33 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
weld doesnt wrap ejbs in serializable proxies. if you want to inject
ejbs you should do it with wicket-jee module found in wicketstuff.
-igor
On Thu, Apr 12, 2012 at 5:55 AM, Jonathan Tougas jtou...@gmail.com
wrote:
@Override
protected void onBeforeRender() {
System.out.println( foo );
System.out.println( foo.getClass() );
super.onBeforeRender();
}
When using @Stateless, the output is :
08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view
class:
com.foo.FooStateless of EJB: FooStateless
08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
when using @ApplicationScoped, the output is:
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
com.foo.FooStateless@201a6e9
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
com.foo.FooStateless$Proxy$_$$_WeldClientProxy
On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov mgrigo...@apache.org
wrote:
The difference is that scoped beans are represented by proxy.
I guess there is no proxy for the stateless EJB. You can verify this
by putting a breakpoint in your page's #onBeforeRender() and checking
the type of the injected value.
Later during deserialization the current class loader cannot load
class org.jboss.msc.service.ServiceName.
In the case with scoped bean the proxy is loaded without problems and
it seems the proxy itself deals with the class loading of the
underlying bean.
On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas jtou...@gmail.com
wrote:
I'm not familiar with the Wicketopia source, but doing a quick scan I
can't
find any EJBs in there. The problem in this case occurs if the
FooStateless
class is @Stateless. Changing this to @ApplicationScoped, the problem
goes
away.
On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas jtou...@gmail.com
wrote:
A stateless bean is injected into the home page class. Load the page
in
two tabs (so twice in the same session), then on the first tab, press
the
button. The error occurs every time in this scenario.
On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov
mgrigo...@apache.org
wrote:
Hi,
On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas
jtou...@gmail.com
wrote:
I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to
the
mix.
In certain cases when Wicket deserializes a Page containing a
reference
to
a CDI bean, I get this exception:
In what cases exactly ?
Because the problem is
Caused by: java.lang.ClassNotFoundException:
org.jboss.msc.service.ServiceName from [Module
deployment.wicket.war:main
from Service Module Loader]
In what cases this class is no more loadable by the current class
loader ?
15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack]
(http--127.0.0.1-8080-1) Error detaching RequestHandler:
java.lang.RuntimeException: Could not deserialize object using:
class
org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.request.handler.logger.PageLogData.init(PageLogData.java:51)
[wicket-core-1.5.5
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
I looked into wicket-jee but this won't do for me.
I don't think this problem is Wicket related in any event. Here are some
links I came across.
- https://community.jboss.org/thread/179757
- http://java.net/jira/browse/GLASSFISH-12599
- https://community.jboss.org/thread/179324#comment105426
- https://issues.jboss.org/browse/WELD-290
For now I have a workaround. I can i@Inject a SLSB into an
@ApplicationScoped component, and @Inject this into Wicket Pages. These
make it through serialization intact. It's not pretty, but it works for now
and will buy me some time to get to the bottom of this.
On Thu, Apr 12, 2012 at 11:56 AM, Jonathan Tougas jtou...@gmail.com wrote:
I'll check it out thanks!
On Thu, Apr 12, 2012 at 11:33 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
weld doesnt wrap ejbs in serializable proxies. if you want to inject
ejbs you should do it with wicket-jee module found in wicketstuff.
-igor
On Thu, Apr 12, 2012 at 5:55 AM, Jonathan Tougas jtou...@gmail.com
wrote:
@Override
protected void onBeforeRender() {
System.out.println( foo );
System.out.println( foo.getClass() );
super.onBeforeRender();
}
When using @Stateless, the output is :
08:52:35,027 INFO [stdout] (http--127.0.0.1-8080-1) Proxy for view
class:
com.foo.FooStateless of EJB: FooStateless
08:52:35,028 INFO [stdout] (http--127.0.0.1-8080-1) class
com.foo.FooStateless$Proxy$_$$_Weld$Proxy$
when using @ApplicationScoped, the output is:
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4)
com.foo.FooStateless@201a6e9
08:54:00,831 INFO [stdout] (http--127.0.0.1-8080-4) class
com.foo.FooStateless$Proxy$_$$_WeldClientProxy
On Thu, Apr 12, 2012 at 8:46 AM, Martin Grigorov mgrigo...@apache.org
wrote:
The difference is that scoped beans are represented by proxy.
I guess there is no proxy for the stateless EJB. You can verify this
by putting a breakpoint in your page's #onBeforeRender() and checking
the type of the injected value.
Later during deserialization the current class loader cannot load
class org.jboss.msc.service.ServiceName.
In the case with scoped bean the proxy is loaded without problems and
it seems the proxy itself deals with the class loading of the
underlying bean.
On Thu, Apr 12, 2012 at 3:40 PM, Jonathan Tougas jtou...@gmail.com
wrote:
I'm not familiar with the Wicketopia source, but doing a quick scan I
can't
find any EJBs in there. The problem in this case occurs if the
FooStateless
class is @Stateless. Changing this to @ApplicationScoped, the problem
goes
away.
On Thu, Apr 12, 2012 at 8:28 AM, Jonathan Tougas jtou...@gmail.com
wrote:
A stateless bean is injected into the home page class. Load the
page in
two tabs (so twice in the same session), then on the first tab,
press
the
button. The error occurs every time in this scenario.
On Thu, Apr 12, 2012 at 2:41 AM, Martin Grigorov
mgrigo...@apache.org
wrote:
Hi,
On Wed, Apr 11, 2012 at 10:54 PM, Jonathan Tougas
jtou...@gmail.com
wrote:
I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to
the
mix.
In certain cases when Wicket deserializes a Page containing a
reference
to
a CDI bean, I get this exception:
In what cases exactly ?
Because the problem is
Caused by: java.lang.ClassNotFoundException:
org.jboss.msc.service.ServiceName from [Module
deployment.wicket.war:main
from Service Module Loader]
In what cases this class is no more loadable by the current class
loader ?
15:10:30,841 ERROR
[org.apache.wicket.request.RequestHandlerStack]
(http--127.0.0.1-8080-1) Error detaching RequestHandler:
java.lang.RuntimeException: Could not deserialize object using:
class
org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
[wicket-core-1.5.5.jar:1.5.5]
at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257
Re: Wicket 1.5.5 + JBoss 7.1.1 + CDI - ClassNotFoundException
Using wicket-cdi https://github.com/42Lines/wicket-cdi the problem still exists. I'll update the example in a moment. On Wed, Apr 11, 2012 at 3:58 PM, James Carman ja...@carmanconsulting.comwrote: I would recommend checking out one of the existing libraries that does Wicket/CDI integration. On Wed, Apr 11, 2012 at 3:54 PM, Jonathan Tougas jtou...@gmail.com wrote: I'm running Wicket 1.5 on JBoss 7.1.1 with some CDI thrown in to the mix. In certain cases when Wicket deserializes a Page containing a reference to a CDI bean, I get this exception: 15:10:30,841 ERROR [org.apache.wicket.request.RequestHandlerStack] (http--127.0.0.1-8080-1) Error detaching RequestHandler: java.lang.RuntimeException: Could not deserialize object using: class org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.PageProvider.getPageParameters(PageProvider.java:184) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.PageLogData.init(PageLogData.java:51) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.init(ListenerInterfaceLogData.java:56) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.detach(ListenerInterfaceRequestHandler.java:134) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:792) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180) [wicket-request-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:596) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) [wicket-core-1.5.5.jar:1.5.5] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) [wicket-core-1.5.5.jar:1.5.5] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.10.Final.jar:] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.10.Final.jar:] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process
Re: AbstractPageableView cachedItemCount
I see your point, the order the components are rendered is important.
I didn't have any trouble getting this to work though: I have a
UserListPage, which has a SizeLabel (whose getModel() =
datatable.getgetItemCount()), and a UserDataTable. The UserListPage listens
for ajax events to add the SizeLabel to AjaxRequestTarget when appropriate.
The components in the AjaxRequestTarget are ordered, and the datatable is
added first since it is the target of the ajax request, so it's
onBeforeRender is called before the label's. The label then correctly picks
up the new size. This case works, more involves ones might not...
So the deeper reason why the rendering order is important is that the
datatable's model is refreshed as a consequence of rendering. It should
probably be done before the rendering even starts, either as part of the
page load, or a click handler. This way, when the rendering phase comes
around, the data is available, and not dependent on the rendering order of
the components.
If ever I run into the problem where the rendering order is problematic
I'll probably try writing up a datatable that can be explicitly refreshed
like this. For now I'm good :)
Thanks for the help! (and Igor thank you for replying to so many user
questions!)
On Thu, Feb 16, 2012 at 12:26 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
suppose you have a label before the data table that shows how many
items are in the table. it uses datatable.getitemcount() to do this.
onbeforerender() will be called on the label before it is on the
datatable so it now uses the stale item count and is out of sync with
the datatable.
-igor
On Thu, Feb 16, 2012 at 9:08 AM, Jonathan Tougas jtou...@gmail.com
wrote:
It should be discarded only before rendering.
I figured out a way to accomplish this by extending the DataTable class
and creating a wrapper for the data provider with a cache of it's own,
which bypasses the AbstractPageableView's size cache. This one is cleared
by the extension of DataTable before rendering like I'm suggesting:
public class SuperTableT extends DataTableT {
private SuperDataProviderWrapperT dataProviderWrapper;
public SuperTable( String id, ListIColumnT columns,
SuperDataProviderWrapperT dataProviderWrapper, int rowsPerPage ) {
super( id, columns, dataProviderWrapper, rowsPerPage );
this.dataProviderWrapper = dataProviderWrapper;
setOutputMarkupId( true );
setVersioned( false );
addTopToolbar( new AjaxNavigationToolbar( this ) );
addTopToolbar( new AjaxFallbackHeadersToolbar( this,
dataProviderWrapper )
);
addBottomToolbar( new NoRecordsToolbar( this ) );
}
@Override
protected ItemT newRowItem( final String id, final int index, final
IModelT model ) {
return new OddEvenItemT( id, index, model );
}
@Override
protected void onBeforeRender() {
// reset size before rendering!
dataProviderWrapper.resetSize();
super.onBeforeRender();
}
}
public class SuperDataProviderWrapperT implements
ISortableDataProviderT {
private ISortableDataProviderT delegate;
private int size;
public SuperDataProviderWrapper( ISortableDataProviderT delegate ) {
this.delegate = delegate;
resetSize();
}
@Override
public int size() {
if( size == -1 ) {
size = delegate.size();
}
return size;
}
public void resetSize() {
size = -1;
}
/*snip delegations...*/
}
End result is one call to count when the ajax links are clicked instead
of
two.
On Wed, Feb 15, 2012 at 7:33 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
so when should it be discarded?
-igor
On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas jtou...@gmail.com
wrote:
The cachedItemCount calculated in onBeforeRender should not be
discarded
at
the end of a request (so the clear in onDetach and readObject
shouldn't
be
there). This way it would still be around when a request comes in to
handle
a click.
On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com
wrote:
Thanks for the clarification. I see your point now: if records are
deleted
from the database, the navigation click is ignored an the page is
simply
re-rendered. But if the data content has changed such that the
navigation
no longer makes sense, what behavior would you prefer?
On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com
wrote:
The PagingNavigationIncrementLink's linksTo(Page), which calls
isLast()
which calls pageable getPageCount() which ends up calling size()
eventually. This is called during
Component.canCallListenerInterface
(*you're
right it's not isVisible*) to verify if the link can indeed be
clicked.
And to be clear I am discussing multiple size() calls in one
request.
It
happens when clicking on the navigation links: size() is called
first
as
part of the verifying if the link is enabled (as described above
Re: AbstractPageableView cachedItemCount
It should be discarded only before rendering.
I figured out a way to accomplish this by extending the DataTable class
and creating a wrapper for the data provider with a cache of it's own,
which bypasses the AbstractPageableView's size cache. This one is cleared
by the extension of DataTable before rendering like I'm suggesting:
public class SuperTableT extends DataTableT {
private SuperDataProviderWrapperT dataProviderWrapper;
public SuperTable( String id, ListIColumnT columns,
SuperDataProviderWrapperT dataProviderWrapper, int rowsPerPage ) {
super( id, columns, dataProviderWrapper, rowsPerPage );
this.dataProviderWrapper = dataProviderWrapper;
setOutputMarkupId( true );
setVersioned( false );
addTopToolbar( new AjaxNavigationToolbar( this ) );
addTopToolbar( new AjaxFallbackHeadersToolbar( this, dataProviderWrapper )
);
addBottomToolbar( new NoRecordsToolbar( this ) );
}
@Override
protected ItemT newRowItem( final String id, final int index, final
IModelT model ) {
return new OddEvenItemT( id, index, model );
}
@Override
protected void onBeforeRender() {
// reset size before rendering!
dataProviderWrapper.resetSize();
super.onBeforeRender();
}
}
public class SuperDataProviderWrapperT implements
ISortableDataProviderT {
private ISortableDataProviderT delegate;
private int size;
public SuperDataProviderWrapper( ISortableDataProviderT delegate ) {
this.delegate = delegate;
resetSize();
}
@Override
public int size() {
if( size == -1 ) {
size = delegate.size();
}
return size;
}
public void resetSize() {
size = -1;
}
/*snip delegations...*/
}
End result is one call to count when the ajax links are clicked instead of
two.
On Wed, Feb 15, 2012 at 7:33 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
so when should it be discarded?
-igor
On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas jtou...@gmail.com
wrote:
The cachedItemCount calculated in onBeforeRender should not be discarded
at
the end of a request (so the clear in onDetach and readObject shouldn't
be
there). This way it would still be around when a request comes in to
handle
a click.
On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com
wrote:
Thanks for the clarification. I see your point now: if records are
deleted
from the database, the navigation click is ignored an the page is simply
re-rendered. But if the data content has changed such that the
navigation
no longer makes sense, what behavior would you prefer?
On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com
wrote:
The PagingNavigationIncrementLink's linksTo(Page), which calls
isLast()
which calls pageable getPageCount() which ends up calling size()
eventually. This is called during Component.canCallListenerInterface
(*you're
right it's not isVisible*) to verify if the link can indeed be
clicked.
And to be clear I am discussing multiple size() calls in one request.
It
happens when clicking on the navigation links: size() is called first
as
part of the verifying if the link is enabled (as described above),
then
the
cached value is discarded just before rendering (in onBeforeRender()).
Then
size() is called again as part of the rendering, and again cached. The
cached value is again discarded at the end of the request in
onDetach().
What I'm saying is the the first size() shouldn't occur because the
page
count should be cached from the previous rendering (it shouldn't be
cleared
in onDetach() nor readObject()).
On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com
wrote:
Hi, Jonathan. Which component are you referring to? I don't see
isVisible()
overrides in PagingNavigator or its helpers.
It's state and as such should not be discarded when
the request is finished, it's still needed for things like
checking
if
a
link was indeed visible when a click comes in for it.
How can you receive a click event for a link that was not visible?
Invisible components aren't rendered.
That JIRA discusses multiple size() calls in a single request.
You're
discussing multiple size() calls with multiple requests. Right?
Dan
On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
wrote:
I noticed two count queries go by when using the DataTable
component.
so
I
searched and dug up this jira issue
https://issues.apache.org/jira/browse/WICKET-1766 which is a
won't
fix.
Igor states that two queries are required each request, but I see
this
differently:
The count is a used as the basis for the paging navigator's
isVisible(),
so
far so good. The issue is that the count is discarded in
onDetach()
(as
well as readObject()). It's state and as such should not be
discarded
when
the request is finished, it's still needed for things like
checking
AbstractPageableView cachedItemCount
I noticed two count queries go by when using the DataTable component. so I searched and dug up this jira issue https://issues.apache.org/jira/browse/WICKET-1766 which is a won't fix. Igor states that two queries are required each request, but I see this differently: The count is a used as the basis for the paging navigator's isVisible(), so far so good. The issue is that the count is discarded in onDetach() (as well as readObject()). It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. If it's not kept, a new query to the model will be made, which might return a different result - consequences ensue. The critical part of that is we are checking if the link *was* visible, not if it *is* visible. I think the only time it should be discarded is in the onBeforeRender() event. This is when we are actually interested in going back to the model to see if the value has changed. So to me this is indeed a bug. I don't mind patching something up myself, or reopening the ticket...but I would like a confirmation that I'm not way out in left field ;) Cheers! Jonathan Tougas
Re: AbstractPageableView cachedItemCount
The PagingNavigationIncrementLink's linksTo(Page), which calls isLast() which calls pageable getPageCount() which ends up calling size() eventually. This is called during Component.canCallListenerInterface (*you're right it's not isVisible*) to verify if the link can indeed be clicked. And to be clear I am discussing multiple size() calls in one request. It happens when clicking on the navigation links: size() is called first as part of the verifying if the link is enabled (as described above), then the cached value is discarded just before rendering (in onBeforeRender()). Then size() is called again as part of the rendering, and again cached. The cached value is again discarded at the end of the request in onDetach(). What I'm saying is the the first size() shouldn't occur because the page count should be cached from the previous rendering (it shouldn't be cleared in onDetach() nor readObject()). On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi, Jonathan. Which component are you referring to? I don't see isVisible() overrides in PagingNavigator or its helpers. It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. How can you receive a click event for a link that was not visible? Invisible components aren't rendered. That JIRA discusses multiple size() calls in a single request. You're discussing multiple size() calls with multiple requests. Right? Dan On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com wrote: I noticed two count queries go by when using the DataTable component. so I searched and dug up this jira issue https://issues.apache.org/jira/browse/WICKET-1766 which is a won't fix. Igor states that two queries are required each request, but I see this differently: The count is a used as the basis for the paging navigator's isVisible(), so far so good. The issue is that the count is discarded in onDetach() (as well as readObject()). It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. If it's not kept, a new query to the model will be made, which might return a different result - consequences ensue. The critical part of that is we are checking if the link *was* visible, not if it *is* visible. I think the only time it should be discarded is in the onBeforeRender() event. This is when we are actually interested in going back to the model to see if the value has changed. So to me this is indeed a bug. I don't mind patching something up myself, or reopening the ticket...but I would like a confirmation that I'm not way out in left field ;) Cheers! Jonathan Tougas
Re: AbstractPageableView cachedItemCount
The cachedItemCount calculated in onBeforeRender should not be discarded at the end of a request (so the clear in onDetach and readObject shouldn't be there). This way it would still be around when a request comes in to handle a click. On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com wrote: Thanks for the clarification. I see your point now: if records are deleted from the database, the navigation click is ignored an the page is simply re-rendered. But if the data content has changed such that the navigation no longer makes sense, what behavior would you prefer? On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com wrote: The PagingNavigationIncrementLink's linksTo(Page), which calls isLast() which calls pageable getPageCount() which ends up calling size() eventually. This is called during Component.canCallListenerInterface (*you're right it's not isVisible*) to verify if the link can indeed be clicked. And to be clear I am discussing multiple size() calls in one request. It happens when clicking on the navigation links: size() is called first as part of the verifying if the link is enabled (as described above), then the cached value is discarded just before rendering (in onBeforeRender()). Then size() is called again as part of the rendering, and again cached. The cached value is again discarded at the end of the request in onDetach(). What I'm saying is the the first size() shouldn't occur because the page count should be cached from the previous rendering (it shouldn't be cleared in onDetach() nor readObject()). On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi, Jonathan. Which component are you referring to? I don't see isVisible() overrides in PagingNavigator or its helpers. It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. How can you receive a click event for a link that was not visible? Invisible components aren't rendered. That JIRA discusses multiple size() calls in a single request. You're discussing multiple size() calls with multiple requests. Right? Dan On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com wrote: I noticed two count queries go by when using the DataTable component. so I searched and dug up this jira issue https://issues.apache.org/jira/browse/WICKET-1766 which is a won't fix. Igor states that two queries are required each request, but I see this differently: The count is a used as the basis for the paging navigator's isVisible(), so far so good. The issue is that the count is discarded in onDetach() (as well as readObject()). It's state and as such should not be discarded when the request is finished, it's still needed for things like checking if a link was indeed visible when a click comes in for it. If it's not kept, a new query to the model will be made, which might return a different result - consequences ensue. The critical part of that is we are checking if the link *was* visible, not if it *is* visible. I think the only time it should be discarded is in the onBeforeRender() event. This is when we are actually interested in going back to the model to see if the value has changed. So to me this is indeed a bug. I don't mind patching something up myself, or reopening the ticket...but I would like a confirmation that I'm not way out in left field ;) Cheers! Jonathan Tougas
Re: refresh and AjaxFallbackDefaultDataTable
Can't you fix that with a getPage().dirty(); in the Ajax request handler? Hmm tried your suggestion, but no luck. How would it help anyway? It's dirty() that is causing the page to change version in the first place right? RefreshingView.onPopulate() - MarkupContainer.removeAll() - Component.addStateChange() - Page.componentStateChanging() - Page.dirty() - new version number! I did find a fix for this though. Changing the rendering strategy from the default REDIRECT_TO_BUFFER to ONE_PASS_RENDER. With this strategy, the initial request is not redirect to *?%version%*, which means when the user presses refresh, a new page is recreated from scratch every time. Ajax updates are applied on the version of the page that originally rendered them, so there's no ambiguity like the scenario I describe. The drawback of course is that page refreshes lose ajax updates, but the semantic in that case at least is very clear and it's what I expected in the first place. On Tue, Feb 14, 2012 at 7:32 AM, Wilhelmsen Tor Iver toriv...@arrive.nowrote: Thus the browser still shows the old version in the URL. But all future Ajax requests are targetting a different page version than visible in the browser URL :(. Can't you fix that with a getPage().dirty(); in the Ajax request handler? - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
refresh and AjaxFallbackDefaultDataTable
I'm getting some inconsistent behavior with AjaxFallbackDefaultDataTable. Here are two scenarios that can be run on wicket-examples: *Scenario 1* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - click the link to navigate to page 2 3 - refresh (F5) After the page refresh, you're still on page 2 - as expected *Scenario 2:* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - refresh (F5) 3 - click the link to navigate to results page 2 4 - refresh (F5) After the page refresh you're back to page 1 - oops The navigation links work fine until the page is refreshed. After a page refresh the navigation links point to the wrong page version (or so it seems), so refreshing a second time doesn't work as expected. I'm fairly new to Wicket so I may be missing something, and I haven't found a bug report for this. Can someone confirm or explain what Im not getting please? Cheers!
