Re: What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Guten Tag Sven Meier, am Dienstag, 1. Oktober 2019 um 20:53 schrieben Sie: > Actually you could argue whether it is practical that these events > are not delivered to invisible or disabled components by default - > something I wouldn't expect, since it requires to override > #canCallListener() or a clever solution like yours. +1, I was suprised as well in the past. AnnotationEventDispatcher is some kind of opt-in in the end already, so one can argue it should not care if to publish events or not at all. If receivers of events want to ignore some based on aspects like visibility of a component, if it's enabled or not etc., they could check that in the event handler on their own. Would have the benefit of being able to check that for each and every individual event (handler) as well. > IMHO we should make this configurable[...] Such a configuration has been explicitly removed in the past in favour of calling "canCallListener": https://github.com/wicketstuff/core/commit/f2ee61fb48259f9bdbf682713b12738e596d3cc1#diff-e8dc60d585cc63b237e8bb83a2814c3b https://github.com/wicketstuff/core/commit/f2ee61fb48259f9bdbf682713b12738e596d3cc1#diff-e1aa43fd3aadd18631700c7dd4c63179 So it might be worth it to consider re-introducing that configuration again, but with a changed default of "true" to send to invisible components. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Hi, I wasn't aware of that class and that usage of that method. First of all returning true from #canCallListener() might open security problems, because a browser might request disabled or invisible components - don't do this if you don't need to. So I'm wondering how I'm making sure to only return "true" in that call if AnnotationEventDispatcher is the caller? I don't see how that would be possible :/. Actually you could argue whether it is practical that these events are not delivered to invisible or disabled components by default - something I wouldn't expect, since it requires to override #canCallListener() or a clever solution like yours. IMHO we should make this configurable - calling #canCallListener() without method argument isn't helpful but rather dangerous (see above). Sven On 01.10.19 19:32, Thorsten Schöning wrote: Guten Tag Sven Meier, am Dienstag, 1. Oktober 2019 um 18:51 schrieben Sie: What methods are you iterating over in onEventMethods? That's not me, but AnotationEventDispatcher: https://github.com/wicketstuff/core/blob/master/annotationeventdispatcher-parent/annotationeventdispatcher/src/main/java/org/wicketstuff/event/annotation/AnnotationEventSink.java#L138 That is getting all methods annottated with "@OnEvent" and afterwards checking if the parent component of those methods is able to get events by calling "canCallListener" on the component: https://github.com/wicketstuff/core/blob/master/annotationeventdispatcher-parent/annotationeventdispatcher/src/main/java/org/wicketstuff/event/annotation/AnnotationEventSink.java#L187 The former implementation in Wicket 7 provided the method found during that call, so the component was able to recognize that AnnotationEventDispatcher is the caller. That is no longer possible, because the "Method" argument has been removed in WICKET-6137. So I'm wondering how I'm making sure to only return "true" in that call if AnnotationEventDispatcher is the caller? Or if I even need to at all? The docs for "canCallListener" read so that one should take extra care to not easily return "true" without good reasons to do so. And my reason only is AnnotationEventDispatcher forwarding some event I depend on even if the component is still invisible. Mit freundlichen Grüßen, Thorsten Schöning
Re: Overridden Application.getExceptionMapperProvider not called
> not enough Voodoo. ... or too much of it :P Sven On 01.10.19 20:34, Thorsten Schöning wrote: Guten Tag Thorsten Schöning, am Dienstag, 1. Oktober 2019 um 19:45 schrieben Sie: I've already cleared caches in the web server, tebuilt the app and such Voodoo. Any additional ideas? Thanks! Ignore that, not enough Voodoo. :-) After I additionally cleaned out things and rebuilt stuff etc.,my custom exception mapper works as expected. Mit freundlichen Grüßen, Thorsten Schöning
Re: Overridden Application.getExceptionMapperProvider not called
Guten Tag Thorsten Schöning, am Dienstag, 1. Oktober 2019 um 19:45 schrieben Sie: > I've already cleared caches in the web server, tebuilt the app and > such Voodoo. Any additional ideas? Thanks! Ignore that, not enough Voodoo. :-) After I additionally cleaned out things and rebuilt stuff etc.,my custom exception mapper works as expected. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Overridden Application.getExceptionMapperProvider not called
Hi all,
I'm migrating from Wicket 7 to 8 and have the problem that my custom
exception mapper is not called anymore. I'm simply extending
"AuthenticatedWebApplication" and overriding the following method:
>@Override
>public Supplier getExceptionMapperProvider()
>{
>return this.exMapProv;
>}
Eclipse says everything is OK, I can even set a valid breakpoint at
the return, but that never fires. Instead, if I set a breakpoint in
"Application" at the following place, I can see that
"getExceptionMapperProvider" uses the default implementation:
>public final RequestCycle createRequestCycle(final Request request,
> final Response response)
>{
>RequestCycleContext context = new RequestCycleContext(request,
> response,
>getRootRequestMapper(),
> getExceptionMapperProvider().get());
I've already cleared caches in the web server, tebuilt the app and
such Voodoo. Any additional ideas? Thanks!
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Guten Tag Sven Meier, am Dienstag, 1. Oktober 2019 um 18:51 schrieben Sie: > What methods are you iterating over in onEventMethods? That's not me, but AnotationEventDispatcher: https://github.com/wicketstuff/core/blob/master/annotationeventdispatcher-parent/annotationeventdispatcher/src/main/java/org/wicketstuff/event/annotation/AnnotationEventSink.java#L138 That is getting all methods annottated with "@OnEvent" and afterwards checking if the parent component of those methods is able to get events by calling "canCallListener" on the component: https://github.com/wicketstuff/core/blob/master/annotationeventdispatcher-parent/annotationeventdispatcher/src/main/java/org/wicketstuff/event/annotation/AnnotationEventSink.java#L187 The former implementation in Wicket 7 provided the method found during that call, so the component was able to recognize that AnnotationEventDispatcher is the caller. That is no longer possible, because the "Method" argument has been removed in WICKET-6137. So I'm wondering how I'm making sure to only return "true" in that call if AnnotationEventDispatcher is the caller? Or if I even need to at all? The docs for "canCallListener" read so that one should take extra care to not easily return "true" without good reasons to do so. And my reason only is AnnotationEventDispatcher forwarding some event I depend on even if the component is still invisible. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Hi Thorsten,
in Wicket 8 there's one method left only: it is always #onRequest().
What methods are you iterating over in onEventMethods?
Regards
Sven
On 01.10.19 16:29, Thorsten Schöning wrote:
Guten Tag Thorsten Schöning,
am Dienstag, 1. Oktober 2019 um 16:15 schrieben Sie:
public boolean canCallListener(Method method)
{
if (method.isAnnotationPresent(OnEvent.class))
{
return true;
}
return super.canCallListener(method);
}
That callback doesn't exist anymore and I'm wondering how I'm able to
recognize my custom event?[...]
That statement is misleading: I don't want to recognize my custom
event, but AnnotationEventDispatcher trying to send that to me
instead. AnnotationEventDispatcher gets all methods annotated using
"@OnEvent" and in Wicket 7 was checking if to dispatch an event to a
component using those methods.
for (Method method : onEventMethods)
{
if (canCallListenerInterface(sink, method))
{
That way I could be somewhat sure to only return "true" for my own
custom event. With removing the "Method"-argument I don't know how to
distinguish AnnotationEventDispatcher from everything else anymore.
Mit freundlichen Grüßen,
Thorsten Schöning
ApacheCon North America 2020, project participation
Hi, folks, (Note: You're receiving this email because you're on the dev@ list for one or more Apache Software Foundation projects.) For ApacheCon North America 2019, we asked projects to participate in the creation of project/topic specific tracks. This was very successful, with about 15 projects stepping up to curate the content for their track/summit/event. We need to know if you're going to do the same for 2020. This informs how large a venue we book for the event, how long the event runs, and many other considerations. If you intend to participate again in 2020, we need to hear from you on the plann...@apachecon.com mailing list. This is not a firm commitment, but we need to know if you're, say, 75% confident that you'll be participating. And, no, we do not have any details at all, but assume that it will be in roughly the same calendar space as this year's event, ie, somewhere in the August-October timeframe. Thanks. -- Rich Bowen VP Conferences The Apache Software Foundation @apachecon
Re: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
I use b222 and all is good here. On Tue, Oct 1, 2019, 19:22 Maxim Solodovnik wrote: > Is it possible it is caused by Java version? > Travis uses > > java version "1.8.0_151" > Java(TM) SE Runtime Environment (build 1.8.0_151-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) > > > > > > I locally using > > java version "1.8.0_201" > Java(TM) SE Runtime Environment (build 1.8.0_201-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) > > > > On Mon, 30 Sep 2019 at 22:04, Thorsten Schöning > wrote: > > > Guten Tag Martin Grigorov, > > am Montag, 30. September 2019 um 15:25 schrieben Sie: > > > > > It will be good to find what in your environment causes the problem. > > > Maybe it is some environment variable, or your system locale, or > > something > > > else. > > > > My Windows is pretty standard, I'm not even running AV-software, > > including on-board Defender. That has been disabled using group > > policies. The only difference to others is my German locale most > > likely. Looking at Process Monitor, Wicket seems to search for > > localized files for all test including HTML and text, never finds > > those for de_DE and all those other tests succeed anyway. Doesn't look > > like the actual problem to me. > > > > > For me this test passes. It must pass at Maxim's machine as well > because > > he > > > built the release. > > > Could someone else with Windows run the test and report ? > > > > I've found an additional way to make the build succeed WITHOUT > > ignoring the formerly mentioned test: Switching the option to reuse > > forked JMV by surefire to "false" in pom.xml. > > > > > false > > > > Switching between true and false make the build failing vs. > > succeeding. What's additionally interesting is that in case the build > > fails, executing the command line from the error message manually in > > some other cmd.exe seems to succeed: > > > > > cmd.exe /X /C ""C:\Program Files\Java\jdk-8\bin\java.exe" -Xmx1024m > -jar > > > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451\surefirebooter4577796592449395223.jar > > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451 > > 2019-09-30T16-38-42_368-jvmRun1 surefire9181599006974311426tmp > > surefire_07065828248506771667tmp"" > > > > > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG > > - 'main' released lock to page with id '1'\0D\0A > > > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG > > - 'main' notifying blocked threads\0D\0A > > > > > > 3,1,windows-1252,[org.apache.wicket.protocol.http.servlet.ServletWebRequest] > > DEBUG - Calculating context relative path from: context path > '/context'\2C > > filterPrefix 'servlet/'\2C uri '/context/servlet/'\0D\0A > > > > > > 6,1,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,shouldCreateTwoMonitorsForPagesThatAreNavigatedToTwice(org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest),null,null,null > > > > > > 2,1,org.apache.maven.surefire.junit4.JUnit4Provider,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,null,null,null > > > Z,0,BYE! > > > > Which very much reads like a proper "goodbye" like mentioned in the > > error message at the beginning. My feeling is that for some reason > > surefire is not able to properly recognize that goodbye in some > > combinations of tests anymore if those were run within the same JVM. > > > > > If there is JVM crash then there must be a hs_errPID.txt file in the > > Maven > > > process working folder. It will give you more information what went > > wrong. > > > > I don't find such file, neither searching the file system, nor looking > > at the logs of Process Monitor during running the build. > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > > > > -- > > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > > > Telefon...05151- 9468- 55 > > Fax...05151- 9468- 88 > > Mobil..0178-8 9468- 04 > > > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > > > > -- > WBR > Maxim aka solomax >
Re: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
Is it possible it is caused by Java version? Travis uses java version "1.8.0_151" Java(TM) SE Runtime Environment (build 1.8.0_151-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) I locally using java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) On Mon, 30 Sep 2019 at 22:04, Thorsten Schöning wrote: > Guten Tag Martin Grigorov, > am Montag, 30. September 2019 um 15:25 schrieben Sie: > > > It will be good to find what in your environment causes the problem. > > Maybe it is some environment variable, or your system locale, or > something > > else. > > My Windows is pretty standard, I'm not even running AV-software, > including on-board Defender. That has been disabled using group > policies. The only difference to others is my German locale most > likely. Looking at Process Monitor, Wicket seems to search for > localized files for all test including HTML and text, never finds > those for de_DE and all those other tests succeed anyway. Doesn't look > like the actual problem to me. > > > For me this test passes. It must pass at Maxim's machine as well because > he > > built the release. > > Could someone else with Windows run the test and report ? > > I've found an additional way to make the build succeed WITHOUT > ignoring the formerly mentioned test: Switching the option to reuse > forked JMV by surefire to "false" in pom.xml. > > > false > > Switching between true and false make the build failing vs. > succeeding. What's additionally interesting is that in case the build > fails, executing the command line from the error message manually in > some other cmd.exe seems to succeed: > > > cmd.exe /X /C ""C:\Program Files\Java\jdk-8\bin\java.exe" -Xmx1024m -jar > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451\surefirebooter4577796592449395223.jar > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451 > 2019-09-30T16-38-42_368-jvmRun1 surefire9181599006974311426tmp > surefire_07065828248506771667tmp"" > > > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG > - 'main' released lock to page with id '1'\0D\0A > > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG > - 'main' notifying blocked threads\0D\0A > > > 3,1,windows-1252,[org.apache.wicket.protocol.http.servlet.ServletWebRequest] > DEBUG - Calculating context relative path from: context path '/context'\2C > filterPrefix 'servlet/'\2C uri '/context/servlet/'\0D\0A > > > 6,1,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,shouldCreateTwoMonitorsForPagesThatAreNavigatedToTwice(org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest),null,null,null > > > 2,1,org.apache.maven.surefire.junit4.JUnit4Provider,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,null,null,null > > Z,0,BYE! > > Which very much reads like a proper "goodbye" like mentioned in the > error message at the beginning. My feeling is that for some reason > surefire is not able to properly recognize that goodbye in some > combinations of tests anymore if those were run within the same JVM. > > > If there is JVM crash then there must be a hs_errPID.txt file in the > Maven > > process working folder. It will give you more information what went > wrong. > > I don't find such file, neither searching the file system, nor looking > at the logs of Process Monitor during running the build. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > -- WBR Maxim aka solomax
Re: What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Guten Tag Thorsten Schöning,
am Dienstag, 1. Oktober 2019 um 16:15 schrieben Sie:
>> public boolean canCallListener(Method method)
>> {
>> if (method.isAnnotationPresent(OnEvent.class))
>> {
>> return true;
>> }
>>
>> return super.canCallListener(method);
>> }
> That callback doesn't exist anymore and I'm wondering how I'm able to
> recognize my custom event?[...]
That statement is misleading: I don't want to recognize my custom
event, but AnnotationEventDispatcher trying to send that to me
instead. AnnotationEventDispatcher gets all methods annotated using
"@OnEvent" and in Wicket 7 was checking if to dispatch an event to a
component using those methods.
> for (Method method : onEventMethods)
> {
> if (canCallListenerInterface(sink, method))
> {
That way I could be somewhat sure to only return "true" for my own
custom event. With removing the "Method"-argument I don't know how to
distinguish AnnotationEventDispatcher from everything else anymore.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
What's the replacement for Component.canCallListener(Method method) in Wicket 8?
Hi all,
I'm upgrading from Wicket 7 to Wicket 8 and seem to have a problem
with WICKET-6137[1]. That removed Component.canCallListener(Method)
which I'm using in the following circumstances:
One page with one form and additional panels to show the results of
the action done by submitting the form. The form provides those
results to the panels simply by publishing some custom event using the
parent page the form is associated with. The important thing to note is
that the panels showing the results are invisible by default until
the event with results arrive.
During implementing that with Wicket 7 I recognized that if the panels
are not visible, they don't receive the sent events as well. So I had
overriden "cannCallListenerInterface":
> public boolean canCallListener(Method method)
> {
> if (method.isAnnotationPresent(OnEvent.class))
> {
> return true;
> }
>
> return super.canCallListener(method);
> }
That callback doesn't exist anymore and I'm wondering how I'm able to
recognize my custom event? Or is the approach to not distinguish
anything, but only return "true" always?
From the docs of "canCallListener" I had the feeling it would be
better to be super careful on when to return "true". Or is my approach
using a custom event entirely the wrong track and you have better
ones? Thanks!
[1]: https://issues.apache.org/jira/browse/WICKET-6137
canCallListener(Method method)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: NPE at org.wicketstuff.rest.injection.InjectResourceTest.testInjection(InjectResourceTest.java:59)
Guten Tag Thorsten Schöning, am Montag, 30. September 2019 um 12:06 schrieben Sie: >> --- >> Test set: org.wicketstuff.rest.injection.InjectResourceTest >> --- >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.414 s <<< >> FAILURE! - in org.wicketstuff.rest.injection.InjectResourceTest >> testInjection(org.wicketstuff.rest.injection.InjectResourceTest) Time >> elapsed: 1.357 s <<< ERROR! >> java.lang.NullPointerException >> at >> org.wicketstuff.rest.injection.InjectResourceTest.testInjection(InjectResourceTest.java:59) Just in case anyone else comes across this thread: I'm building Wicket Stuff using a path with spaces and some places in the code use URL.getFile, which doesn't properly decode that. Instead of failing because of some missing path, resources for the test seemed to have simply not been provided as expected. Changing that to properly decode the URL fixes the build. https://github.com/wicketstuff/core/pull/678 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
