You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2010/05/19 09:35:03 UTC
[vote] Release Wicket 1.4.9
This vote is to release wicket 1.4.9
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
Artifacts:
http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
Maven repo:
http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
(and below)
This vote ends Saturday 2:30am GMT-5
Please test the release and offer your vote:
[ ] Yes, release
[ ] No, don't release it (and please tell us why)
--
Jeremy Thomerson
http://www.wickettraining.com
---------
Release Notes - Wicket - Version 1.4.9
** Bug
* [WICKET-2741] - non-performant Collections.synchronizedMap() should be
replaced with ConcurrentMap
* [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its
use of the model
* [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
retain selected but disabled items
* [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
causes NullPointerException when used in a Class within the root package
(i.e. it has no package declaration)
* [WICKET-2858] - WicketSessionFilter:
java.lang.IllegalArgumentException: Argument application can not be null
* [WICKET-2859] - Wrong package names in Examples
* [WICKET-2860] - Wrong name for swiss Application.properties
* [WICKET-2861] - getConvertedInput() returns null and
selectedValues.addAll tries adding it
** Improvement
* [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if
form is multiPart
* [WICKET-2840] - Remove final on
AbstractRequestTargetUrlCodingStrategy#getMountPath()
* [WICKET-2846] - Store Application in InheritableThreadLocal instead of
ThreadLocal
* [WICKET-2855] - Constructor of RedirectRequestTarget does not validate
URL
* [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
* [WICKET-2870] - Fix hungarian translation for Wizard
* [WICKET-2879] - delegate isVisible in PanelCachingTab
AW: [vote] Release Wicket 1.4.9
Posted by Stefan Lindner <li...@visionet.de>.
[x] Yes, release
Stefan
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I'd say that it would be better to think this thing through a
bit better and come up with a solution (like the executor idea that
was proposed earlier) that actually works the way users would expect
it to all the time. To me, releasing with something that we know is
half-baked at best is a mistake.
On Thu, May 20, 2010 at 6:17 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> +1 - Yes, release.
>
> I understand that some don't like this because of the
> InheritableThreadLocal. But, I have not seen anything that proves that it
> will cause a bug. It's my understanding that it:
>
> - does work for the one hedge case that it was requested for (starting
> short-lived threads from the request thread)
> - does not break other things (if you are using pooled executors, etc)
> - does not add any extra complexity to our codebase
>
> In that case, I'm in favor of leaving it. However, considering the very
> slight value that it adds, if someone conclusively proves that it breaks
> existing applications (that are not doing something stupid), then I am in
> favor of reverting it for the next release. It just does not have any
> proven detrimental effects that should delay this release and the benefits
> of the other fixes / enhancements.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Wed, May 19, 2010 at 2:35 AM, Jeremy Thomerson <jeremy@wickettraining.com
>> wrote:
>
>> This vote is to release wicket 1.4.9
>>
>> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
>> Artifacts:
>> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
>> Maven repo:
>> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
>> Changelog:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
>> (and below)
>>
>> This vote ends Saturday 2:30am GMT-5
>>
>> Please test the release and offer your vote:
>> [ ] Yes, release
>> [ ] No, don't release it (and please tell us why)
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>> ---------
>>
>> Release Notes - Wicket - Version 1.4.9
>>
>> ** Bug
>> * [WICKET-2741] - non-performant Collections.synchronizedMap() should
>> be replaced with ConcurrentMap
>> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in
>> its use of the model
>> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
>> retain selected but disabled items
>> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
>> causes NullPointerException when used in a Class within the root package
>> (i.e. it has no package declaration)
>> * [WICKET-2858] - WicketSessionFilter:
>> java.lang.IllegalArgumentException: Argument application can not be null
>> * [WICKET-2859] - Wrong package names in Examples
>> * [WICKET-2860] - Wrong name for swiss Application.properties
>> * [WICKET-2861] - getConvertedInput() returns null and
>> selectedValues.addAll tries adding it
>>
>> ** Improvement
>> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check
>> if form is multiPart
>> * [WICKET-2840] - Remove final on
>> AbstractRequestTargetUrlCodingStrategy#getMountPath()
>> * [WICKET-2846] - Store Application in InheritableThreadLocal instead
>> of ThreadLocal
>> * [WICKET-2855] - Constructor of RedirectRequestTarget does not
>> validate URL
>> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
>> * [WICKET-2870] - Fix hungarian translation for Wizard
>> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>>
>>
>>
>>
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
+1 - Yes, release.
I understand that some don't like this because of the
InheritableThreadLocal. But, I have not seen anything that proves that it
will cause a bug. It's my understanding that it:
- does work for the one hedge case that it was requested for (starting
short-lived threads from the request thread)
- does not break other things (if you are using pooled executors, etc)
- does not add any extra complexity to our codebase
In that case, I'm in favor of leaving it. However, considering the very
slight value that it adds, if someone conclusively proves that it breaks
existing applications (that are not doing something stupid), then I am in
favor of reverting it for the next release. It just does not have any
proven detrimental effects that should delay this release and the benefits
of the other fixes / enhancements.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 2:35 AM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> ---------
>
> Release Notes - Wicket - Version 1.4.9
>
> ** Bug
> * [WICKET-2741] - non-performant Collections.synchronizedMap() should
> be replaced with ConcurrentMap
> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in
> its use of the model
> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
> retain selected but disabled items
> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
> causes NullPointerException when used in a Class within the root package
> (i.e. it has no package declaration)
> * [WICKET-2858] - WicketSessionFilter:
> java.lang.IllegalArgumentException: Argument application can not be null
> * [WICKET-2859] - Wrong package names in Examples
> * [WICKET-2860] - Wrong name for swiss Application.properties
> * [WICKET-2861] - getConvertedInput() returns null and
> selectedValues.addAll tries adding it
>
> ** Improvement
> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check
> if form is multiPart
> * [WICKET-2840] - Remove final on
> AbstractRequestTargetUrlCodingStrategy#getMountPath()
> * [WICKET-2846] - Store Application in InheritableThreadLocal instead
> of ThreadLocal
> * [WICKET-2855] - Constructor of RedirectRequestTarget does not
> validate URL
> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
> * [WICKET-2870] - Fix hungarian translation for Wizard
> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>
>
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Igor Vaynberg <ig...@gmail.com>.
+1
-igor
On Wed, May 19, 2010 at 12:35 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> ---------
>
> Release Notes - Wicket - Version 1.4.9
>
> ** Bug
> * [WICKET-2741] - non-performant Collections.synchronizedMap() should be
> replaced with ConcurrentMap
> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its
> use of the model
> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
> retain selected but disabled items
> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
> causes NullPointerException when used in a Class within the root package
> (i.e. it has no package declaration)
> * [WICKET-2858] - WicketSessionFilter:
> java.lang.IllegalArgumentException: Argument application can not be null
> * [WICKET-2859] - Wrong package names in Examples
> * [WICKET-2860] - Wrong name for swiss Application.properties
> * [WICKET-2861] - getConvertedInput() returns null and
> selectedValues.addAll tries adding it
>
> ** Improvement
> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if
> form is multiPart
> * [WICKET-2840] - Remove final on
> AbstractRequestTargetUrlCodingStrategy#getMountPath()
> * [WICKET-2846] - Store Application in InheritableThreadLocal instead of
> ThreadLocal
> * [WICKET-2855] - Constructor of RedirectRequestTarget does not validate
> URL
> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
> * [WICKET-2870] - Fix hungarian translation for Wizard
> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 19/05/2010 16:37, tetsuo wrote:
> On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes<
> adrianosf@gmail.com> wrote:
>
>
>> I can't, however, do it now. But I would have no reason to do it knowing
>> some folks just consider a normal thing restart the container to update the
>> application. So if Wicket devs are in this way, I could write no quickstart
>> to convince.
>>
>>
> Cara, agora você está sendo um grande babacão...
>
Sorry, but I'm not a child (as you seems to be) to have a flame war with
you.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by tetsuo <ro...@gmail.com>.
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> I can't, however, do it now. But I would have no reason to do it knowing
> some folks just consider a normal thing restart the container to update the
> application. So if Wicket devs are in this way, I could write no quickstart
> to convince.
>
Cara, agora você está sendo um grande babacão...
What they are trying to say is that there is no reason to believe that there
is an issue regarding the InheritableThreadLocal and application redeploys,
but your *unproven* doubt, thus submitting a test case would make the issue
clear.
Guice, by its use of thread locals, and considering that Java thread locals
> are not ideal, have the same type of bug. They could solve it with an API to
> close a thing, but they don't. They could ship some fancy classes that may
> work (accordingly to old @crazybob says) in some cases but they also didn't.
> So if you redeploy an app with Guice in Tomcat, it logs about a thread local
> leak.
>
Is Guice's issue related to child thread creation (thus related to our
issue)? Or is it just some clean-up they don't do (which is not related to
our issue at all)?
> It's going to do the same thing with Wicket.
>
Only if you leave request-created threads to run indefinitely. But this
would be a bug in *your *code, not in Wicket.
Re: [vote] Release Wicket 1.4.9
Posted by Johan Compagner <jc...@gmail.com>.
Exactly...
the InheritableThreadLocal is never a problem, its the thread itself not
what it possess
in the other thread this example is given:
final Application application = Application.get();
new Thread(new Runnable()
{
run() {application.xxx}
}).start();
if that thread doesnt die on a redeploy, you have the exact same leak.....
There is no difference what so ever. Its the thread/runnable object holding
on to a application instance.
But i dont mind if that InheritableThreadLocal is reverted, because i dont
see a big win in that anyway
starting new threads like above can be handled as above, but doing the above
thing or with InheritableThreadLocal is a bad design anyway
You shouldnt never just start threads for a request... Then it is so easy to
completely bomb out your server.. just hit that same request 10000 times....
Use pooling for that with a max number of threads doing what you want to
do..
If people would like we could introduce a getExecutor() in (Web)Application
and we handle the Application.set/unset for you in the Executor threads.
We could give you there options for a scheduled or none scheduled and so on.
Then creating threads on the fly isnt needed, there is no need to set the
application anywhere just use the wicket executor...
johan
On Wed, May 19, 2010 at 21:36, Juliano Viana <ju...@logicstyle.com> wrote:
> Hi Adriano,
>
> If your application creates (or uses a library that creates) threads that
> don't die when the application is redeployed then you will have a memory
> leak no matter what Wicket does.
> If, on the other hand, all your theads are well behaved and die properly
> when your application is redeployed, you have no memory leak even with
> InheritableThreadLocal.
>
> So using InheritableThreadLocal or not will not make any difference in this
> case.
>
> Regards,
> - Juliano
>
>
>
>
> On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes <
> adrianosf@gmail.com> wrote:
>
> > On 19/05/2010 15:57, Jeremy Thomerson wrote:
> >
> >> Here's how you create a quickstart:
> >> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
> >>
> >> If you find that there is a bug, you zip your quickstart directory and
> >> attach it to a JIRA issue. Then we fix it and build a new release and
> >> start
> >> a new vote (if the bug is serious enough).
> >>
> >>
> >>
> > I know, I know... For example, the ones I have in Jira and got closed
> > without analyze, or the ones I attached with fixes.
> >
> > I can't, however, do it now. But I would have no reason to do it knowing
> > some folks just consider a normal thing restart the container to update
> the
> > application. So if Wicket devs are in this way, I could write no
> quickstart
> > to convince.
> >
> > Guice, by its use of thread locals, and considering that Java thread
> locals
> > are not ideal, have the same type of bug. They could solve it with an API
> to
> > close a thing, but they don't. They could ship some fancy classes that
> may
> > work (accordingly to old @crazybob says) in some cases but they also
> didn't.
> > So if you redeploy an app with Guice in Tomcat, it logs about a thread
> local
> > leak.
> >
> > It's going to do the same thing with Wicket.
> >
> >
> > Adriano
> >
> >
>
Re: [vote] Release Wicket 1.4.9
Posted by Juliano Viana <ju...@logicstyle.com>.
Hi Adriano,
If your application creates (or uses a library that creates) threads that
don't die when the application is redeployed then you will have a memory
leak no matter what Wicket does.
If, on the other hand, all your theads are well behaved and die properly
when your application is redeployed, you have no memory leak even with
InheritableThreadLocal.
So using InheritableThreadLocal or not will not make any difference in this
case.
Regards,
- Juliano
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 19/05/2010 15:57, Jeremy Thomerson wrote:
>
>> Here's how you create a quickstart:
>> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
>>
>> If you find that there is a bug, you zip your quickstart directory and
>> attach it to a JIRA issue. Then we fix it and build a new release and
>> start
>> a new vote (if the bug is serious enough).
>>
>>
>>
> I know, I know... For example, the ones I have in Jira and got closed
> without analyze, or the ones I attached with fixes.
>
> I can't, however, do it now. But I would have no reason to do it knowing
> some folks just consider a normal thing restart the container to update the
> application. So if Wicket devs are in this way, I could write no quickstart
> to convince.
>
> Guice, by its use of thread locals, and considering that Java thread locals
> are not ideal, have the same type of bug. They could solve it with an API to
> close a thing, but they don't. They could ship some fancy classes that may
> work (accordingly to old @crazybob says) in some cases but they also didn't.
> So if you redeploy an app with Guice in Tomcat, it logs about a thread local
> leak.
>
> It's going to do the same thing with Wicket.
>
>
> Adriano
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Wed, May 19, 2010 at 2:20 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 19/05/2010 15:57, Jeremy Thomerson wrote:
>
>> Here's how you create a quickstart:
>> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
>>
>> If you find that there is a bug, you zip your quickstart directory and
>> attach it to a JIRA issue. Then we fix it and build a new release and
>> start
>> a new vote (if the bug is serious enough).
>>
>>
>>
> I know, I know... For example, the ones I have in Jira and got closed
> without analyze, or the ones I attached with fixes.
>
Which ones? We don't close any without looking at them first. Please bring
these to our attention on another thread - not this vote thread.
> I can't, however, do it now. But I would have no reason to do it knowing
> some folks just consider a normal thing restart the container to update the
> application. So if Wicket devs are in this way, I could write no quickstart
> to convince.
>
Look, none of the Wicket devs have said you have to restart the container.
All we have said is that you are complaining that "I think there might be a
bug", and have shown no proof. As many people have said - on this thread
and your other one - the bug will be YOURS if YOU are leaving threads
running past a redeploy. So, we still have no proof that there is a bug.
Guice, by its use of thread locals, and considering that Java thread locals
> are not ideal, have the same type of bug. They could solve it with an API to
> close a thing, but they don't. They could ship some fancy classes that may
> work (accordingly to old @crazybob says) in some cases but they also didn't.
> So if you redeploy an app with Guice in Tomcat, it logs about a thread local
> leak.
>
I don't care what Guice does. However, I do care if there's a bug in
Wicket. If there is, I'll try to fix it. But you must show the bug - I'm
not going to do free development to prove that your thesis is correct.
Finally, please take this off the vote thread. This thread is for voting
whether or not the release should be released. Our devs spend hours
building these releases, and then we open a vote, and someone always whines
that they didn't get what they wanted. But, if someone brings up VALID bug
and SHOWS SOME PROOF that it is really a bug (or it's blatantly obvious),
then we again spend hours building a new release. But, again, I don't work
for you, and I will not spend hours of my day proving your thesis. I've
already spent enough time just trying to ask you nicely to submit something
that proves that there's a bug in our code. The only thing we've proven so
far is that, *yes* a bad developer can write bad code that results in bad
consequences.
Jeremy Thomerson
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 19/05/2010 15:57, Jeremy Thomerson wrote:
> Here's how you create a quickstart:
> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
>
> If you find that there is a bug, you zip your quickstart directory and
> attach it to a JIRA issue. Then we fix it and build a new release and start
> a new vote (if the bug is serious enough).
>
>
I know, I know... For example, the ones I have in Jira and got closed
without analyze, or the ones I attached with fixes.
I can't, however, do it now. But I would have no reason to do it knowing
some folks just consider a normal thing restart the container to update
the application. So if Wicket devs are in this way, I could write no
quickstart to convince.
Guice, by its use of thread locals, and considering that Java thread
locals are not ideal, have the same type of bug. They could solve it
with an API to close a thing, but they don't. They could ship some fancy
classes that may work (accordingly to old @crazybob says) in some cases
but they also didn't. So if you redeploy an app with Guice in Tomcat, it
logs about a thread local leak.
It's going to do the same thing with Wicket.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Here's how you create a quickstart:
http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
If you find that there is a bug, you zip your quickstart directory and
attach it to a JIRA issue. Then we fix it and build a new release and start
a new vote (if the bug is serious enough).
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 1:55 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 19/05/2010 15:48, James Carman wrote:
>
>> Do you have a quickstart application that exhibits this behavior?
>>
>>
> How would I could do it?
>
> This requires someone willing to change the code (if there is a problem) to
> redeploy the application with have previously created a thread.
>
> About the sun bug, it is still open, so you may pass the ball or deal with
> it.
>
>
> Adriano
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 19/05/2010 15:48, James Carman wrote:
> Do you have a quickstart application that exhibits this behavior?
>
How would I could do it?
This requires someone willing to change the code (if there is a problem)
to redeploy the application with have previously created a thread.
About the sun bug, it is still open, so you may pass the ball or deal
with it.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
Do you have a quickstart application that exhibits this behavior?
On Wed, May 19, 2010 at 2:44 PM, Adriano dos Santos Fernandes
<ad...@gmail.com> wrote:
> On 19/05/2010 14:49, Jeremy Thomerson wrote:
>>
>> How about we put the request back on you:
>>
>> Please prove that WICKET-2846 DOES introduce a nasty regression.
>>
>> This is much easier to prove / disprove than what you request.
>>
>
> Jeremy, as an open source developer, I understand your position and what you
> said. However, I also understand that the Wicket team could consider the
> problem I'm bringing to you. I'm sure your team could understand what I
> said, and may explain if I'm wrong. My experience with this, however, is
> that it make Wicket another piece of the stack to introduce an evil problem.
>
> See the bug I shown, for example. Guice team just make they counterpart open
> till now. Wicket could do the same, but as this is a new "improvement", it
> looks for me that its consequence was not well know, as this isn't essential
> for the framework.
>
> As a user, needing to do our applications, we haven't even time to upgrade,
> so we're still in 1.4.1.
>
> As my vote didn't really count (it's non binding, after all), voting against
> is just a way to show my in-satisfaction with something I considered a
> problem. Note that I have (re)opened bug reports that matter for us, and I'm
> not one that vote against due to it.
>
>
> Adriano
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Some comments inline.
On Wed, May 19, 2010 at 1:44 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 19/05/2010 14:49, Jeremy Thomerson wrote:
>
>> How about we put the request back on you:
>>
>> Please prove that WICKET-2846 DOES introduce a nasty regression.
>>
>> This is much easier to prove / disprove than what you request.
>>
>>
> Jeremy, as an open source developer, I understand your position and what
> you said. However, I also understand that the Wicket team could consider the
> problem I'm bringing to you. I'm sure your team could understand what I
> said, and may explain if I'm wrong. My experience with this, however, is
> that it make Wicket another piece of the stack to introduce an evil problem.
>
Yes, we can (and will) consider it. And we can understand it. But you
can't say that Wicket "introduce[s] an evil problem" - since you yourself
have said that you do NOT know if it introduces a problem.
See the bug I shown, for example. Guice team just make they counterpart open
> till now. Wicket could do the same, but as this is a new "improvement", it
> looks for me that its consequence was not well know, as this isn't essential
> for the framework.
>
I'm not sure what you mean about Guice.
> As a user, needing to do our applications, we haven't even time to upgrade,
> so we're still in 1.4.1.
>
> As my vote didn't really count (it's non binding, after all), voting
> against is just a way to show my in-satisfaction with something I considered
> a problem. Note that I have (re)opened bug reports that matter for us, and
> I'm not one that vote against due to it.
>
But we still value votes. But, you can't vote against something because you
*think* it *may* *possibly* have a bug. If, however, you could spend
fifteen to thirty minutes creating a quickstart that proves that there is a
bug, then we would probably vote against this release ourselves. That's the
reason we open it up to the dev list - so that people can test that there
are not regressions.
Bottom line is that we fix bugs, but we can't go and do the legwork for
everyone who says "oh, I think this may be a bug". There are very
reasonable responses on the other thread as to why this will *not* create a
bug - that if the threads are still running, it's a bug in why you're
running threads still during a redeploy. The reference to the application
that gets copied in the InheritableThreadLocal will die when the thread
does. So, how will this introduce a bug?
--
Jeremy Thomerson
http://www.wickettraining.com
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 19/05/2010 14:49, Jeremy Thomerson wrote:
> How about we put the request back on you:
>
> Please prove that WICKET-2846 DOES introduce a nasty regression.
>
> This is much easier to prove / disprove than what you request.
>
Jeremy, as an open source developer, I understand your position and what
you said. However, I also understand that the Wicket team could consider
the problem I'm bringing to you. I'm sure your team could understand
what I said, and may explain if I'm wrong. My experience with this,
however, is that it make Wicket another piece of the stack to introduce
an evil problem.
See the bug I shown, for example. Guice team just make they counterpart
open till now. Wicket could do the same, but as this is a new
"improvement", it looks for me that its consequence was not well know,
as this isn't essential for the framework.
As a user, needing to do our applications, we haven't even time to
upgrade, so we're still in 1.4.1.
As my vote didn't really count (it's non binding, after all), voting
against is just a way to show my in-satisfaction with something I
considered a problem. Note that I have (re)opened bug reports that
matter for us, and I'm not one that vote against due to it.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
How about we put the request back on you:
Please prove that WICKET-2846 DOES introduce a nasty regression.
This is much easier to prove / disprove than what you request.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 12:43 PM, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 19/05/2010 04:35, Jeremy Thomerson wrote:
>
>> This vote is to release wicket 1.4.9
>>
>> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
>> Artifacts:
>> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
>> Maven repo:
>> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
>> Changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
>> (and below)
>>
>> This vote ends Saturday 2:30am GMT-5
>>
>> Please test the release and offer your vote:
>> [ ] Yes, release
>> [ ] No, don't release it (and please tell us why)
>>
>>
> [X ] No, don't release it, at least until someone guarantees WICKET-2846 is
> not going to introduce a nasty regression.
>
>
> Adriano
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 19/05/2010 04:35, Jeremy Thomerson wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
[X ] No, don't release it, at least until someone guarantees WICKET-2846
is not going to introduce a nasty regression.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Jan Kriesten <kr...@mail.footprint.de>.
> Please test the release and offer your vote:
> [x] Yes, release
> [ ] No, don't release it (and please tell us why)
Best regards, --- Jan.
Re: [vote] Release Wicket 1.4.9
Posted by Johan Compagner <jc...@gmail.com>.
+1
(i dont care about the InheritableThreadLocal, if there are really problems
with it we could back it out in the next release)
On Wed, May 19, 2010 at 09:35, Jeremy Thomerson
<je...@wickettraining.com>wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> ---------
>
> Release Notes - Wicket - Version 1.4.9
>
> ** Bug
> * [WICKET-2741] - non-performant Collections.synchronizedMap() should be
> replaced with ConcurrentMap
> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its
> use of the model
> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
> retain selected but disabled items
> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
> causes NullPointerException when used in a Class within the root package
> (i.e. it has no package declaration)
> * [WICKET-2858] - WicketSessionFilter:
> java.lang.IllegalArgumentException: Argument application can not be null
> * [WICKET-2859] - Wrong package names in Examples
> * [WICKET-2860] - Wrong name for swiss Application.properties
> * [WICKET-2861] - getConvertedInput() returns null and
> selectedValues.addAll tries adding it
>
> ** Improvement
> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if
> form is multiPart
> * [WICKET-2840] - Remove final on
> AbstractRequestTargetUrlCodingStrategy#getMountPath()
> * [WICKET-2846] - Store Application in InheritableThreadLocal instead of
> ThreadLocal
> * [WICKET-2855] - Constructor of RedirectRequestTarget does not validate
> URL
> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
> * [WICKET-2870] - Fix hungarian translation for Wizard
> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
The vote is now closed, and it passes with:
3 binding +1's
2 non-binding +1's
1 non-binding -1
and an ink cartridge in an apple tree.
The announcement will come after the mirrors are sync'd.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 2:35 AM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> ---------
>
> Release Notes - Wicket - Version 1.4.9
>
> ** Bug
> * [WICKET-2741] - non-performant Collections.synchronizedMap() should
> be replaced with ConcurrentMap
> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in
> its use of the model
> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
> retain selected but disabled items
> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
> causes NullPointerException when used in a Class within the root package
> (i.e. it has no package declaration)
> * [WICKET-2858] - WicketSessionFilter:
> java.lang.IllegalArgumentException: Argument application can not be null
> * [WICKET-2859] - Wrong package names in Examples
> * [WICKET-2860] - Wrong name for swiss Application.properties
> * [WICKET-2861] - getConvertedInput() returns null and
> selectedValues.addAll tries adding it
>
> ** Improvement
> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check
> if form is multiPart
> * [WICKET-2840] - Remove final on
> AbstractRequestTargetUrlCodingStrategy#getMountPath()
> * [WICKET-2846] - Store Application in InheritableThreadLocal instead
> of ThreadLocal
> * [WICKET-2855] - Constructor of RedirectRequestTarget does not
> validate URL
> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
> * [WICKET-2870] - Fix hungarian translation for Wizard
> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>
>
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
That's the thing - we haven't even discussed IF we would back it out in a
future release. Has anybody given *any* evidence that this actually breaks
something that wouldn't already be broken? If someone does, I'm fine with
backing it out. But, we don't think it will break any existing
applications, so there's no reason to waste the effort that already went
into this release. Why throw away all of the other enhancements* for the
sake of this non-broken thing that people have unfounded exception to?
* including the big performance gain in the broken injector, which
is WICKET-2875 - not explicitly mentioned in the release notes because I
overlooked it since it was closed as duplicate to WICKET-2741
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 20, 2010 at 8:28 PM, James Carman <ja...@carmanconsulting.com>wrote:
> Well, you guys can do what you want with the release. It's your baby.
> I'm giving up my argument because it really doesn't matter to me
> (I'll just wait for the later release when this is backed out) and my
> vote doesn't "count" anyway. I don't know that I would necessarily -1
> anyway if I could. I would probably be -0. I don't think it should
> be released with something in it that you know you're going to back
> out in a later release. Apparently that's just me, though.
>
> On Thu, May 20, 2010 at 9:19 PM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
> > That's actually part of what I'm saying. Right now, if you start a
> thread
> > for AppA from a request in AppB, you are *not* using Application.get().
> You
> > *must* be passing the Application in some way to the thread. So, this
> > doesn't break that functionality. What I was saying about what's
> "already
> > broken" is if you are inadvertently starting a thread for AppA in a
> request
> > from AppB, that's currently a bug, and nothing we're doing will either
> make
> > that better or worse.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Thu, May 20, 2010 at 7:40 PM, James Carman <
> james@carmanconsulting.com>wrote:
> >
> >> That's not an existing problem because the application threadlocal isn't
> >> propagated to the pooled thread.
> >>
> >> On May 20, 2010 6:39 PM, "Jeremy Thomerson" <je...@wickettraining.com>
> >> wrote:
> >>
> >> You would only get an Application in a thread that was started from a
> >> request thread. You wouldn't start a thread for AppB from a request in
> >> AppA. The only chance of getting that cross-over would be if you
> started
> >> threads in AppA that were later pooled for AppB - but that would be an
> >> existing problem.
> >>
> >>
> >> --
> >> Jeremy Thomerson
> >> http://www.wickettraining.com
> >>
> >>
> >> On Thu, May 20, 2010 at 5:22 PM, James Carman <
> james@carmanconsulting.com
> >> >wrote:
> >>
> >>
> >> > What if someone has two applications running in the same webapp that
> >> > are handling two different...
> >>
> >
>
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
Well, you guys can do what you want with the release. It's your baby.
I'm giving up my argument because it really doesn't matter to me
(I'll just wait for the later release when this is backed out) and my
vote doesn't "count" anyway. I don't know that I would necessarily -1
anyway if I could. I would probably be -0. I don't think it should
be released with something in it that you know you're going to back
out in a later release. Apparently that's just me, though.
On Thu, May 20, 2010 at 9:19 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> That's actually part of what I'm saying. Right now, if you start a thread
> for AppA from a request in AppB, you are *not* using Application.get(). You
> *must* be passing the Application in some way to the thread. So, this
> doesn't break that functionality. What I was saying about what's "already
> broken" is if you are inadvertently starting a thread for AppA in a request
> from AppB, that's currently a bug, and nothing we're doing will either make
> that better or worse.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, May 20, 2010 at 7:40 PM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> That's not an existing problem because the application threadlocal isn't
>> propagated to the pooled thread.
>>
>> On May 20, 2010 6:39 PM, "Jeremy Thomerson" <je...@wickettraining.com>
>> wrote:
>>
>> You would only get an Application in a thread that was started from a
>> request thread. You wouldn't start a thread for AppB from a request in
>> AppA. The only chance of getting that cross-over would be if you started
>> threads in AppA that were later pooled for AppB - but that would be an
>> existing problem.
>>
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>> On Thu, May 20, 2010 at 5:22 PM, James Carman <james@carmanconsulting.com
>> >wrote:
>>
>>
>> > What if someone has two applications running in the same webapp that
>> > are handling two different...
>>
>
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
That's actually part of what I'm saying. Right now, if you start a thread
for AppA from a request in AppB, you are *not* using Application.get(). You
*must* be passing the Application in some way to the thread. So, this
doesn't break that functionality. What I was saying about what's "already
broken" is if you are inadvertently starting a thread for AppA in a request
from AppB, that's currently a bug, and nothing we're doing will either make
that better or worse.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 20, 2010 at 7:40 PM, James Carman <ja...@carmanconsulting.com>wrote:
> That's not an existing problem because the application threadlocal isn't
> propagated to the pooled thread.
>
> On May 20, 2010 6:39 PM, "Jeremy Thomerson" <je...@wickettraining.com>
> wrote:
>
> You would only get an Application in a thread that was started from a
> request thread. You wouldn't start a thread for AppB from a request in
> AppA. The only chance of getting that cross-over would be if you started
> threads in AppA that were later pooled for AppB - but that would be an
> existing problem.
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
> On Thu, May 20, 2010 at 5:22 PM, James Carman <james@carmanconsulting.com
> >wrote:
>
>
> > What if someone has two applications running in the same webapp that
> > are handling two different...
>
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
That's not an existing problem because the application threadlocal isn't
propagated to the pooled thread.
On May 20, 2010 6:39 PM, "Jeremy Thomerson" <je...@wickettraining.com>
wrote:
You would only get an Application in a thread that was started from a
request thread. You wouldn't start a thread for AppB from a request in
AppA. The only chance of getting that cross-over would be if you started
threads in AppA that were later pooled for AppB - but that would be an
existing problem.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 20, 2010 at 5:22 PM, James Carman <james@carmanconsulting.com
>wrote:
> What if someone has two applications running in the same webapp that
> are handling two different...
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
You would only get an Application in a thread that was started from a
request thread. You wouldn't start a thread for AppB from a request in
AppA. The only chance of getting that cross-over would be if you started
threads in AppA that were later pooled for AppB - but that would be an
existing problem.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 20, 2010 at 5:22 PM, James Carman <ja...@carmanconsulting.com>wrote:
> What if someone has two applications running in the same webapp that
> are handling two different customers? What if during development,
> they just happen to get the correct instance of the Application object
> and they think everything is working just fine. Then, in production,
> they get crossed up and the thread that's supposed to be running for
> customer A gets access to customer B's application and sends an email
> saying "Customer B would like to thank you for your order."
>
> On Thu, May 20, 2010 at 6:14 PM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
> > But it also don't break anything with the ITL, and it doesn't add more
> > complexity. So, in that case, why should we remove the ITL?
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Thu, May 20, 2010 at 4:42 PM, James Carman <
> james@carmanconsulting.com>wrote:
> >
> >> Starting this short-lived thread within the context of the request
> >> thread is the only place where using the ITL works correctly. All the
> >> other usecases (which are both more probable and more advisable) don't
> >> work reliably or at all.
> >>
> >> On Thu, May 20, 2010 at 4:17 PM, Alex Objelean <alex.objelean@gmail.com
> >
> >> wrote:
> >> >
> >> > I do not agree...
> >> > Maybe you didn't understand completely the use-case:
> >> >
> >> > public class MyPage extends Page {
> >> > @SpringBean
> >> > private MyService service;
> >> > //perform a polling of long running process triggered by a button
> click
> >> > onClickButton() {
> >> > new Thread() {
> >> > run() {
> >> > service.executeLongRunningProcess();
> >> > }
> >> > }.start();
> >> > }
> >> > }
> >> >
> >> > The following example won't work well if the Application is not stored
> in
> >> > InheritableThreadLocal. The reason why it doesn't work, as I
> understand
> >> > that, is because @SpringBean lookup depends on Application instance
> which
> >> is
> >> > not accessible from within the thread. Having it stored inside of ITL
> >> would
> >> > solve the problem.
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >>
> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
> >> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >
> >>
> >
>
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
What if someone has two applications running in the same webapp that
are handling two different customers? What if during development,
they just happen to get the correct instance of the Application object
and they think everything is working just fine. Then, in production,
they get crossed up and the thread that's supposed to be running for
customer A gets access to customer B's application and sends an email
saying "Customer B would like to thank you for your order."
On Thu, May 20, 2010 at 6:14 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> But it also don't break anything with the ITL, and it doesn't add more
> complexity. So, in that case, why should we remove the ITL?
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, May 20, 2010 at 4:42 PM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> Starting this short-lived thread within the context of the request
>> thread is the only place where using the ITL works correctly. All the
>> other usecases (which are both more probable and more advisable) don't
>> work reliably or at all.
>>
>> On Thu, May 20, 2010 at 4:17 PM, Alex Objelean <al...@gmail.com>
>> wrote:
>> >
>> > I do not agree...
>> > Maybe you didn't understand completely the use-case:
>> >
>> > public class MyPage extends Page {
>> > @SpringBean
>> > private MyService service;
>> > //perform a polling of long running process triggered by a button click
>> > onClickButton() {
>> > new Thread() {
>> > run() {
>> > service.executeLongRunningProcess();
>> > }
>> > }.start();
>> > }
>> > }
>> >
>> > The following example won't work well if the Application is not stored in
>> > InheritableThreadLocal. The reason why it doesn't work, as I understand
>> > that, is because @SpringBean lookup depends on Application instance which
>> is
>> > not accessible from within the thread. Having it stored inside of ITL
>> would
>> > solve the problem.
>> >
>> >
>> > --
>> > View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
>> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >
>>
>
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 21/05/2010 11:24, Jeremy Thomerson wrote:
> So, again, what you're saying is "if you already
> have a broken application, it will stay broken". Okay, I'm fine with that.
>
I would have to make more hacks as clear/re-set wicket application, to
not leak *more* things that it leaks by default. The Java bug (related
to context classloader) leaks only classes (and static instances).
Without do more hacks, it will also leak a chain of objects reachable by
Application (and user's extended class).
James explained better than me the other issues. I'd say it's much
better to offer hooks (and it's Wicket tradition way) than to put
something invasive in the core.
You also said about release 1.4.9 and delay a change. Well, once you
make users not worry (in theory) about the application in TLS, you're
going to make then angry if you revert it.
I'm now shutting-up. I've said many times all the issues it's going to
cause. It's the committers that have the final word, anyway...
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
>
>
>>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
>
> This is Java design fault, and as I said you could blame Java or at least
> try to deal with it. This may happen in others situations that Java library
> creates threads.
>
> This problem has a workaround. You could force creation of Java2D disposer
> thread using another context classloader. In Appliction.init I call this
> method:
>
> public static void initJava2D()
> {
> try
> {
> ClassLoader oldClassLoader =
> Thread.currentThread().getContextClassLoader();
> try
> {
> ClassLoader sysClassLoader =
> ClassLoader.getSystemClassLoader();
>
> Thread.currentThread().setContextClassLoader(sysClassLoader);
>
> // Força a criação do Java2D Disposer Thread
> sysClassLoader.loadClass("sun.java2d.Disposer");
>
> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
> javax.imageio.spi.IIORegistry.getDefaultInstance();
> }
> finally
> {
>
> Thread.currentThread().setContextClassLoader(oldClassLoader);
> }
>
>
> ClassLoader.getSystemClassLoader().loadClass("sun.java2d.Disposer");
> }
> catch (ClassNotFoundException e)
> {
> Logger log = LoggerFactory.getLogger(Util.class);
> log.error("Erro ao carregar sun.java2d.Disposer", e);
> }
> }
>
> If you put the application in ITL, you're going to break this workaround
> and ignore Java design fault I mentioned.
>
> If you not call this method, first time you need to do something with
> images you're going to create the Java2D disposer thread anyway, also
> leaking the application object and all of its references.
Thank you for finally posting code. However, what you are saying, restated
in my vernacular is: "if you already have something that's broken, it will
continue to be broken".
The problem is the leaking threads, NOT having the application available to
other threads. If you don't call a method similar to your init2d method,
you will have a thread leak. That would happen with 1.4.1, 1.4.7, 1.4.8, or
any other release, because it's a Java bug. What we have changed does not
make that any different. So, again, what you're saying is "if you already
have a broken application, it will stay broken". Okay, I'm fine with that.
--
Jeremy Thomerson
http://www.wickettraining.com
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 21/05/2010 08:24, Johan Compagner wrote:
> which leaks?
> give use a real wicket example where it leaks, which isnt the thread itself
> thats the leak.
>
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
This is Java design fault, and as I said you could blame Java or at
least try to deal with it. This may happen in others situations that
Java library creates threads.
This problem has a workaround. You could force creation of Java2D
disposer thread using another context classloader. In Appliction.init I
call this method:
public static void initJava2D()
{
try
{
ClassLoader oldClassLoader =
Thread.currentThread().getContextClassLoader();
try
{
ClassLoader sysClassLoader =
ClassLoader.getSystemClassLoader();
Thread.currentThread().setContextClassLoader(sysClassLoader);
// Força a criação do Java2D Disposer Thread
sysClassLoader.loadClass("sun.java2d.Disposer");
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
javax.imageio.spi.IIORegistry.getDefaultInstance();
}
finally
{
Thread.currentThread().setContextClassLoader(oldClassLoader);
}
ClassLoader.getSystemClassLoader().loadClass("sun.java2d.Disposer");
}
catch (ClassNotFoundException e)
{
Logger log = LoggerFactory.getLogger(Util.class);
log.error("Erro ao carregar sun.java2d.Disposer", e);
}
}
If you put the application in ITL, you're going to break this workaround
and ignore Java design fault I mentioned.
If you not call this method, first time you need to do something with
images you're going to create the Java2D disposer thread anyway, also
leaking the application object and all of its references.
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Johan Compagner <jc...@gmail.com>.
which leaks?
give use a real wicket example where it leaks, which isnt the thread itself
thats the leak.
On Fri, May 21, 2010 at 12:49, Adriano dos Santos Fernandes <
adrianosf@gmail.com> wrote:
> On 20/05/2010 19:14, Jeremy Thomerson wrote:
>
>> But it also don't break anything with the ITL, and it doesn't add more
>> complexity. So, in that case, why should we remove the ITL?
>>
>>
> It was already shown various reasons where it doesn't work well: leaks due
> to *Java class library threads*; problem with multiple Wicket applications
> in same web application; problem with shareable classes creating threads.
>
> Don't try to generalize specific problems. Before, Wicket was always in
> favor of letting hooks for people do specific things, why do that evil
> change now?
>
>
> Adriano
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
On 20/05/2010 19:14, Jeremy Thomerson wrote:
> But it also don't break anything with the ITL, and it doesn't add more
> complexity. So, in that case, why should we remove the ITL?
>
It was already shown various reasons where it doesn't work well: leaks
due to *Java class library threads*; problem with multiple Wicket
applications in same web application; problem with shareable classes
creating threads.
Don't try to generalize specific problems. Before, Wicket was always in
favor of letting hooks for people do specific things, why do that evil
change now?
Adriano
Re: [vote] Release Wicket 1.4.9
Posted by Jeremy Thomerson <je...@wickettraining.com>.
But it also don't break anything with the ITL, and it doesn't add more
complexity. So, in that case, why should we remove the ITL?
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 20, 2010 at 4:42 PM, James Carman <ja...@carmanconsulting.com>wrote:
> Starting this short-lived thread within the context of the request
> thread is the only place where using the ITL works correctly. All the
> other usecases (which are both more probable and more advisable) don't
> work reliably or at all.
>
> On Thu, May 20, 2010 at 4:17 PM, Alex Objelean <al...@gmail.com>
> wrote:
> >
> > I do not agree...
> > Maybe you didn't understand completely the use-case:
> >
> > public class MyPage extends Page {
> > @SpringBean
> > private MyService service;
> > //perform a polling of long running process triggered by a button click
> > onClickButton() {
> > new Thread() {
> > run() {
> > service.executeLongRunningProcess();
> > }
> > }.start();
> > }
> > }
> >
> > The following example won't work well if the Application is not stored in
> > InheritableThreadLocal. The reason why it doesn't work, as I understand
> > that, is because @SpringBean lookup depends on Application instance which
> is
> > not accessible from within the thread. Having it stored inside of ITL
> would
> > solve the problem.
> >
> >
> > --
> > View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
>
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
Starting this short-lived thread within the context of the request
thread is the only place where using the ITL works correctly. All the
other usecases (which are both more probable and more advisable) don't
work reliably or at all.
On Thu, May 20, 2010 at 4:17 PM, Alex Objelean <al...@gmail.com> wrote:
>
> I do not agree...
> Maybe you didn't understand completely the use-case:
>
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
>
> The following example won't work well if the Application is not stored in
> InheritableThreadLocal. The reason why it doesn't work, as I understand
> that, is because @SpringBean lookup depends on Application instance which is
> not accessible from within the thread. Having it stored inside of ITL would
> solve the problem.
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
Re: [vote] Release Wicket 1.4.9
Posted by tetsuo <ro...@gmail.com>.
You can return a Future from the @Async-annotated method.
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async
On Thu, May 20, 2010 at 5:52 PM, Alex Objelean <al...@gmail.com>wrote:
>
> Thanks for the hint. It is good to know about it.
> But how can you get the state of the task when using Async? When creating
> the thread myself, I can get an instance of Future and poll its state
> whenever I need.
>
> Alex
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225298.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
Re: [vote] Release Wicket 1.4.9
Posted by Alex Objelean <al...@gmail.com>.
Thanks for the hint. It is good to know about it.
But how can you get the state of the task when using Async? When creating
the thread myself, I can get an instance of Future and poll its state
whenever I need.
Alex
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225298.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Release Wicket 1.4.9
Posted by tetsuo <ro...@gmail.com>.
You could use Spring 3's @Async:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async
If you can upgrade to 3.0, that is..
On Thu, May 20, 2010 at 5:17 PM, Alex Objelean <al...@gmail.com>wrote:
>
> I do not agree...
> Maybe you didn't understand completely the use-case:
>
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
>
> The following example won't work well if the Application is not stored in
> InheritableThreadLocal. The reason why it doesn't work, as I understand
> that, is because @SpringBean lookup depends on Application instance which
> is
> not accessible from within the thread. Having it stored inside of ITL would
> solve the problem.
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
Re: [vote] Release Wicket 1.4.9
Posted by Johan Compagner <jc...@gmail.com>.
if you use a ThreadPoolExecutor class
then implement the methods:
/**
* Method invoked prior to executing the given Runnable in the
* given thread. This method is invoked by thread <tt>t</tt> that
* will execute task <tt>r</tt>, and may be used to re-initialize
* ThreadLocals, or to perform logging. Note: To properly nest
* multiple overridings, subclasses should generally invoke
* <tt>super.beforeExecute</tt> at the end of this method.
*
* @param t the thread that will run task r.
* @param r the task that will be executed.
*/
protected void beforeExecute(Thread t, Runnable r) { }
/**
* Method invoked upon completion of execution of the given
* Runnable. This method is invoked by the thread that executed
* the task. If non-null, the Throwable is the uncaught exception
* that caused execution to terminate abruptly. Note: To properly
* nest multiple overridings, subclasses should generally invoke
* <tt>super.afterExecute</tt> at the beginning of this method.
*
* @param r the runnable that has completed.
* @param t the exception that caused termination, or null if
* execution completed normally.
*/
protected void afterExecute(Runnable r, Throwable t) { }
and there you call Application.set() and Application.unset()
(yes i know it is not public api but it should be fine to call)
On Fri, May 21, 2010 at 13:34, Objelean Alex <al...@gmail.com>wrote:
> I actually do use a tread pool, but didn't include it in pseudocode for
> sake of simplicity. Anyway, the problem is the same. As long as Application
> instance is not available from the created thread, you cannot use
> @SpringBean field reference because it needs Application to lookup spring
> bean. If you have a different approach for this problem, I'm very open to
> see it.
>
> Alex
>
>
> On 21 May 2010 00:21, Johan Compagner <jc...@gmail.com> wrote:
>
>> But this is a very bad design you should use a thread pool for this and
>> not just start new threads when a button is pressed.
>>
>> So this change makes it easier to program badly....
>> Beter would be to have a wicket managed threadpool...
>>
>> ----- Original message -----
>> >
>> > I do not agree...
>> > Maybe you didn't understand completely the use-case:
>> >
>> > public class MyPage extends Page {
>> > @SpringBean
>> > private MyService service;
>> > //perform a polling of long running process triggered by a button
>> click
>> > onClickButton() {
>> > new Thread() {
>> > run() {
>> > service.executeLongRunningProcess();
>> > }
>> > }.start();
>> > }
>> > }
>> >
>> > The following example won't work well if the Application is not stored
>> in
>> > InheritableThreadLocal. The reason why it doesn't work, as I understand
>> > that, is because @SpringBean lookup depends on Application instance
>> which is
>> > not accessible from within the thread. Having it stored inside of ITL
>> would
>> > solve the problem.
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
>> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >
>>
>>
>
Re: [vote] Release Wicket 1.4.9
Posted by Objelean Alex <al...@gmail.com>.
I actually do use a tread pool, but didn't include it in pseudocode for sake
of simplicity. Anyway, the problem is the same. As long as Application
instance is not available from the created thread, you cannot use
@SpringBean field reference because it needs Application to lookup spring
bean. If you have a different approach for this problem, I'm very open to
see it.
Alex
On 21 May 2010 00:21, Johan Compagner <jc...@gmail.com> wrote:
> But this is a very bad design you should use a thread pool for this and
> not just start new threads when a button is pressed.
>
> So this change makes it easier to program badly....
> Beter would be to have a wicket managed threadpool...
>
> ----- Original message -----
> >
> > I do not agree...
> > Maybe you didn't understand completely the use-case:
> >
> > public class MyPage extends Page {
> > @SpringBean
> > private MyService service;
> > //perform a polling of long running process triggered by a button
> click
> > onClickButton() {
> > new Thread() {
> > run() {
> > service.executeLongRunningProcess();
> > }
> > }.start();
> > }
> > }
> >
> > The following example won't work well if the Application is not stored in
>
> > InheritableThreadLocal. The reason why it doesn't work, as I understand
> > that, is because @SpringBean lookup depends on Application instance which
> is
> > not accessible from within the thread. Having it stored inside of ITL
> would
> > solve the problem.
> >
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
>
>
Re: [vote] Release Wicket 1.4.9
Posted by Alex Objelean <al...@gmail.com>.
I do not agree...
Maybe you didn't understand completely the use-case:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button click
onClickButton() {
new Thread() {
run() {
service.executeLongRunningProcess();
}
}.start();
}
}
The following example won't work well if the Application is not stored in
InheritableThreadLocal. The reason why it doesn't work, as I understand
that, is because @SpringBean lookup depends on Application instance which is
not accessible from within the thread. Having it stored inside of ITL would
solve the problem.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I think we've come to agreement that the enhancement won't
really do what it was meant to do. So, why keep it?
On Thu, May 20, 2010 at 3:57 PM, Alex Objelean <al...@gmail.com> wrote:
>
> Reading the entire thread regarding WICKET-2846, shows that only one person
> is against this feature without even having a good reasoning. I don't think
> that this is enough to remove the feature from 1.4.9 release. I was the
> person who requested it and have a good use-case for it. Anyway, as many
> other people said before, there is absolutely no reason for worry.
>
> Alex
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225203.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
Re: [vote] Release Wicket 1.4.9
Posted by Alex Objelean <al...@gmail.com>.
Reading the entire thread regarding WICKET-2846, shows that only one person
is against this feature without even having a good reasoning. I don't think
that this is enough to remove the feature from 1.4.9 release. I was the
person who requested it and have a good use-case for it. Anyway, as many
other people said before, there is absolutely no reason for worry.
Alex
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225203.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Release Wicket 1.4.9
Posted by James Carman <ja...@carmanconsulting.com>.
I would say we probably need to re-think whether we want to release a
version of Wicket with WICKET-2846 included, since the conversation on
the other thread is making it seem like it's not a good idea.
On Wed, May 19, 2010 at 3:35 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> This vote is to release wicket 1.4.9
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/
> Artifacts:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist
> Maven repo:
> http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo
> Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&styleName=Html&version=12314962
> (and below)
>
> This vote ends Saturday 2:30am GMT-5
>
> Please test the release and offer your vote:
> [ ] Yes, release
> [ ] No, don't release it (and please tell us why)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> ---------
>
> Release Notes - Wicket - Version 1.4.9
>
> ** Bug
> * [WICKET-2741] - non-performant Collections.synchronizedMap() should be
> replaced with ConcurrentMap
> * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its
> use of the model
> * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not
> retain selected but disabled items
> * [WICKET-2856] - PackageStringResourceLoader.loadStringResource()
> causes NullPointerException when used in a Class within the root package
> (i.e. it has no package declaration)
> * [WICKET-2858] - WicketSessionFilter:
> java.lang.IllegalArgumentException: Argument application can not be null
> * [WICKET-2859] - Wrong package names in Examples
> * [WICKET-2860] - Wrong name for swiss Application.properties
> * [WICKET-2861] - getConvertedInput() returns null and
> selectedValues.addAll tries adding it
>
> ** Improvement
> * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if
> form is multiPart
> * [WICKET-2840] - Remove final on
> AbstractRequestTargetUrlCodingStrategy#getMountPath()
> * [WICKET-2846] - Store Application in InheritableThreadLocal instead of
> ThreadLocal
> * [WICKET-2855] - Constructor of RedirectRequestTarget does not validate
> URL
> * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum
> * [WICKET-2870] - Fix hungarian translation for Wizard
> * [WICKET-2879] - delegate isVisible in PanelCachingTab
>