Re: Implications of setRecreateBookmarkablePagesAfterExpiry()
Thank you Martin, here's the Ticket: https://issues.apache.org/jira/browse/WICKET-6182 -Ravi -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Implications-of-setRecreateBookmarkablePagesAfterExpiry-tp4674899p4674922.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: Implications of setRecreateBookmarkablePagesAfterExpiry()
Hi, I don't see how you could work around this. But I think we could remove the check at org.apache.wicket.Component#createRequestHandler(). I think it is fine to render urls with the page mount path in them. org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper#processHybrid() is responsible to throw PageExpiredException when needed. I've just tried this change and I see that two unit tests are failing, but in my opinion they should pass. Please create a ticket and we will investigate deeper! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Jun 15, 2016 at 12:39 PM, Ravi wrote: > Hi all, > > I have an application where I set cookies with the app's context + > mountedPageUrl as the cookie's path. > Something like this: 'wicket-sandbox/pageA' > > Work's fine out of the box. > Now I want to have a SessionExpiredPage. > According to this https://issues.apache.org/jira/browse/WICKET-4014 I > simply > have to set setRecreateBookmarkablePagesAfterExpiry(false). > > But now all of my Ajax-/Listener-URLs don't use their mounted page URLs > anymore, but a generic 'wicket/page'. > > So before, they look like: > > http://localhost:8081/wicket-sandbox/pageA?2-1.IBehaviorListener.0-increment&_=1465988637772 > Now they look like: > > http://localhost:8081/wicket-sandbox/wicket/page?1-1.IBehaviorListener.0-increment&_=1465988144642 > > So it is not possible to get or differentiate between the cookies. > > I tried debugging it, but I do not see where I can change this behavior > because at the point where the application decides on which > IPageRequestHandler to use (/see Component.class, method > createRequestHandler(RequestListenerInterface listener, PageParameters > parameters, Integer id)/), > it does query the getRecreateBookmarkablePagesAfterExpiry() method (which > returns false) and uses a ListenerInterfaceRequestHandler instead of an > BookmarkableListenerInterfaceRequestHandler. > > Any ideas on how I can get this working? > > Kind regards, > > Ravi > > I am using wicket 7.2.0 > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Implications-of-setRecreateBookmarkablePagesAfterExpiry-tp4674899.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-guice and recursive injection of non serializable JPA2 objects
Hi Dieter,
Which version of wicket are you using? (I ask since I see you are using
onBeforeRender() to initialize your components, while since wicket 1.5
there is onInitialize() for that in each component).
For as far as I can see there are no references to your dao in the gist you
provided; However, since it is serialized somewhere in the component tree,
it could be in one of the smaller components used in your PersonenTable
page.
In any case, your page (or a component inside it) has a reference to your
dao.
Since I’ve seen this a lot when I started using wicket, please check if you
are referencing your dao somewhere inside an anonymous inner class /
component.
E.g.:
public Component createMyComponent(String id) {
DAO dao = getDaoFromPageOrElsewhere();
return new AjaxLink(id) {
public void onClick(AjaxRequestTarget target) {
// This is where an instance of DAO will get serialized into the component
tree!
dao.performAction();
}
}
}
Rewrite such code (if you have it) to look up the DAO reference at the time
you actually need it:
public void onClick(AjaxRequestTarget target) {
DAO dao = getDaoFromPageOrElsewhere();
dao.performAction();
}
My guess is that you’ll find the culprit by simply looking at all places in
your code where you use the PersonenDao.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de)
schreef:
Hello Martin,
it is:
personenProvider = (com.sun.proxy.$Proxy24)
org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea
wrapInProxies is true
I added a SignIn mechanism, SignInSession uses PersonenDao too to
authorize in the database. But I checked not to have any references to
it, that could be serialized. I added more of this this part to the gist:
https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
Dieter
Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> Hi,
>
> Put a breakpoint at PersonenTable constructor and see what is the type of
'
> personenProvider'.
> It must be JDK Proxy instance.
> If it is not then something wrong is going on.
>
>
org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
> com.google.inject.Injector, boolean) - the last parameter here is
> 'wrapInProxies'. It must be 'true'.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel
> wrote:
>
>> Hi Bas,
>>
>> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>>
>> I fear it is not really useful, since it starts with
>>
>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> trying to collect debug information about not serializable object
>>
>> Dieter
>>
>> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
>>> Hi Dieter,
>>>
>>> Can you share the stack trace of the serialization checker error?
>>> Normally it points out where in the hierarchy it found a
>>> non-serializable object.
>>> My first guess is that you are referencing the dao class somewhere
>>> directly from your page. The stack trace will prove me right or wrong
:-)
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas Gooren
>>>
>>> Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
>>> ) schreef:
>>>
Hello Bas,
I try to cut small pieces of the code, please tell me if you want to
see
more.
First the error:
12:59:03.919 [http-nio-8084-exec-6] WARN
o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
writeObject :
>>
de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,
path: /children
12:59:03.925 [http-nio-8084-exec-6] ERROR
o.a.w.serialize.java.JavaSerializer - Error serializing object class
de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count =
1]]
org.apache.wicket.WicketRuntimeException: A problem occurred while
trying to collect debug information about not serializable object
at
>>
org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)
public class PersonenTable extends BasePage {
@Inject
private ICachingAbiDataProvider personenProvider;
...
}
public class AbstractProvider extends
SortableDataProvider implements IAbiDataProvider {
@Inject
private ReadOnlyDao dao;
...
}
public abstract class JPAReadOnlyDao implements
ReadOnlyDao {
private Provider emProvider;
private final Class entityClass;
public JPAReadOnlyDao(Class entityClass) {
this.entityClass = entityClass;
}
...
@Inject
public void setEntityManagerProvider(Provider
emProvider) {
this.emProvider = emProv
Re: Rendering performance
Ok, that might have something to do with it! :-D Thanks! 2016-06-16 16:21 GMT+02:00 Martin Grigorov : > The models and data providers are asked for their data at render time. > Once the final data is available Wicket starts populating the HTML markup > with it. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 4:17 PM, Lars Törner > wrote: > > > Hi Martin, > > > > we use wicket 6.22. > > > > Doesn't the rendering take place when everything else is done? I.e the > > wicket components are already created and populated with data when the > > rendering phase starts. I guess I have to dig a bit deeper... anyway, > > thanks for your quick answers! > > > > Lasse > > > > 2016-06-16 15:47 GMT+02:00 Martin Grigorov : > > > > > Also it could be similar to > > > https://issues.apache.org/jira/browse/WICKET-6177. > > > There the user also has a lot of components in the tree and this takes > > time > > > at page serialization time. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov > > > > wrote: > > > > > > > Hi Lasse, > > > > > > > > Which version of Wicket do you use ? > > > > > > > > I think you will have to use a profiler to see where the times is > > spent. > > > > It could be Wicket, but also it could be the application spending a > lot > > > of > > > > time while loading the data which should be rendered. > > > > > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> we have an issue with rendering performance and I wonder if there > are > > > any > > > >> common misusages of wicket when it comes to this. > > > >> > > > >> When rendering a fully expanded tree with 160 top level nodes and > > mostly > > > >> no > > > >> subtrees (an expanded node is a forms with a bunch of labels and > > > >> attributes) it takes about 20 seconds for the page to load (actually > > > it's > > > >> an Ajax request) and it seems that most of this time is spent when > > > wicket > > > >> renders the components. > > > >> > > > >> For one ot these 160 nodes, which has some sub nodes and forms, > > > rendering > > > >> takes about half a second. > > > >> > > > >> I'm using the RenderPerformanceListener from wicket-devutils to do > the > > > >> measuring and gets, for the entire expanded tree, over 22 000 > > > >> "afterRender" > > > >> rows in the log from the RenderPerformanceListener. > > > >> This is in my opinion a huge number! > > > >> > > > >> - is it expected that rendering of so many components takes this > > amount > > > of > > > >> time? > > > >> - is this amount a sign of that we are using wicket in the wrong > way? > > > >> > > > >> > > > >> Don't know if this makes any sense to anyone but this is the last > > lines > > > of > > > >> the log output for one of the top level nodes: > > > >> > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > > > >> for 0ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > > > >> for 0ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > > > >> for 0ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > > > >> for 1ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > > > >> for 2ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > > > >> for 2ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyCon
Re: Rendering performance
The models and data providers are asked for their data at render time. Once the final data is available Wicket starts populating the HTML markup with it. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 4:17 PM, Lars Törner wrote: > Hi Martin, > > we use wicket 6.22. > > Doesn't the rendering take place when everything else is done? I.e the > wicket components are already created and populated with data when the > rendering phase starts. I guess I have to dig a bit deeper... anyway, > thanks for your quick answers! > > Lasse > > 2016-06-16 15:47 GMT+02:00 Martin Grigorov : > > > Also it could be similar to > > https://issues.apache.org/jira/browse/WICKET-6177. > > There the user also has a lot of components in the tree and this takes > time > > at page serialization time. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov > > wrote: > > > > > Hi Lasse, > > > > > > Which version of Wicket do you use ? > > > > > > I think you will have to use a profiler to see where the times is > spent. > > > It could be Wicket, but also it could be the application spending a lot > > of > > > time while loading the data which should be rendered. > > > > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner > > > wrote: > > > > > >> Hi, > > >> > > >> we have an issue with rendering performance and I wonder if there are > > any > > >> common misusages of wicket when it comes to this. > > >> > > >> When rendering a fully expanded tree with 160 top level nodes and > mostly > > >> no > > >> subtrees (an expanded node is a forms with a bunch of labels and > > >> attributes) it takes about 20 seconds for the page to load (actually > > it's > > >> an Ajax request) and it seems that most of this time is spent when > > wicket > > >> renders the components. > > >> > > >> For one ot these 160 nodes, which has some sub nodes and forms, > > rendering > > >> takes about half a second. > > >> > > >> I'm using the RenderPerformanceListener from wicket-devutils to do the > > >> measuring and gets, for the entire expanded tree, over 22 000 > > >> "afterRender" > > >> rows in the log from the RenderPerformanceListener. > > >> This is in my opinion a huge number! > > >> > > >> - is it expected that rendering of so many components takes this > amount > > of > > >> time? > > >> - is this amount a sign of that we are using wicket in the wrong way? > > >> > > >> > > >> Don't know if this makes any sense to anyone but this is the last > lines > > of > > >> the log output for one of the top level nodes: > > >> > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > > >> for 1ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > > >> for 2ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > > >> for 2ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' > > >> for 26ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSectio
Re: Rendering performance
Hi Martin, we use wicket 6.22. Doesn't the rendering take place when everything else is done? I.e the wicket components are already created and populated with data when the rendering phase starts. I guess I have to dig a bit deeper... anyway, thanks for your quick answers! Lasse 2016-06-16 15:47 GMT+02:00 Martin Grigorov : > Also it could be similar to > https://issues.apache.org/jira/browse/WICKET-6177. > There the user also has a lot of components in the tree and this takes time > at page serialization time. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov > wrote: > > > Hi Lasse, > > > > Which version of Wicket do you use ? > > > > I think you will have to use a profiler to see where the times is spent. > > It could be Wicket, but also it could be the application spending a lot > of > > time while loading the data which should be rendered. > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner > > wrote: > > > >> Hi, > >> > >> we have an issue with rendering performance and I wonder if there are > any > >> common misusages of wicket when it comes to this. > >> > >> When rendering a fully expanded tree with 160 top level nodes and mostly > >> no > >> subtrees (an expanded node is a forms with a bunch of labels and > >> attributes) it takes about 20 seconds for the page to load (actually > it's > >> an Ajax request) and it seems that most of this time is spent when > wicket > >> renders the components. > >> > >> For one ot these 160 nodes, which has some sub nodes and forms, > rendering > >> takes about half a second. > >> > >> I'm using the RenderPerformanceListener from wicket-devutils to do the > >> measuring and gets, for the entire expanded tree, over 22 000 > >> "afterRender" > >> rows in the log from the RenderPerformanceListener. > >> This is in my opinion a huge number! > >> > >> - is it expected that rendering of so many components takes this amount > of > >> time? > >> - is this amount a sign of that we are using wicket in the wrong way? > >> > >> > >> Don't know if this makes any sense to anyone but this is the last lines > of > >> the log output for one of the top level nodes: > >> > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > >> for 1ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' > >> for 26ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' > >> for 27ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' > >> for 27ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' > >> for 27ms > >> > >> > 'mainContent:
Re: Rendering performance
Also it could be similar to https://issues.apache.org/jira/browse/WICKET-6177. There the user also has a lot of components in the tree and this takes time at page serialization time. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov wrote: > Hi Lasse, > > Which version of Wicket do you use ? > > I think you will have to use a profiler to see where the times is spent. > It could be Wicket, but also it could be the application spending a lot of > time while loading the data which should be rendered. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner > wrote: > >> Hi, >> >> we have an issue with rendering performance and I wonder if there are any >> common misusages of wicket when it comes to this. >> >> When rendering a fully expanded tree with 160 top level nodes and mostly >> no >> subtrees (an expanded node is a forms with a bunch of labels and >> attributes) it takes about 20 seconds for the page to load (actually it's >> an Ajax request) and it seems that most of this time is spent when wicket >> renders the components. >> >> For one ot these 160 nodes, which has some sub nodes and forms, rendering >> takes about half a second. >> >> I'm using the RenderPerformanceListener from wicket-devutils to do the >> measuring and gets, for the entire expanded tree, over 22 000 >> "afterRender" >> rows in the log from the RenderPerformanceListener. >> This is in my opinion a huge number! >> >> - is it expected that rendering of so many components takes this amount of >> time? >> - is this amount a sign of that we are using wicket in the wrong way? >> >> >> Don't know if this makes any sense to anyone but this is the last lines of >> the log output for one of the top level nodes: >> >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' >> for 1ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' >> for 2ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' >> for 2ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' >> for 26ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' >> for 27ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' >> for 27ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' >> for 27ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' >> for 28ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' >> for 29ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree
Re: Rendering performance
Hi Lasse, Which version of Wicket do you use ? I think you will have to use a profiler to see where the times is spent. It could be Wicket, but also it could be the application spending a lot of time while loading the data which should be rendered. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner wrote: > Hi, > > we have an issue with rendering performance and I wonder if there are any > common misusages of wicket when it comes to this. > > When rendering a fully expanded tree with 160 top level nodes and mostly no > subtrees (an expanded node is a forms with a bunch of labels and > attributes) it takes about 20 seconds for the page to load (actually it's > an Ajax request) and it seems that most of this time is spent when wicket > renders the components. > > For one ot these 160 nodes, which has some sub nodes and forms, rendering > takes about half a second. > > I'm using the RenderPerformanceListener from wicket-devutils to do the > measuring and gets, for the entire expanded tree, over 22 000 "afterRender" > rows in the log from the RenderPerformanceListener. > This is in my opinion a huge number! > > - is it expected that rendering of so many components takes this amount of > time? > - is this amount a sign of that we are using wicket in the wrong way? > > > Don't know if this makes any sense to anyone but this is the last lines of > the log output for one of the top level nodes: > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > for 1ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > for 2ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > for 2ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' > for 26ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' > for 28ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' > for 29ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component' > for 29ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content' > for 36ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node' > for 36ms > > > 'mainContent:detailViewer:detailAndSi
Rendering performance
Hi, we have an issue with rendering performance and I wonder if there are any common misusages of wicket when it comes to this. When rendering a fully expanded tree with 160 top level nodes and mostly no subtrees (an expanded node is a forms with a bunch of labels and attributes) it takes about 20 seconds for the page to load (actually it's an Ajax request) and it seems that most of this time is spent when wicket renders the components. For one ot these 160 nodes, which has some sub nodes and forms, rendering takes about half a second. I'm using the RenderPerformanceListener from wicket-devutils to do the measuring and gets, for the entire expanded tree, over 22 000 "afterRender" rows in the log from the RenderPerformanceListener. This is in my opinion a huge number! - is it expected that rendering of so many components takes this amount of time? - is this amount a sign of that we are using wicket in the wrong way? Don't know if this makes any sense to anyone but this is the last lines of the log output for one of the top level nodes: 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' for 26ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' for 28ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree:branches' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8' for 37ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches' for 340ms 'main
Re: Generate css from less for package resources at runtime.
Hi Martin, many thanks for your efforts! Unfortunately this isn't a priority for our team at the moment. I'll get back to you if/when we dig deeper into this matter. Cheers Lasse 2016-06-08 22:04 GMT+02:00 Martin Grigorov : > HI Lasse, > > I've checked again Wicket Bootstrap code and I see that it works only with > LessSource$URLSource class which have lastModifiedDate. > I'll need more info (or a demo app) how exactly you use StringSource so I > can think for improvement. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, May 30, 2016 at 4:38 PM, Martin Grigorov > wrote: > > > Hi Lasse, > > > > > > > https://github.com/SomMeri/less4j/blob/master/src/main/java/com/github/sommeri/less4j/LessSource.java#L365 > > > > StringSource doesn't have get/set lastModifiedDate. > > I can add a specialization of this class in Wicket Bootstrap Less project > > and make use of it while calculating the last modified for a LessSource > and > > all its imports. > > Then the application should use my version instead of the Less4j one. > > If you think this is a good solution then please open an issue at > > https://github.com/l0rdn1kk0n/wicket-bootstrap/ > > A Pull Request will be awesome! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, May 25, 2016 at 3:54 PM, Lars Törner > > wrote: > > > >> Hi Martin, Bas and others! > >> > >> Unfortunately I got one crucial thing wrong when I described our > scenario. > >> > >> "A less-variable (put in a separate file) gets a new value." > >> > >> This is not the case, the variable is changed in code and not in a file. > >> This means that even though we have changed a less variable and > >> regenerated > >> the css, the less files themselves has not changed (no new modification > >> time), and therefore the problem we have arises. > >> > >> To touch the css-file might be a work around, but it seems kind of a > >> strange way to handle things. > >> > >> Cheers > >> Lasse > >> > >> 2016-05-25 12:35 GMT+02:00 Bas Gooren : > >> > >> > Lars, Martin, > >> > > >> > > >> > Sorry for hijacking this thread (sort of). > >> > > >> > > >> > Hmmm, I am 100% sure it was not working for us in a web app we > currently > >> > have running. > >> > > >> > I just checked which version of wicket-bootstrap-less it uses (version > >> > 0.9.11), and that version already has the recursive check on the > >> > last-modified time of imported sources. > >> > > >> > > >> > I’ll try to do some debugging to see if it really is not working, and > if > >> > that’s the case: why it’s not working. > >> > > >> > Met vriendelijke groet, > >> > Kind regards, > >> > > >> > Bas Gooren > >> > > >> > Op 24 mei 2016 bij 20:25:52, Lars Törner (lars.tor...@gmail.com) > >> schreef: > >> > > >> > Thanks Martin, I'll take a look at it! > >> > > >> > tisdag 24 maj 2016 skrev Martin Grigorov : > >> > > >> > > Hi, > >> > > > >> > > I checked the code last night and I believe this use case should be > >> > covered > >> > > by > >> > > > >> > > > >> > > >> > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/a64af20bcd65f365dbd487c7480db441fd6b6489/bootstrap-less/src/main/java/de/agilecoders/wicket/less/LessCacheManager.java#L156 > >> > > It uses Less4j's APIs to get all imported resources recursively and > >> > > extracts the latest modification time. > >> > > > >> > > > >> > > Martin Grigorov > >> > > Wicket Training and Consulting > >> > > https://twitter.com/mtgrigorov > >> > > > >> > > On Wed, May 18, 2016 at 3:17 PM, Lars Törner >> > > > wrote: > >> > > > >> > > > Thanks, we'll try this! > >> > > > > >> > > > Cheers > >> > > > Lasse > >> > > > > >> > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren >: > >> > > > > >> > > > > Hi all, > >> > > > > > >> > > > > We’ve encountered this issue, too; Simple fix is to touch the > less > >> > > file, > >> > > > > even when a secondary file was the only change. > >> > > > > > >> > > > > The root cause is simple: wicket is not aware of any includes in > >> the > >> > > less > >> > > > > file, and as such only looks at the “parent” less file to see if > >> it > >> > was > >> > > > > changed. A potential way to fix this is to make it more > >> intelligent, > >> > > > > assuming the less compiler can expose such details (referenced > >> > files, > >> > > > > last-modified time of those files). > >> > > > > > >> > > > > Met vriendelijke groet, > >> > > > > Kind regards, > >> > > > > > >> > > > > Bas Gooren > >> > > > > > >> > > > > Op 18 mei 2016 bij 13:06:59, Martin Grigorov ( > >> mgrigo...@apache.org > >> > > ) > >> > > > > schreef: > >> > > > > > >> > > > > Hi Lasse, > >> > > > > > >> > > > > I'll take a look in the coming days! > >> > > > > > >> > > > > Martin Grigorov > >> > > > > Wicket Training and Consulting > >> > > > > https://twitter.com/mtgrigorov > >> > > > > > >> > > > > On Wed, May 18, 2016 at 11:43 AM, Lars Törner < > >> lars.tor...@gmail.com > >> > > > > >> > > > > wrote: >
Re: stop wicket from rewriting references in my css file
Hi, If you don't add the CssUrlReplacer manually it is not active by default. If URLs are replaced into Reference URLs it might be a manually added CssUrlReplacer. If you don't want that some of the URLs are replaced you can consider to add them into a different CSS file and add the name of the file to the excludes of the CssUrlReplacer. kind regards Tobias > Am 16.06.2016 um 08:12 schrieb nino martinez wael > : > > Ok it looks like it could be something like that. BUT,i've changed > nothing from stock options. Could that be enabled by default in 6.22 . > Other option of course are that it is because of something in pax > wicket.. I'll go check. > >> On Wed, Jun 15, 2016 at 1:15 PM, Bas Gooren wrote: >> Sounds like you have enabled the css compressor / rewriter. By default it is >> off. >> >> This assumes that you are letting wicket handle the css (which you do, as >> you mention it is a shared resource). >> >> You are looking for Application#getResourceSettings() and >> (I)ResourceSettings#(get|set)CssCompressor(). >> It sounds like it is currently set to an instance of CssUrlReplacer in your >> app, as that rewrites all references in CSS. >> >> Met vriendelijke groet, >> Kind regards, >> >> Bas Gooren >> >> Op 15 juni 2016 bij 12:11:12, nino martinez wael >> (nino.martinez.w...@gmail.com) schreef: >> >> Hi >> >> I currently have an issue where I add a shared css resource, but >> wicket rewrites all references in the resource. I can't seem to find >> the setting to turn of that part of wickets processing? >> >> -- >> Best regards / Med venlig hilsen >> Nino Martinez >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org > > > > -- > Best regards / Med venlig hilsen > Nino Martinez > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
