Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 Ari S. - Original Message - From: Martijn Dashorst [EMAIL PROTECTED] To: Wicket Development [EMAIL PROTECTED]; Wicket Users users@wicket.apache.org Sent: Monday, March 17, 2008 10:13 AM Subject: [vote] Release 1.4 with only generics and stop support for 1.3 This thread is for voting only. Use the [discuss] thread for voicing your opinion or asking questions. This makes counting the votes much easier. The discussion on our development list makes it clear that a lot of folks are anxious for generified models. Most users if not all wish us to release a quick release which is 1.3 + generics. The consequence is that the core team will stop to support 1.3, and that everybody that wishes updates will have to migrate to 1.4, and upgrade to Java 5. Everybody is invited to vote! Please use [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 [ ] -1, I need a supported version running on Java 1.4 Let your voices be heard! Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira WICKET-1184 (PageSavingThread not stopped)
Hi, This seems to occur at us and I have been able to reproduce it with standard tomcat 6.0 installation. I added some comments to: https://issues.apache.org/jira/browse/WICKET-1184 Ari S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
