[jira] Updated: (WICKET-2440) ReuseIfModelObjectsEqualStrategy - Reuse Strategy for repeaters based on model objects
[ https://issues.apache.org/jira/browse/WICKET-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Zatselyapin updated WICKET-2440: --- Attachment: ReuseIfModelObjectsEqualStrategy.java based on version 3.5 > ReuseIfModelObjectsEqualStrategy - Reuse Strategy for repeaters based on > model objects > -- > > Key: WICKET-2440 > URL: https://issues.apache.org/jira/browse/WICKET-2440 > Project: Wicket > Issue Type: Improvement > Components: wicket > Environment: generic >Reporter: Dmitry Zatselyapin >Priority: Minor > Attachments: ReuseIfModelObjectsEqualStrategy.java > > > Add new reuse strategy that allows reuse models if model objects have not > changed. The existing ReuseIfModelsEqualStrategy can also be used to > accomplish this, you must override the model's equals/hashcode for proper > implementation. Using ReuseIfModelObjectsEqualStrategy will require provide > equals/hashcode methods only for model objects. Models themselves do not > have to be changed. There are only tiny changes required to the > ReuseIfModelsEqualStrategy to create this new strategy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2440) ReuseIfModelObjectsEqualStrategy - Reuse Strategy for repeaters based on model objects
ReuseIfModelObjectsEqualStrategy - Reuse Strategy for repeaters based on model objects -- Key: WICKET-2440 URL: https://issues.apache.org/jira/browse/WICKET-2440 Project: Wicket Issue Type: Improvement Components: wicket Environment: generic Reporter: Dmitry Zatselyapin Priority: Minor Add new reuse strategy that allows reuse models if model objects have not changed. The existing ReuseIfModelsEqualStrategy can also be used to accomplish this, you must override the model's equals/hashcode for proper implementation. Using ReuseIfModelObjectsEqualStrategy will require provide equals/hashcode methods only for model objects. Models themselves do not have to be changed. There are only tiny changes required to the ReuseIfModelsEqualStrategy to create this new strategy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2416) Exception with EJB Session Bean
[ https://issues.apache.org/jira/browse/WICKET-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748596#action_12748596 ] bernard commented on WICKET-2416: - The test case also fails immediately on a virtual remote Debian Linux server. The software on this Linux installation is of different origin, no NetBeans environment, pure server. The GlassFish version is v2.1, as on the Windows computer. I would not like to restrict the test case fail criterion to failure on pressing the browser back button. Please click through the pages. The test case fails on pressing the "Continue" button. There are additional failure scenarios as Igor pointed out, and I see them too, but this test case does not focus on them. > Exception with EJB Session Bean > --- > > Key: WICKET-2416 > URL: https://issues.apache.org/jira/browse/WICKET-2416 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.0 > Environment: Java 1.6. > Wicket Java EE 1.1 >Reporter: bernard >Priority: Minor > Attachments: testcase.zip > > > The attached testcase gets an exception > java.io.InvalidClassException: test.session.TestSessionLocal; could not > resolve class [test.session.TestSessionLocal] when deserializing proxy > at > org.apache.wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyInitProxyFactory.java:236) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > when the user clicks through it, starting from index.html. > I can't really make any progress without a fix, or without knowing what I am > doing wrong to get this. > The testcase will work out of the box with NetBeans 6.7.1 and Server: > GlassFish V2 which is bundled with it. > I don't know what really causes this. It is interesting that the tescase runs > ok when > two lines are removed from Page2.java. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2439) Improve MixedParamUrlCodingStrategy, introduce Hybrid
[ https://issues.apache.org/jira/browse/WICKET-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2439: Attachment: WICKET-2439.patch Please apply to 1.4 branch, possible also to 1.5 branch if that is still applicable. > Improve MixedParamUrlCodingStrategy, introduce Hybrid > - > > Key: WICKET-2439 > URL: https://issues.apache.org/jira/browse/WICKET-2439 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.1 >Reporter: Erik van Oosten > Fix For: 1.4.2 > > Attachments: WICKET-2439.patch > > > The MixedParamUrlCodingStrategy can be improved. > The current form has the following shortcomings: > - it just fails when something is added to the URL, solution: add the option > to ignore the added parts (in fact I made this the default) > - when something is added to the URL, the message is not very clear, > solution: rewrite message and add more information > - it does not accept non-String parameter values, solution: use > String.valueOf(paramValue) > In addition the patch adds a Hybrid variant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2439) Improve MixedParamUrlCodingStrategy, introduce Hybrid
Improve MixedParamUrlCodingStrategy, introduce Hybrid - Key: WICKET-2439 URL: https://issues.apache.org/jira/browse/WICKET-2439 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Erik van Oosten Fix For: 1.4.2 The MixedParamUrlCodingStrategy can be improved. The current form has the following shortcomings: - it just fails when something is added to the URL, solution: add the option to ignore the added parts (in fact I made this the default) - when something is added to the URL, the message is not very clear, solution: rewrite message and add more information - it does not accept non-String parameter values, solution: use String.valueOf(paramValue) In addition the patch adds a Hybrid variant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2416) Exception with EJB Session Bean
[ https://issues.apache.org/jira/browse/WICKET-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748446#action_12748446 ] Loren commented on WICKET-2416: --- I have compiled and run this test case using Wicket 1.4.1 and Glassfish V2.1 without error, using the back button hasn't caused any serialization problems. To compile the program I had to remove the libraries Bernard included and add the following: For Test-ejb - just the Glassfish 2.1 library that is added when you associate the app with your application server in NetBeans and JDK 1.6. Nothing else was required. For Test-war - Test-ejb cglib-nodep-2.1_3.jar - I forget if this is required by wicket's logging, or java-ee-contrib, but it is needed. wicket-extensions-1.4.1.jar wicket-ioc-1.4.1.jar wicket-contrib-javaee-1.1.jar The Glassfish 2.1 library JDK 1.6 To run Wicket with Glassfish you do need to add slf4j-jdk14.jar and slf4j-api.jar to /opt/glassfish/lib, because of some issue I've half forgotten with when the logging modules get loaded. Igor, perhaps this will resolve your classloader issue? I've been injecting ejb's into webApplications, pages, panels, and models with wicket-contrib-javaee 1.1 and Wicket 1.3 without any issues for nearly a year, it totally works. Many thanks to the Wicket team, Filippo Diotalevi, and Maris Orbidans for making it go; please please don't discount bugs just because they involve EJB3, it's really not half bad, and some of us need to put big enterprisey technologies somewhere in our design specs for very silly, but, none the less real, reasons. - Loren > Exception with EJB Session Bean > --- > > Key: WICKET-2416 > URL: https://issues.apache.org/jira/browse/WICKET-2416 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.0 > Environment: Java 1.6. > Wicket Java EE 1.1 >Reporter: bernard >Priority: Minor > Attachments: testcase.zip > > > The attached testcase gets an exception > java.io.InvalidClassException: test.session.TestSessionLocal; could not > resolve class [test.session.TestSessionLocal] when deserializing proxy > at > org.apache.wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyInitProxyFactory.java:236) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > when the user clicks through it, starting from index.html. > I can't really make any progress without a fix, or without knowing what I am > doing wrong to get this. > The testcase will work out of the box with NetBeans 6.7.1 and Server: > GlassFish V2 which is bundled with it. > I don't know what really causes this. It is interesting that the tescase runs > ok when > two lines are removed from Page2.java. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748418#action_12748418 ] Rodrigo De Castro commented on WICKET-2437: --- So, is there any plan to make pages thread-safe or does it require an architecture change? Otherwise, it seems to defeat the whole purpose of making things async with Ajax. I would be interested in trying to fix that, so please let me know how I can help. In the meanwhile, should I turn them into individual pages and use an external Ajax library to load them in async way? What would be your suggestion if I have an application with multiple AjaxLazyLoadPanel and I need to paralyze the requests? > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748408#action_12748408 ] Matej Knopp commented on WICKET-2437: - There is no way to process parallel requests for a single page without locking. Pages are not thread safe. > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748393#action_12748393 ] Rodrigo De Castro commented on WICKET-2437: --- Yesterday I played a bit with the client side specifying the channel name in the AjaxLazyLoadPanel class and saw that using multiple channel does not even work. Some panels are loaded, but others never load, eventually leading to an exception. For this reason I thought there may be something else that needed to be changed. Do they have to be serialized on the server? Is that because of the current implementation? I guess this may be a deal-breaker if Wicket does not have any plans to allow concurrent Ajax requests. If you have any suggestion where to begin, I can try to take a look. > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748293#action_12748293 ] Matej Knopp commented on WICKET-2437: - It does not matter if the requests on client are fired in parallel because we are locking on the pagemap so they will be serialized on server. They have to be. So the only "benefit" of parallel request is that the execution order will be non-deterministic. > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
