[jira] Updated: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Igor Vaynberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-3112:
--

Priority: Major  (was: Blocker)

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3098) AjaxEventBehavior#onEvent is invoked on disabled behavior

2010-10-18 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922350#action_12922350
 ] 

Hudson commented on WICKET-3098:


Integrated in Apache Wicket 1.5.x #419 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/419/])
Issue: WICKET-3098


> AjaxEventBehavior#onEvent is invoked on disabled behavior
> -
>
> Key: WICKET-3098
> URL: https://issues.apache.org/jira/browse/WICKET-3098
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.9
>Reporter: Stanislav Dvorscak
>Assignee: Igor Vaynberg
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: BehaviorRequestTarget.java.patch, patch.txt
>
>
> Security bug  AjaxEventBehavior#onEvent is invoked on disabled behavior. It 
> should not be - it is really dangerous, can you fix it.
> I think it is security bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (WICKET-3116) class cast exception

2010-10-18 Thread dgherrig (JIRA)
class cast exception


 Key: WICKET-3116
 URL: https://issues.apache.org/jira/browse/WICKET-3116
 Project: Wicket
  Issue Type: Bug
  Components: wicket-portlet
Affects Versions: 1.4.10
 Environment: running on windows
Reporter: dgherrig


Below is the exception I am getting when doing "setResponse( 
myPage(some_value)" in my code.

I downloaded the src and in WicketPortlet.java at line 676::


changed:   (RenderResponse)response).reset();

to:response.reset();

rebuilt and tested again and this fixed the problem.


I believe this is related to running wicket in the jetspeed portal and 
conflicts with pluto 2.0 which uses the clean room jars of javax.

The casting is not necessary.


java.lang.ClassCastException: 
org.apache.pluto.container.impl.ResourceResponseImpl cannot be cast to 
javax.portlet.RenderResponse
at 
org.apache.wicket.protocol.http.portlet.WicketPortlet.processMimeResponseRequest(WicketPortlet.java:676)
at 
org.apache.wicket.protocol.http.portlet.WicketPortlet.processRequest(WicketPortlet.java:608)
at 
org.apache.wicket.protocol.http.portlet.WicketPortlet.serveResource(WicketPortlet.java:536)
at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.jetspeed.portlet.PortletObjectProxy.invoke(PortletObjectProxy.java:181)
at $Proxy91.serveResource(Unknown Source)
at 
org.apache.jetspeed.factory.JetspeedPortletInstance.serveResource(JetspeedPortletInstance.java:139)
at 
org.apache.jetspeed.container.services.JetspeedFilterChain.doFilter(JetspeedFilterChain.java:157)
at 
org.apache.jetspeed.container.services.JetspeedFilterChain.processFilter(JetspeedFilterChain.java:78)
at 
org.apache.jetspeed.container.services.JetspeedFilterManager.processFilter(JetspeedFilterManager.java:117)
at 
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:161)
at 
org.apache.jetspeed.container.invoker.JetspeedPortletInvokerService.serveResource(JetspeedPortletInvokerService.java:136)
at 
org.apache.pluto.container.impl.PortletContainerImpl.doServeResource(PortletContainerImpl.java:203)
at 
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.doServeResource(JetspeedPortletContainerWrapper.java:93)
at 
org.apache.jetspeed.resource.ResourceValveImpl.invoke(ResourceValveImpl.java:69)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:139)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:88)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.container.PageHistoryValve.invoke(PageHistoryValve.java:108)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.profiler.impl.RefreshUserHomepageValveImpl.invoke(RefreshUserHomepageValveImpl.java:114)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.pipeline.valve.impl.AbstractPageValveImpl.invoke(AbstractPageValveImpl.java:169)
at 
org.apache.jetspeed.pipeline.valve.impl.PageProfilerValveImpl.invoke(PageProfilerValveImpl.java:59)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:242)
at 
org.apache.jetspeed.security.impl.LoginValidationValveImpl.invoke(LoginValidationValveImpl.java:158)
at 
org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invo

[jira] Closed: (WICKET-1633) Wicket contributions

2010-10-18 Thread Igor Vaynberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/WICKET-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg closed WICKET-1633.
-

Resolution: Not A Problem
  Assignee: Igor Vaynberg  (was: Alastair Maw)

> Wicket contributions
> 
>
> Key: WICKET-1633
> URL: https://issues.apache.org/jira/browse/WICKET-1633
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket, wicket-guice
>Affects Versions: 1.4-M1
> Environment: Any
>Reporter: Mathieu Carbou
>Assignee: Igor Vaynberg
>Priority: Minor
>
> Hi,
> I don't know if it is the right place to post this ;) So here is the request:
> We wanted to use wicket with Guice, but we found some limitations in the 
> source code and Guice integration. So i decided to extract all the classes i 
> developped in a project : wicket-contrib at 
> http://code.google.com/p/wicket-contrib/.  You can find all the improved 
> wicket classes with a user guide explaining how to use the changes, but i 
> hardly suggest you checkout the code base, issue a mvn idea:idea and run the 
> sample webapps as described in the user guide.
> Here is the list of our concerns:
> 1 - we wanted to have the minimal configuration to do - using Convention 
> Over Configuration, but still be able to customize as wee need
> 2 - we wanted to be able to use a ReloadableClassloader when testing 
> mutliple wicket apps in the same webapp
> 3 - we wanted to have a real simple way to use Guice with wicket
> 4 - we wanted to have Guice features provided, like the ability to use 
> scope bindings (request, session, flash), and also the ability to integration 
> easily WARP modules for persistence, security, ... from 
> http://www.wideplay.com/
> 5 - we wanted to use wicket testing features without junit but with 
> TestNG and also with Guice integration
> We found some limitations in the current code base of wicket (1.4-SNAPSHOT):
> 1 - Too many configurations in the web.xml file 
> 2 - Must provide a WebApplication
> 3 - Must change the filter if we want to use reloadable classloader
> 4 - ReloadableClassloader has static configuration, which prevents using 
> it in a web.xml file that contains several wicket applications
> 5 - Guice integration is very limited - no scopes bindings, cannot inject 
> HttpSession, request and response to classes, ...
> 6 - WicketTester is completely binded to Junit, 
> 7 - The way WicketTester has been developped, with many inheritances, 
> makes it very difficult to extend and provide different behavior. I.e, when 
> we enhanced the wicket tester, we wanted to provide our proper 
> WicketApplication already configured through our filter. But the 
> MockWebApplication class has no constructor that simply take has argument a 
> configured - ready to use WebApplication (it recreate a filter, etc...)
> So this issue is much more a improvement request: wicket-contrib code could 
> be taken / modified / integrated in Wicket code base to improve Guice 
> support, testing features, and also to fix issues about reloading 
> classloader, wicket tester binded to junit, ...
> Hope it will help !
> Mathieu.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3098) AjaxEventBehavior#onEvent is invoked on disabled behavior

2010-10-18 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922343#action_12922343
 ] 

Igor Vaynberg commented on WICKET-3098:
---

fxed, thanks.

> AjaxEventBehavior#onEvent is invoked on disabled behavior
> -
>
> Key: WICKET-3098
> URL: https://issues.apache.org/jira/browse/WICKET-3098
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.9
>Reporter: Stanislav Dvorscak
>Assignee: Igor Vaynberg
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: BehaviorRequestTarget.java.patch, patch.txt
>
>
> Security bug  AjaxEventBehavior#onEvent is invoked on disabled behavior. It 
> should not be - it is really dangerous, can you fix it.
> I think it is security bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1024056 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/RequestListenerInterface.java test/java/org/apache/wicket/BehaviorRequestTest.java

2010-10-18 Thread ivaynberg
Author: ivaynberg
Date: Mon Oct 18 22:59:28 2010
New Revision: 1024056

URL: http://svn.apache.org/viewvc?rev=1024056&view=rev
Log:

Issue: WICKET-3098

Added:

wicket/trunk/wicket/src/test/java/org/apache/wicket/BehaviorRequestTest.java   
(with props)
Modified:

wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestListenerInterface.java

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestListenerInterface.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestListenerInterface.java?rev=1024056&r1=1024055&r2=1024056&view=diff
==
--- 
wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestListenerInterface.java
 (original)
+++ 
wicket/trunk/wicket/src/main/java/org/apache/wicket/RequestListenerInterface.java
 Mon Oct 18 22:59:28 2010
@@ -255,6 +255,7 @@ public class RequestListenerInterface
{
log.warn("behavior not enabled; ignore call. Behavior 
{} at component {}", behavior,
component);
+   return;
}
 
try

Added: 
wicket/trunk/wicket/src/test/java/org/apache/wicket/BehaviorRequestTest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/BehaviorRequestTest.java?rev=1024056&view=auto
==
--- 
wicket/trunk/wicket/src/test/java/org/apache/wicket/BehaviorRequestTest.java 
(added)
+++ 
wicket/trunk/wicket/src/test/java/org/apache/wicket/BehaviorRequestTest.java 
Mon Oct 18 22:59:28 2010
@@ -0,0 +1,131 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket;
+
+import junit.framework.TestCase;
+
+import org.apache.wicket.behavior.AbstractBehavior;
+import org.apache.wicket.behavior.IBehavior;
+import org.apache.wicket.behavior.IBehaviorListener;
+import org.apache.wicket.markup.ComponentTag;
+import org.apache.wicket.markup.IMarkupResourceStreamProvider;
+import org.apache.wicket.markup.html.WebMarkupContainer;
+import org.apache.wicket.markup.html.WebPage;
+import org.apache.wicket.request.handler.ListenerInterfaceRequestHandler;
+import org.apache.wicket.request.handler.PageAndComponentProvider;
+import org.apache.wicket.util.resource.IResourceStream;
+import org.apache.wicket.util.resource.StringResourceStream;
+import org.apache.wicket.util.tester.WicketTester;
+
+
+/**
+ * @see https://issues.apache.org/jira/browse/WICKET-3098
+ */
+public class BehaviorRequestTest extends TestCase
+{
+   private WicketTester tester;
+   private TestPage page;
+
+   @Override
+   protected void setUp() throws Exception
+   {
+   tester = new WicketTester();
+   page = new TestPage();
+   tester.startPage(page);
+   }
+
+   public void testEnabledBehaviorRequest()
+   {
+   tester.executeUrl(urlForBehavior(page.enabledBehavior));
+   assertTrue(page.enabledBehavior.isCalled());
+   }
+
+   public void testDisabledBehaviorRequest()
+   {
+   tester.executeUrl(urlForBehavior(page.disabledBehavior));
+   assertTrue(!page.disabledBehavior.isCalled());
+   }
+
+   private String urlForBehavior(IBehavior behaviorUnderTest)
+   {
+   int index = 
page.container.getBehaviorsRawList().indexOf(behaviorUnderTest);
+   String enabledBehaviorUrl = tester.urlFor(
+   new ListenerInterfaceRequestHandler(new 
PageAndComponentProvider(page, page.container),
+   IBehaviorListener.INTERFACE, index)).toString();
+   return enabledBehaviorUrl;
+   }
+
+   public static class TestPage extends WebPage implements 
IMarkupResourceStreamProvider
+   {
+   private WebMarkupContainer container;
+   private TestCallbackBehavior enabledBehavior;
+   private TestCallbackBehavior disabledBehavior;
+
+   public TestPage()
+   {
+   enabledBehavior = new TestCallbackBehavior();
+ 

[jira] Commented: (WICKET-1633) Wicket contributions

2010-10-18 Thread Mathieu Carbou (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922311#action_12922311
 ] 

Mathieu Carbou commented on WICKET-1633:


Hi,

I think this can be closed: this was a mere essay to put convention over 
configuration with some other features but since Wicket has greatly improved 
since these are unecessary. The google code project is no used since a lot of 
time and I also miss time to update it.

Thanks a lot !


> Wicket contributions
> 
>
> Key: WICKET-1633
> URL: https://issues.apache.org/jira/browse/WICKET-1633
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket, wicket-guice
>Affects Versions: 1.4-M1
> Environment: Any
>Reporter: Mathieu Carbou
>Assignee: Alastair Maw
>Priority: Minor
>
> Hi,
> I don't know if it is the right place to post this ;) So here is the request:
> We wanted to use wicket with Guice, but we found some limitations in the 
> source code and Guice integration. So i decided to extract all the classes i 
> developped in a project : wicket-contrib at 
> http://code.google.com/p/wicket-contrib/.  You can find all the improved 
> wicket classes with a user guide explaining how to use the changes, but i 
> hardly suggest you checkout the code base, issue a mvn idea:idea and run the 
> sample webapps as described in the user guide.
> Here is the list of our concerns:
> 1 - we wanted to have the minimal configuration to do - using Convention 
> Over Configuration, but still be able to customize as wee need
> 2 - we wanted to be able to use a ReloadableClassloader when testing 
> mutliple wicket apps in the same webapp
> 3 - we wanted to have a real simple way to use Guice with wicket
> 4 - we wanted to have Guice features provided, like the ability to use 
> scope bindings (request, session, flash), and also the ability to integration 
> easily WARP modules for persistence, security, ... from 
> http://www.wideplay.com/
> 5 - we wanted to use wicket testing features without junit but with 
> TestNG and also with Guice integration
> We found some limitations in the current code base of wicket (1.4-SNAPSHOT):
> 1 - Too many configurations in the web.xml file 
> 2 - Must provide a WebApplication
> 3 - Must change the filter if we want to use reloadable classloader
> 4 - ReloadableClassloader has static configuration, which prevents using 
> it in a web.xml file that contains several wicket applications
> 5 - Guice integration is very limited - no scopes bindings, cannot inject 
> HttpSession, request and response to classes, ...
> 6 - WicketTester is completely binded to Junit, 
> 7 - The way WicketTester has been developped, with many inheritances, 
> makes it very difficult to extend and provide different behavior. I.e, when 
> we enhanced the wicket tester, we wanted to provide our proper 
> WicketApplication already configured through our filter. But the 
> MockWebApplication class has no constructor that simply take has argument a 
> configured - ready to use WebApplication (it recreate a filter, etc...)
> So this issue is much more a improvement request: wicket-contrib code could 
> be taken / modified / integrated in Wicket code base to improve Guice 
> support, testing features, and also to fix issues about reloading 
> classloader, wicket tester binded to junit, ...
> Hope it will help !
> Mathieu.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-579) Need for DataTable not to require size

2010-10-18 Thread Jeremy Thomerson (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922305#action_12922305
 ] 

Jeremy Thomerson commented on WICKET-579:
-

inmethod-grid provides an implementation that allows unbounded data sets.  
given the quality of that code, there is a viable alternative for now.  
however, i could see the benefit of adding a way of accomplishing this from 
core.

> Need for DataTable not to require size
> --
>
> Key: WICKET-579
> URL: https://issues.apache.org/jira/browse/WICKET-579
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket, wicket-extensions
>Affects Versions: 1.3.0-beta1
> Environment: 1.3 snapshot dated 4/25
>Reporter: Kurt Roekle
> Fix For: 1.5-M3
>
> Attachments: WICKET-578.patch, wicket-toolbar.jar
>
>
> Requiring a size query for the DataProvider passed to the DataTable hurts 
> performance and scalability (not to mention, it wont be accurate in a system 
> when a lot of updates/deletes are taking place).  I had hoped to be able to 
> code just a new toolbar and DataProvider that would fix this, but I found I 
> needed changes in DataTable and  AbstractPageableView due to the fact 
> AbstractPageableView caches the row count.  I've made fixes for DataTable and 
> AbstractPageableView and I've included one new interface that would be 
> required.  I've also added an implementation of a new toolbar and 
> DataProvider that will enable DataTable to work without size (I've also 
> included a modified NavigationToolbar (and friends) that could be implemented 
> instead of a new toolbar.  I've tested these changes with my limited 
> knowledge of wicket and they seem to not break any existing code.  I 
> currently can't give you a diff, but the line #'s that changed are as follows:
>   
> AbstractPageableView: 70,97,137,139,142-149
> DataTable: 120-122
> NavigationToolbar: 39,49,60,64,88,104
> PagingNavigator: 48,62-66,81,97,110
> NavigatorLabel: 42,54,74

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-2532) Pageable Views call IDataProvider.size() more than once

2010-10-18 Thread Jeremy Thomerson (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922296#action_12922296
 ] 

Jeremy Thomerson edited comment on WICKET-2532 at 10/18/10 5:57 PM:


just to add a comment here.  the inmethod grid allows tables of unknown size.  
we could look at how it does it, although there are significant differences 
between the two.

also, see WICKET-579

  was (Author: jthomerson):
just to add a comment here.  the inmethod grid allows tables of unknown 
size.  we could look at how it does it, although there are significant 
differences between the two.
  
> Pageable Views call IDataProvider.size() more than once
> ---
>
> Key: WICKET-2532
> URL: https://issues.apache.org/jira/browse/WICKET-2532
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 1.4.1
> Environment: All
>Reporter: bernard
> Fix For: 1.5-M3
>
> Attachments: ContactDataProviderTest.java, PagingPage.java
>
>
> IDataProvider.size() is typically an expensive database operation. It is 
> called twice in typical Pageable View scenarios although Wicket makes 
> attempts to avoid that. In addition, the first call is premature from the 
> application perspective because it is made while the the requested page 
> position is not yet known.
> How to reproduce:
> Drop in the attached files into the Wicket examples application and run:
> repeaters|Paging DataView Example - builds on previous to demonstrate paging 
> and page navigation
> Otherwise I am running against a wall with IDataProvider.size() and 
> AbstractPageableVew because I can't find any way to get the page position at 
> the same time when IDataProvider.size() is called. Support of paging of 
> results of unknows size is impossible without this information. Please refer 
> to Google search results paging - that is the kind of paging we need.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-2532) Pageable Views call IDataProvider.size() more than once

2010-10-18 Thread Jeremy Thomerson (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922296#action_12922296
 ] 

Jeremy Thomerson commented on WICKET-2532:
--

just to add a comment here.  the inmethod grid allows tables of unknown size.  
we could look at how it does it, although there are significant differences 
between the two.

> Pageable Views call IDataProvider.size() more than once
> ---
>
> Key: WICKET-2532
> URL: https://issues.apache.org/jira/browse/WICKET-2532
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 1.4.1
> Environment: All
>Reporter: bernard
> Fix For: 1.5-M3
>
> Attachments: ContactDataProviderTest.java, PagingPage.java
>
>
> IDataProvider.size() is typically an expensive database operation. It is 
> called twice in typical Pageable View scenarios although Wicket makes 
> attempts to avoid that. In addition, the first call is premature from the 
> application perspective because it is made while the the requested page 
> position is not yet known.
> How to reproduce:
> Drop in the attached files into the Wicket examples application and run:
> repeaters|Paging DataView Example - builds on previous to demonstrate paging 
> and page navigation
> Otherwise I am running against a wall with IDataProvider.size() and 
> AbstractPageableVew because I can't find any way to get the page position at 
> the same time when IDataProvider.size() is called. Support of paging of 
> results of unknows size is impossible without this information. Please refer 
> to Google search results paging - that is the kind of paging we need.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (WICKET-3115) source code link doesn't work in wicket-examples 1.5 - request mappers demo

2010-10-18 Thread Jeremy Thomerson (JIRA)
source code link doesn't work in wicket-examples 1.5 - request mappers demo
---

 Key: WICKET-3115
 URL: https://issues.apache.org/jira/browse/WICKET-3115
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket-examples
Affects Versions: 1.5-M2.1
Reporter: Jeremy Thomerson


fire up wicket-examples in trunk and go to the request mappers examples.  click 
"source code" in the top right.  It doesn't work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (WICKET-3115) source code link doesn't work in wicket-examples 1.5 - request mappers demo

2010-10-18 Thread Jeremy Thomerson (JIRA)

 [ 
https://issues.apache.org/jira/browse/WICKET-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Thomerson updated WICKET-3115:
-

Priority: Minor  (was: Major)

> source code link doesn't work in wicket-examples 1.5 - request mappers demo
> ---
>
> Key: WICKET-3115
> URL: https://issues.apache.org/jira/browse/WICKET-3115
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket-examples
>Affects Versions: 1.5-M2.1
>Reporter: Jeremy Thomerson
>Priority: Minor
>
> fire up wicket-examples in trunk and go to the request mappers examples.  
> click "source code" in the top right.  It doesn't work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1633) Wicket contributions

2010-10-18 Thread Jeremy Thomerson (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922291#action_12922291
 ] 

Jeremy Thomerson commented on WICKET-1633:
--

Mathieu,

  Please comment on whether there is anything left in here that should keep 
this ticket open.  It's been open 2 1/2 years and there's been a lot of 
evolution of the Spring and Guice support during that time.

> Wicket contributions
> 
>
> Key: WICKET-1633
> URL: https://issues.apache.org/jira/browse/WICKET-1633
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket, wicket-guice
>Affects Versions: 1.4-M1
> Environment: Any
>Reporter: Mathieu Carbou
>Assignee: Alastair Maw
>Priority: Minor
>
> Hi,
> I don't know if it is the right place to post this ;) So here is the request:
> We wanted to use wicket with Guice, but we found some limitations in the 
> source code and Guice integration. So i decided to extract all the classes i 
> developped in a project : wicket-contrib at 
> http://code.google.com/p/wicket-contrib/.  You can find all the improved 
> wicket classes with a user guide explaining how to use the changes, but i 
> hardly suggest you checkout the code base, issue a mvn idea:idea and run the 
> sample webapps as described in the user guide.
> Here is the list of our concerns:
> 1 - we wanted to have the minimal configuration to do - using Convention 
> Over Configuration, but still be able to customize as wee need
> 2 - we wanted to be able to use a ReloadableClassloader when testing 
> mutliple wicket apps in the same webapp
> 3 - we wanted to have a real simple way to use Guice with wicket
> 4 - we wanted to have Guice features provided, like the ability to use 
> scope bindings (request, session, flash), and also the ability to integration 
> easily WARP modules for persistence, security, ... from 
> http://www.wideplay.com/
> 5 - we wanted to use wicket testing features without junit but with 
> TestNG and also with Guice integration
> We found some limitations in the current code base of wicket (1.4-SNAPSHOT):
> 1 - Too many configurations in the web.xml file 
> 2 - Must provide a WebApplication
> 3 - Must change the filter if we want to use reloadable classloader
> 4 - ReloadableClassloader has static configuration, which prevents using 
> it in a web.xml file that contains several wicket applications
> 5 - Guice integration is very limited - no scopes bindings, cannot inject 
> HttpSession, request and response to classes, ...
> 6 - WicketTester is completely binded to Junit, 
> 7 - The way WicketTester has been developped, with many inheritances, 
> makes it very difficult to extend and provide different behavior. I.e, when 
> we enhanced the wicket tester, we wanted to provide our proper 
> WicketApplication already configured through our filter. But the 
> MockWebApplication class has no constructor that simply take has argument a 
> configured - ready to use WebApplication (it recreate a filter, etc...)
> So this issue is much more a improvement request: wicket-contrib code could 
> be taken / modified / integrated in Wicket code base to improve Guice 
> support, testing features, and also to fix issues about reloading 
> classloader, wicket tester binded to junit, ...
> Hope it will help !
> Mathieu.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (WICKET-3098) AjaxEventBehavior#onEvent is invoked on disabled behavior

2010-10-18 Thread Pedro Santos (JIRA)

 [ 
https://issues.apache.org/jira/browse/WICKET-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pedro Santos updated WICKET-3098:
-

Attachment: patch.txt

an test case preventing the bug plus a missing else clause :)

> AjaxEventBehavior#onEvent is invoked on disabled behavior
> -
>
> Key: WICKET-3098
> URL: https://issues.apache.org/jira/browse/WICKET-3098
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.9
>Reporter: Stanislav Dvorscak
>Assignee: Igor Vaynberg
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: BehaviorRequestTarget.java.patch, patch.txt
>
>
> Security bug  AjaxEventBehavior#onEvent is invoked on disabled behavior. It 
> should not be - it is really dangerous, can you fix it.
> I think it is security bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1024004 - in /wicket/trunk: wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/ wicket-jmx/src/main/java/org/apache/wicket/jmx/ wicket/src/main/java/org/apache/wicket/markup

2010-10-18 Thread ivaynberg
Author: ivaynberg
Date: Mon Oct 18 21:06:13 2010
New Revision: 1024004

URL: http://svn.apache.org/viewvc?rev=1024004&view=rev
Log:
remove left overs of obsolted auto multi window support from 1.4.x

Removed:

wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/INewBrowserWindowListener.java
Modified:

wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/NiceUrlApplication.java

wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettings.java

wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettingsMBean.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/WebPage.java

wicket/trunk/wicket/src/main/java/org/apache/wicket/settings/IPageSettings.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/settings/Settings.java

Modified: 
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/NiceUrlApplication.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/NiceUrlApplication.java?rev=1024004&r1=1024003&r2=1024004&view=diff
==
--- 
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/NiceUrlApplication.java
 (original)
+++ 
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/niceurl/NiceUrlApplication.java
 Mon Oct 18 21:06:13 2010
@@ -62,10 +62,6 @@ public class NiceUrlApplication extends 
{
super.init();
 
-   // Disable creation of javascript which jWebUnit (test only)
-   // doesn't handle properly
-   getPageSettings().setAutomaticMultiWindowSupport(false);
-
// mount single bookmarkable pages
mountPage("/the/homepage/path", Home.class);
mountPage("/a/nice/path/to/the/first/page", Page1.class);

Modified: 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettings.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettings.java?rev=1024004&r1=1024003&r2=1024004&view=diff
==
--- 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettings.java 
(original)
+++ 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettings.java 
Mon Oct 18 21:06:13 2010
@@ -37,14 +37,6 @@ public class PageSettings implements Pag
}
 
/**
-* @see 
org.apache.wicket.jmx.PageSettingsMBean#getAutomaticMultiWindowSupport()
-*/
-   public boolean getAutomaticMultiWindowSupport()
-   {
-   return 
application.getPageSettings().getAutomaticMultiWindowSupport();
-   }
-
-   /**
 * @see 
org.apache.wicket.jmx.PageSettingsMBean#getVersionPagesByDefault()
 */
public boolean getVersionPagesByDefault()
@@ -53,14 +45,6 @@ public class PageSettings implements Pag
}
 
/**
-* @see 
org.apache.wicket.jmx.PageSettingsMBean#setAutomaticMultiWindowSupport(boolean)
-*/
-   public void setAutomaticMultiWindowSupport(boolean 
automaticMultiWindowSupport)
-   {
-   
application.getPageSettings().setAutomaticMultiWindowSupport(automaticMultiWindowSupport);
-   }
-
-   /**
 * @see 
org.apache.wicket.jmx.PageSettingsMBean#setVersionPagesByDefault(boolean)
 */
public void setVersionPagesByDefault(boolean pagesVersionedByDefault)

Modified: 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettingsMBean.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettingsMBean.java?rev=1024004&r1=1024003&r2=1024004&view=diff
==
--- 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettingsMBean.java
 (original)
+++ 
wicket/trunk/wicket-jmx/src/main/java/org/apache/wicket/jmx/PageSettingsMBean.java
 Mon Oct 18 21:06:13 2010
@@ -16,7 +16,6 @@
  */
 package org.apache.wicket.jmx;
 
-import org.apache.wicket.markup.html.WebPage;
 
 /**
  * Page settings.
@@ -26,48 +25,11 @@ import org.apache.wicket.markup.html.Web
 public interface PageSettingsMBean
 {
/**
-* Gets whether Wicket should try to support opening multiple windows 
for the same session
-* transparently. If this is true - the default setting -, Wicket tries 
to detect whether a new
-* window was opened by a user (e.g. in Internet Explorer by pressing 
ctrl+n or ctrl+click on a
-* link), and if it detects that, it creates a new page map for that 
window on the fly. As a
-* page map represents the 'history' of one window, each window will 
then have their own
-* history. If two windows would share the same page map, the 
non-bookmarkable links on one

[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Mike Hefner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1295#action_1295
 ] 

Mike Hefner commented on WICKET-3112:
-

Korbinian,
I'm not sure what's going wrong. The problem code that you have at lines 
801-807 should be at lines 938-944 in #treeNodesRemoved().

In Eclipse, I've just tried reverting my local copy of AbstractTree.java to rev 
1023567, confirmed that it's the old version that uses TreeNode, then 
re-applied my patch with no problem.   I'm not familiar with IDEA, but is there 
some way to grab a specific revision of a file from the svn repository so you 
can make sure it's the right one?

Has anyone else been able to apply my patch successfully?


> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1023926 - /wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java

2010-10-18 Thread pete
Author: pete
Date: Mon Oct 18 17:53:17 2010
New Revision: 1023926

URL: http://svn.apache.org/viewvc?rev=1023926&view=rev
Log:
fixed broken test: removed test for mounting '/' since it is not illegal anymore

Modified:

wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java

Modified: 
wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java?rev=1023926&r1=1023925&r2=1023926&view=diff
==
--- 
wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java
 (original)
+++ 
wicket/trunk/wicket/src/test/java/org/apache/wicket/request/mapper/MountedMapperTest.java
 Mon Oct 18 17:53:17 2010
@@ -451,24 +451,6 @@ public class MountedMapperTest extends A
/**
 * 
 */
-   public void testConstruct2()
-   {
-   try
-   {
-   IRequestMapper e = new MountedMapper("/", 
MockPage.class);
-
-   // should never get here
-   assertFalse(true);
-   }
-   catch (IllegalArgumentException e)
-   {
-   // ok
-   }
-   }
-
-   /**
-* 
-*/
public void testPlaceholderDecode1()
{
Url url = Url.parse("some/p1/path/p2");




[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Korbinian Bachl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922165#action_12922165
 ] 

Korbinian Bachl commented on WICKET-3112:
-

@Mike:

dont know what happens here, just rechecked it:

svn co http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x wicket-1.4.x

then open in IDEA and apply patch (IDEA grabs correct revision by itself from 
SVN)

then patch is applied, all well, but lines 801 - 807 want a parentItem that is 
never defined, see here (whole function):

(start-lini is: 772)

public final void treeNodesChanged(TreeModelEvent e)
{
if (dirtyAll)
{
return;
}
// has root node changed?
if (e.getChildren() == null)
{
if (rootItem != null)
{
invalidateNode(rootItem.getModelObject(), true);
}
}
else
{
// go through all changed nodes
Object[] children = e.getChildren();
if (children != null)
{
for (Object node : children)
{
if (isNodeVisible(node))
{
// if the nodes is visible 
invalidate it
invalidateNode(node, true);
}
}
}

if (!parentItem.hasChildTreeItems())
{
// rebuild parent's icon to show it no longer 
has children
invalidateNode(parentNode, true);
}

}
}

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1023883 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java

2010-10-18 Thread mgrigorov
Author: mgrigorov
Date: Mon Oct 18 16:17:47 2010
New Revision: 1023883

URL: http://svn.apache.org/viewvc?rev=1023883&view=rev
Log:
Add a comment to HomePageMapper that it doesn't handle generation of Url for 
IRequestHandler's

If the user application wants to preserve '/' as url then it must mount it 
explicitly in MyApplication#init()

Idea: we could do that automatically in #internalInit() and remove completely 
HomePageMapper.

Remove the check in AbstractMapper because otherwise it is not possible to 
mount at '/'

Modified:

wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java

wicket/trunk/wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java

Modified: 
wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java?rev=1023883&r1=1023882&r2=1023883&view=diff
==
--- 
wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java
 (original)
+++ 
wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/mapper/AbstractMapper.java
 Mon Oct 18 16:17:47 2010
@@ -189,11 +189,6 @@ public abstract class AbstractMapper
}
Url url = Url.parse(mountPath);
 
-   if (url.getSegments().isEmpty())
-   {
-   throw new IllegalArgumentException("Mount path must 
have at least one segment.");
-   }
-
String[] res = new String[url.getSegments().size()];
for (int i = 0; i < res.length; ++i)
{

Modified: 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java?rev=1023883&r1=1023882&r2=1023883&view=diff
==
--- 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java
 (original)
+++ 
wicket/trunk/wicket/src/main/java/org/apache/wicket/request/mapper/HomePageMapper.java
 Mon Oct 18 16:17:47 2010
@@ -16,6 +16,7 @@
  */
 package org.apache.wicket.request.mapper;
 
+import org.apache.wicket.Application;
 import org.apache.wicket.request.IRequestHandler;
 import org.apache.wicket.request.Request;
 import org.apache.wicket.request.Url;
@@ -28,7 +29,12 @@ import org.apache.wicket.request.mapper.
 import org.apache.wicket.util.lang.Args;
 
 /**
- * Mapper for rendering home page.
+ * Default mapper for rendering the configured {...@link 
Application#getHomePage() home page}.
+ * 
+ * Note: Handles requests to '/' but does not produce 
{...@link Url} for it, thus
+ * {...@link BookmarkableMapper} produces something like 
'/wicket/bookmarkable/com.example.MyHomePage'
+ * for it. If the user application wants to preserve '/' then it should mount 
the home page
+ * explicitly in MyApplication#init()
  * 
  * @author Matej Knopp
  */




[jira] Created: (WICKET-3114) Various issues in wicket-examples 1.5.x

2010-10-18 Thread Martin Grigorov (JIRA)
Various issues in wicket-examples 1.5.x
---

 Key: WICKET-3114
 URL: https://issues.apache.org/jira/browse/WICKET-3114
 Project: Wicket
  Issue Type: Bug
  Components: wicket, wicket-examples
Affects Versions: 1.5-M2.1
Reporter: Martin Grigorov


Here is a list of some issues found by Igor while playing with 1.5 
wicket-examples:

* wicket package mounter produces // in url: 
http://localhost:8080/wicket-examples/niceurl//my/mounted/package/

* ajax links example - failure handler is not invoked, instead error is reported

* ajax upload example: text field is always null?

* ajax modal window - page window does not repaint result

* ejax onchange example does not work

* ajax rating example seems slow

More information about each one will be added when the respective issue is 
investigated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1404) Investigate default focus support (on Page or RequestCycle)

2010-10-18 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922105#action_12922105
 ] 

Igor Vaynberg commented on WICKET-1404:
---

thats why there is also ondomready() which shouldnt suffer from that problem.

> Investigate default focus support (on Page or RequestCycle)
> ---
>
> Key: WICKET-1404
> URL: https://issues.apache.org/jira/browse/WICKET-1404
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 1.3.1
>Reporter: James Carman
>Priority: Minor
> Fix For: 1.5-M3
>
> Attachments: WICKET-1404.patch
>
>
> We need something which gives a component the focus when the page loads.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3098) AjaxEventBehavior#onEvent is invoked on disabled behavior

2010-10-18 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922100#action_12922100
 ] 

Igor Vaynberg commented on WICKET-3098:
---

a more likely scenario is that the user overrode isenabled() on the component 
or behavior, and at the time of the callback it returns false. another one is 
that the client messed around with the url and change the behavior index.

anyways, it is handled just like a click on a disabled component.

> AjaxEventBehavior#onEvent is invoked on disabled behavior
> -
>
> Key: WICKET-3098
> URL: https://issues.apache.org/jira/browse/WICKET-3098
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.9
>Reporter: Stanislav Dvorscak
>Assignee: Igor Vaynberg
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: BehaviorRequestTarget.java.patch
>
>
> Security bug  AjaxEventBehavior#onEvent is invoked on disabled behavior. It 
> should not be - it is really dangerous, can you fix it.
> I think it is security bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Mike Hefner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922085#action_12922085
 ] 

Mike Hefner edited comment on WICKET-3112 at 10/18/10 10:55 AM:


My patch for WICKET-3112 does cause a minor change in the behavior that Sergey 
noted in his comment on WICKET-2886 -

Case 1 - When adding the first child to a node, it is expanded and the child 
node is displayed. This behavior hasn't changed.

Case 2 - If you collapse a node that has already has children, then add another 
child, the parent node is expanded and all the children are displayed. This is 
a change; previously the parent node did not expand.

The reason for the change is that it's difficult to distinguish between case 1 
and case 2 with only the information in AbstractTree's internal tree of 
TreeItems. My original patch for WICKET-2886 relied on casting the parent item 
in the insertion event to TreeNode and then using its child list to distinguish 
between the cases. But that's what broke Brix and any other projects that don't 
use TreeNodes.

IMHO, this is a fairly minor change in behavior and it seems more important to 
get the fix for WICKET-3112 out. I can open another JIRA issue and take the 
time to figure out how to distinguish between the two cases without relying on 
TreeNode.

Another option is not to expand the parent node in either case 1 or case 2. 
When I fixed WICKET-2886, I made the assumption that when you added the first 
child to a node, you would want the parent node to be expanded and the child 
visible. It would be a simple change to update the parent node's JunctionLink 
to indicate that it now has a child, but not to expand it. The user would have 
to click on the JunctionLink to see the child they just added.


  was (Author: mikehefner):
My patch for WICKET-3112 does cause a minor change in the behavior that 
Sergey noted in his comment on WICKET-2886 -

Case 1 - When adding the first child to a node, it is expanded and the child 
node is displayed. This behavior hasn't changed.

Case 2 - If you collapse a node that has already has children, then add another 
child, the parent node is expanded and all the children are displayed. This is 
a change; previously the parent node did not expand.

The reason for the change is that it's difficult to distinguish between case 1 
and case 2 with only the information in AbstractTree's internal tree of 
TreeItems. My original patch for WICKET-2886 relied on casting the parent item 
in the insertion event to TreeNode and then using its child list to distinguish 
between the cases. But that's what broke Brix and any other projects that don't 
use TreeNodes.

IMHO, this is a fairly minor change in behavior and it seems more important to 
get the fix for WICKET-3112 out. I can open another JIRA issue and take the 
time to figure out how to distinguish between the two cases without relying on 
TreeNode.
  
> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax

[jira] Commented: (WICKET-3098) AjaxEventBehavior#onEvent is invoked on disabled behavior

2010-10-18 Thread Pedro Santos (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922089#action_12922089
 ] 

Pedro Santos commented on WICKET-3098:
--

Why silent return the call rather then throw page expired exception? The only 
use case that I can imagine now is:
- add an enabled component +  ajax behavior
- processing some ajax request, disable the component and don't add it to target
Result: page is presenting an expired component state, the current one is 
disable.

> AjaxEventBehavior#onEvent is invoked on disabled behavior
> -
>
> Key: WICKET-3098
> URL: https://issues.apache.org/jira/browse/WICKET-3098
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.9
>Reporter: Stanislav Dvorscak
>Assignee: Igor Vaynberg
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: BehaviorRequestTarget.java.patch
>
>
> Security bug  AjaxEventBehavior#onEvent is invoked on disabled behavior. It 
> should not be - it is really dangerous, can you fix it.
> I think it is security bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Mike Hefner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922086#action_12922086
 ] 

Mike Hefner commented on WICKET-2886:
-

I added a comment about the changed behavior to WICKET-3112.

> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Mike Hefner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922085#action_12922085
 ] 

Mike Hefner commented on WICKET-3112:
-

My patch for WICKET-3112 does cause a minor change in the behavior that Sergey 
noted in his comment on WICKET-2886 -

Case 1 - When adding the first child to a node, it is expanded and the child 
node is displayed. This behavior hasn't changed.

Case 2 - If you collapse a node that has already has children, then add another 
child, the parent node is expanded and all the children are displayed. This is 
a change; previously the parent node did not expand.

The reason for the change is that it's difficult to distinguish between case 1 
and case 2 with only the information in AbstractTree's internal tree of 
TreeItems. My original patch for WICKET-2886 relied on casting the parent item 
in the insertion event to TreeNode and then using its child list to distinguish 
between the cases. But that's what broke Brix and any other projects that don't 
use TreeNodes.

IMHO, this is a fairly minor change in behavior and it seems more important to 
get the fix for WICKET-3112 out. I can open another JIRA issue and take the 
time to figure out how to distinguish between the two cases without relying on 
TreeNode.

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Mike Hefner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922080#action_12922080
 ] 

Mike Hefner commented on WICKET-3112:
-

Korbinian,
I created the patch against AbstractTree.java revision 1023567, the latest in 
/branches/wicket-1.4.x. 

In my patched AbstractTree.java file, line 810 is in 
#markTheLastButOneChildDirty(), not one of the modified methods. Are you saying 
that when you apply the patch, the resulting file fails during compilation? Or 
is there an error when you run it?

If the error is during execution, can you give me the steps to reproduce it? I 
tested the patch against the latest wicket-1.4.x and the latest in brix trunk 
(1.2.3-SNAPSHOT).

Thanks

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Martin Grigorov (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922074#action_12922074
 ] 

Martin Grigorov commented on WICKET-3112:
-

Sergey,

Did you apply any of the patches in this ticket before testing ?
Latest SVN version doesn't contain any of these patches. That's why we ask the 
affected users for feedback.

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Sergey Plevko (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922071#action_12922071
 ] 

Sergey Plevko commented on WICKET-3112:
---

Martin,

>>Thanks for the feedback!
>>May I ask you which patch did you use when testing ? There are two - one by 
>>me and one by Mike.
>>Please comment directly in WICKET-3112.

I tested on Wicket 1.4.x #211

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Martin Grigorov (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922070#action_12922070
 ] 

Martin Grigorov commented on WICKET-2886:
-

Hi Sergey,

Thanks for the feedback!
May I ask you which patch did you use when testing ? There are two - one by me 
and one by Mike.
Please comment directly in WICKET-3112.

I'm not sure about the behavior. We must preserve the old one, i.e. 
pre-WICKET-3112.

> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Sergey Plevko (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922065#action_12922065
 ] 

Sergey Plevko edited comment on WICKET-2886 at 10/18/10 9:20 AM:
-

Martin,

I've tested WICKET-3112.
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?

  was (Author: lotos):
Martin,

I've tested [[WICKET-3112]].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?
  
> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Sergey Plevko (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922065#action_12922065
 ] 

Sergey Plevko commented on WICKET-2886:
---

Martin,

I've tested [https://issues.apache.org/jira/browse/WICKET-3112 WICKET-3112].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?

> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Sergey Plevko (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922065#action_12922065
 ] 

Sergey Plevko edited comment on WICKET-2886 at 10/18/10 9:20 AM:
-

Martin,

I've tested [[WICKET-3112]].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?

  was (Author: lotos):
Martin,

I've tested [WICKET-3112].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?
  
> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-2886) Tree doesn't update correctly

2010-10-18 Thread Sergey Plevko (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922065#action_12922065
 ] 

Sergey Plevko edited comment on WICKET-2886 at 10/18/10 9:19 AM:
-

Martin,

I've tested [WICKET-3112].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?

  was (Author: lotos):
Martin,

I've tested [https://issues.apache.org/jira/browse/WICKET-3112 WICKET-3112].
It works.
But i noticed one thing, that this parent node is expanded by default after 
adding a child. Is it ok?
  
> Tree doesn't update correctly
> -
>
> Key: WICKET-2886
> URL: https://issues.apache.org/jira/browse/WICKET-2886
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.8
> Environment: tomcat 6.0.14, win 7
>Reporter: Sergey Plevko
>Assignee: Igor Vaynberg
> Fix For: 1.4.11, 1.5-M2.1
>
> Attachments: WICKET-2886-fix.patch, WICKET-2886-Quickstart.zip
>
>
> When we add a first child to the node this update doesn't appeare in a 
> browser. If we collapse/expand this the parent node forced we will see 
> changes. All the rest updates work correctly.
> This bug easily can be reproduced with the next pice of code.
> TestPage.html 
> http://www.w3.org/1999/xhtml"; 
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
> 
> 
> 
> 
>  class="btn btnStd" />
> 
> 
> 
> TestPage.java
> public class TestPage extends WebPage {
> public MainTreeTestPage() {
> DefaultMutableTreeNode root = new DefaultMutableTreeNode("root");
> final DefaultMutableTreeNode rootChild = new 
> DefaultMutableTreeNode("rootChild");
> root.add(rootChild);
> final DefaultTreeModel treeModel = new DefaultTreeModel(root);
> final BaseTree tree = new LinkTree("tree", treeModel);
> add(tree);
> tree.getTreeState().expandNode(root);
> AjaxLink addButton = new AjaxLink("addChild") {
> public void onClick(AjaxRequestTarget ajaxRequestTarget) {
> DefaultMutableTreeNode child = new 
> DefaultMutableTreeNode("child");
> //rootChild.add(child); // it doesn't matter how we add this 
> child
> treeModel.insertNodeInto(child, rootChild, 0);
> tree.updateTree(ajaxRequestTarget);
> }
> };
> add(addButton);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1404) Investigate default focus support (on Page or RequestCycle)

2010-10-18 Thread Anatoly Kupriyanov (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922023#action_12922023
 ] 

Anatoly Kupriyanov commented on WICKET-1404:


It's bad idea to set focus from the onload event. This event could occur after 
a control is visible and a user starts edit the control - focus suddenly jumps 
to another one.
I hate this - I open page, it still loading but login/password form already 
rendered and while I'm typing a password, page finishes loading and focus 
suddenly jumps to the login box, it could reveal my password.
Usually it's better to put getElementById('" + component.getMarkupId() + 
"').focus() right after form component.

> Investigate default focus support (on Page or RequestCycle)
> ---
>
> Key: WICKET-1404
> URL: https://issues.apache.org/jira/browse/WICKET-1404
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 1.3.1
>Reporter: James Carman
>Priority: Minor
> Fix For: 1.5-M3
>
> Attachments: WICKET-1404.patch
>
>
> We need something which gives a component the focus when the page loads.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Korbinian Bachl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922019#action_12922019
 ] 

Korbinian Bachl commented on WICKET-3112:
-

Martin, your 2nd patch seems to work. I also looked at Mike's patch and the 
null pointer but I can't get that one to work here. I allways end up on line 
~810 with a check to a parentItem that is invalid as there is no parentItem 
around... 
@Mike: at what version did you do this patch against? I tried it against latest 
in branch-trunk as well as latest official one but both failed

> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (WICKET-3112) Fix of issue 2886 breaks all individual implementations of any AbstractTree

2010-10-18 Thread Korbinian Bachl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922019#action_12922019
 ] 

Korbinian Bachl edited comment on WICKET-3112 at 10/18/10 5:01 AM:
---

Martin, your 2nd patch seems to work. I also looked at Mike's patch and the 
null pointer but I can't get that one to work here. I allways end up on line 
~810 with a check to a parentItem that is invalid as there is no parentItem 
around... 
@Mike: at what version did you do this patch against? I tried it against latest 
in branch-trunk as well as latest official one but both failed

PS: Big thank you for fixing it :)

  was (Author: korbinian):
Martin, your 2nd patch seems to work. I also looked at Mike's patch and the 
null pointer but I can't get that one to work here. I allways end up on line 
~810 with a check to a parentItem that is invalid as there is no parentItem 
around... 
@Mike: at what version did you do this patch against? I tried it against latest 
in branch-trunk as well as latest official one but both failed
  
> Fix of issue 2886 breaks all individual implementations of any AbstractTree
> ---
>
> Key: WICKET-3112
> URL: https://issues.apache.org/jira/browse/WICKET-3112
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 1.4.11, 1.4.12
> Environment: any wicket 1.4 app
>Reporter: Korbinian Bachl
>Assignee: Martin Grigorov
>Priority: Blocker
> Attachments: WICKET-3112.patch, WICKET-3112.patch, 
> WICKET-3122-fix.patch
>
>
> AbstratTree was originally written againt pure interfaces and not relies on a 
> special Class, namely the javax.swing.tree.TreeNode. This breaks all custom 
> tree's out there like e.g. the one in the brix project. 
> A workaround to this problem I tried was unsuccessful as the problem is that 
> many parts of AbstratTree are final and can't be easily overwritten and that 
> many other projects epen on Abstrattree like the inmethod grid stuff and much 
> more. This means that any special Nodes for trees can't be implemented 
> anymore, making this a ultimate stopper for all projects rlying on some 
> special nodes. IMHO 2886 should be reverted and then looked upon a differnet 
> patch for this solution that doesn't break everything out there. 
> Example from default Brxix 1.2.3-SNAPSHOT:
> java.lang.ClassCastException: brix.plugin.menu.editor.MenuTreeNode
> cannot be cast to javax.swing.tree.TreeNode
> at
> org.apache.wicket.markup.html.tree.AbstractTree.treeNodesInserted(AbstractTree.java:
> 823)
> at
> brix.web.tree.AbstractTreeModel.nodeInserted(AbstractTreeModel.java:
> 138)
> at brix.plugin.menu.editor.MenuEditor$5.onClick(MenuEditor.java:194)
> at org.apache.wicket.ajax.markup.html.AjaxLink
> $1.onEvent(AjaxLink.java:68)
> at
> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:
> 177)
> at
> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:
> 300)
> at
> org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:
> 119) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.