Re: Test failures due to "incorrect" order of attributes
Hi Thanks for clearing this out. I've filed https://issues.apache.org/jira/browse/WICKET-1389 on this. Regards, Henrik Lundahl 2008/3/1, James Carman <[EMAIL PROTECTED]>: > Maybe it should use a TreeMap instead? > > > On 3/1/08, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > > Yes, this is a known issue, because the ordering of HashMaps(?) > > changed in java6 (or something like that). > > > > the tests should pass fine with java5. > > > > Gerolf > > > > On Sat, Mar 1, 2008 at 5:45 PM, Henrik Lundahl <[EMAIL PROTECTED]> > > wrote: > > > > > > > Hi > > > > > > When building wicket-1.3-SNAPSHOT I get some test failures with > > > messages all similar to this: > > > > > > <
Test failures due to "incorrect" order of attributes
Hi When building wicket-1.3-SNAPSHOT I get some test failures with messages all similar to this: <
Re: OutOfMemoryError (not PermGen) in PageSavingThread
Hi One thing you can check is if you have any references (instance variables, possibly implicit) to pages from your component hierarchy. That seems to cause memory leaks in the serialization. I reported a Jira issue about this yesterday (https://issues.apache.org/jira/browse/WICKET-1365). Another thing could of course be that there isn't enough memory to store all the concurrent sessions. If you still run out of memory after increasing the limit with the same load, this shouldn't be it, though. BR, Henrik 2008/2/22, Meetesh Karia <[EMAIL PROTECTED]>: > > Hi all, > > We're getting an OutOfMemoryError (Wicket 1.3.1 on Tomcat 5.5.17 with > Sun JVM 1.5.0_06-b05) in the PageSavingThread occasionally and I was > just wondering if anyone had seen this before. Is it likely just a > side-effect of some other problem in our application? Or is this an > issue with how the pages are written out in wicket. > > Exception in thread "PageSavingThread-wicketFilter" > java.lang.OutOfMemoryError > at sun.misc.Unsafe.allocateMemory(Native Method) > at java.nio.DirectByteBuffer.(DirectByteBuffer.java:99) > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) > at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:56) > at sun.nio.ch.IOUtil.write(IOUtil.java:69) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:651) > at > > org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage > (DiskPageStore.java:246) > at > > org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList > (DiskPageStore.java:885) > at > > org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run > (DiskPageStore.java:948) > > Thanks in advance, > > Meetesh >
Re: Form.getMethod() throws Exception
Hi
The parameters are left out of the request URL in the request that brings
you to the onSubmit method, but the response URL will contain the
PageParameters you set for the MyResponseClass page.
BR,
Henrik Lundahl
2008/2/18, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Hello.
>
> It was just for debugging purposes.
>
> I wanted to see if I used GET or POST. I know from the code that POST is
> used as default (unless stated otherwise in the markup), but I just
> wanted it confirmed.
>
> With my very limited (next to nothing) knowledge about web coding in
> general I thought that when using POST any parameter passed on is not
> shown in the URL. This is however the case when I submit using
>
> ...
> onSubmit(){
> mySumbitButton.setResponsePage(MyResponseClass.class, new
> PageParameters("myKey=myValue"));
> }
> ...
>
>
> Martijn Dashorst skrev:
> > Don't call this method in a constructor. The component isn't added to
> > the page yet, and therefore doesn't know its markup causing it to fail
> > to find the method="foo" tag.
> >
> > Why do you want to call this method in a constructor?
> >
> > Martijn
> >
> > On 2/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> >
> >> Hello all.
> >>
> >> When calling the getMethod from a subclass of a Form component an
> >> exception is thrown.
> >> When looking in the code I see the following comment just before the
> >> exception is thrown in Component.java:
> >> // This should never happen since Page always has associated markup
> >>
> >> If I out comment this call then my app runs like a charm :), so this
> >> looks like a bug to me. Is this a known problem?
> >>
> >> org.apache.wicket.WicketRuntimeException: Unable to find parent with
> associated markup
> >> at org.apache.wicket.Component.findParentWithAssociatedMarkup(
> Component.java:1218)
> >> at org.apache.wicket.MarkupFragmentFinder.find(
> MarkupFragmentFinder.java:50)
> >> at org.apache.wicket.Component.locateMarkupStream(Component.java
> :3614)
> >> at org.apache.wicket.Component.getMarkupAttributes(Component.java
> :1359)
> >> at org.apache.wicket.markup.html.form.Form.getMethod(Form.java
> :1378)
> >> at
> se.jorgenpersson.web.manager.TemplateManagement$ListTemplateForm.(
> TemplateManagement.java:54)
> >> at se.jorgenpersson.web.manager.TemplateManagement.(
> TemplateManagement.java:28)
> >> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> >> at java.lang.Class.newInstance0(Class.java:355)
> >> at java.lang.Class.newInstance(Class.java:308)
> >> at org.apache.wicket.session.DefaultPageFactory.newPage(
> DefaultPageFactory.java:58)
> >> at
> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage
> (BookmarkablePageRequestTarget.java:262)
> >> at
> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage
> (BookmarkablePageRequestTarget.java:283)
> >> at
> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents
> (BookmarkablePageRequestTarget.java:210)
> >> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(
> AbstractRequestCycleProcessor.java:90)
> >> at org.apache.wicket.RequestCycle.processEventsAndRespond(
> RequestCycle.java:1166)
> >> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241)
> >> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316)
> >> at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
> >> at org.apache.wicket.protocol.http.WicketFilter.doGet(
> WicketFilter.java:354)
> >> at org.apache.wicket.protocol.http.WicketServlet.doGet(
> WicketServlet.java:121)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> >> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:290)
> >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
> >> at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:233)
> >> at org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:175)
> >> at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java
Re: Doubt about getList().indexOf() usage in ListView.moveUpLink, moveDownLink, removeLink
Hi
Yes, but why can't ListItem.getIndex() be used? I can't see any
drawbacks, but one advantage is that you can use the same model object
twice in the list. It's not unlikely that I've missed something,
though.
Regards,
Henrik
2008/2/14, Igor Vaynberg <[EMAIL PROTECTED]>:
> you can always roll your own link, you dont have to use the one
> provided with ListView - there is nothing special it does that you
> cannot do yourself. Of course we should have used item.getindex() if
> there was some common interface that all items that were put in list
> had to implement...but since there is no such thing we do the best we
> can without it but leave you plenty of freedom to implement your own.
>
>
> -igor
>
>
>
> On Feb 13, 2008 8:05 PM, Lan Boon Ping <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Taking a look at ListView.moveUpLink as example, I doubt that this
> > getList().indexOf() will return a correct index if we have duplicate
> > items with same identity in getList(). Should not it uses
> > item.getIndex() instead?
> >
> > public final Link moveUpLink(final String id, final ListItem item)
> > {
> > return new Link(id)
> > {
> > private static final long serialVersionUID = 1L;
> >
> > public void onClick()
> > {
> > final int index =
> getList().indexOf(item.getModelObject()); // use
> > item.getIndex() instead?
> >
> > Thank You.
> >
> > Regards
> > Boon Ping
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ModalWindow with Page memory leak
Hi, In my current project we have a page with six AjaxLinks that open different ModalWindows. We had implemented sub-classes of ModalWindow which had field references to the content Pages (the source of the iframes in the ModalWindows) created by ModalWindow.PageCreators. The references were there to extract state from the Pages when the ModalWindows were closed. The Pages also had field references to the ModalWindows in order to call close on them. Using this design, the serialization/deserialization increased seemingly exponentially for every opened and closed ModalWindow, causing a gigantic memory leak. After opening and closing a number of ModalWindows, a single close could consume an additional ~70 MB of memory. Also, in some situations the Page.numericId was zero in Page.writeObject, causing a ClassCastException when the Page field references were deserialized. Since the numericId was zero, the wrong Page (the initial Page) got deserialized. As far as I have been able to understand what's happening, the problems arise because of the cycles between components and the fact that the Pages are deserialized using different ObjectInputStreams. I'm not sure how the numericId could become zero. Removing the references to the content Pages from the ModalWindow sub-classes and using simple Models instead seems to have solved both problems. Questions: What is happening in the serialization/deserialization when this behavior arises? How can the numericId become zero in Page.writeObject (and sub-sequentially in Page.readObject)? Is it generally problematic to have field references to Pages in Components (or objects)? What would the most decoupled approach (object graph wise), thus minimizing serialization, be to implementing this? Thanks, Henrik Lundahl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
