from:"Francesco Chicchiriccò"

On 2020/04/09 12:04:00, Sven Meier  wrote: 
> Hi Francesco,
> 
> I'll have to check what has changed here.
> 
> I wouldn't expect any problems with MockPageStore, but perhaps it 
> changed slightly.
> 
> Can you write a testcase that runs in Wicket 8 but fails in 9?

Not sure if I am able, but I'll try.
Meanwhile, should you get an enlightenment, please report.

Regards.

> On 09.04.20 12:20, Francesco Chicchiriccò wrote:
> > Hi all,
> > at Syncope we have been upgrading our Console and Enduser web applications 
> > from Wicket 8 to 9.0.0-M5, in our master branch.
> >
> > The process have been quite smooth effectively, with a single noticeable 
> > exception: in our tests we largely use WicketTester; we have verified, 
> > however, that Pages in the MockPageStore are incrementing their numericId 
> > during tests execution, even though they are still looked up by their 
> > initial numericId.
> >
> > We are using this workaround:
> >
> > https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125
> >
> > which is serving its purpose for the moment; please note that this was not 
> > needed with Wicket 8.
> >
> > Are we missing something or the one above is effectively a bug?
> >
> > Thanks for your support.
> > Regards.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Upgrade to Wicket 9: troubles with WicketTester and MockPageStore

On 2020/04/09 12:01:25, Martin Grigorov  wrote: 
> It is not my day today! :-)
> This is the second description of an issue here in users@ which I don't
> understand.

np Martin, I understand you completely :-)

> I'll let someone else try to help you.
> 
> On Thu, Apr 9, 2020 at 2:32 PM Francesco Chicchiriccò 
> wrote:
> 
> > On 2020/04/09 10:58:13, Martin Grigorov  wrote:
> > > Hi,
> > >
> > > Why do you need to use PageManager ?
> > > By default WicketTester uses MockPageManager without a backing PageStore.
> >
> > That was the simplest workaround I could find; for sure, without the
> > workaround, e.g. with simple "new WicketTester()" I have the behavior
> > described below.
> >
> > Regards.
> >
> > > On Thu, Apr 9, 2020 at 1:20 PM Francesco Chicchiriccò <
> > ilgro...@apache.org>
> > > wrote:
> > >
> > > > Hi all,
> > > > at Syncope we have been upgrading our Console and Enduser web
> > applications
> > > > from Wicket 8 to 9.0.0-M5, in our master branch.
> > > >
> > > > The process have been quite smooth effectively, with a single
> > noticeable
> > > > exception: in our tests we largely use WicketTester; we have verified,
> > > > however, that Pages in the MockPageStore are incrementing their
> > numericId
> > > > during tests execution, even though they are still looked up by their
> > > > initial numericId.
> > > >
> > > > We are using this workaround:
> > > >
> > > >
> > > >
> > https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125
> > > >
> > > > which is serving its purpose for the moment; please note that this was
> > not
> > > > needed with Wicket 8.
> > > >
> > > > Are we missing something or the one above is effectively a bug?
> > > >
> > > > Thanks for your support.
> > > > Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Upgrade to Wicket 9: troubles with WicketTester and MockPageStore

On 2020/04/09 10:58:13, Martin Grigorov  wrote: 
> Hi,
> 
> Why do you need to use PageManager ?
> By default WicketTester uses MockPageManager without a backing PageStore.

That was the simplest workaround I could find; for sure, without the 
workaround, e.g. with simple "new WicketTester()" I have the behavior described 
below.

Regards.
 
> On Thu, Apr 9, 2020 at 1:20 PM Francesco Chicchiriccò 
> wrote:
> 
> > Hi all,
> > at Syncope we have been upgrading our Console and Enduser web applications
> > from Wicket 8 to 9.0.0-M5, in our master branch.
> >
> > The process have been quite smooth effectively, with a single noticeable
> > exception: in our tests we largely use WicketTester; we have verified,
> > however, that Pages in the MockPageStore are incrementing their numericId
> > during tests execution, even though they are still looked up by their
> > initial numericId.
> >
> > We are using this workaround:
> >
> >
> > https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125
> >
> > which is serving its purpose for the moment; please note that this was not
> > needed with Wicket 8.
> >
> > Are we missing something or the one above is effectively a bug?
> >
> > Thanks for your support.
> > Regards.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Upgrade to Wicket 9: troubles with WicketTester and MockPageStore

Hi all,
at Syncope we have been upgrading our Console and Enduser web applications from 
Wicket 8 to 9.0.0-M5, in our master branch.

The process have been quite smooth effectively, with a single noticeable 
exception: in our tests we largely use WicketTester; we have verified, however, 
that Pages in the MockPageStore are incrementing their numericId during tests 
execution, even though they are still looked up by their initial numericId.

We are using this workaround:

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125

which is serving its purpose for the moment; please note that this was not 
needed with Wicket 8.

Are we missing something or the one above is effectively a bug?

Thanks for your support.
Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Test errors after upgrading to Wicket 8.7.0

2020-01-10 Thread Francesco Chicchiriccò

Worked like a charm, thanks!

https://github.com/apache/syncope/commit/f5f0bf05cd88e8d5ab6e682f7e1bb6f3c3249c82#diff-1b179dcf722c88b5094875ab9d08d6e3R65

Regards.

On 2020/01/10 13:02:20, Martin Grigorov  wrote: 
> On Fri, Jan 10, 2020 at 2:55 PM Francesco Chicchiriccò 
> wrote:
> 
> > On 2020/01/10 12:24:49, Martin Grigorov  wrote:
> > > Hi Francesco,
> > >
> > > This was a bug in Wicket, a security related one.
> > > You will need to fix your code.
> > >
> > > The change should look something like this:
> > >
> > >
> > > -   tester.getRequest().setParameter("select",
> > > page.option1.getValue());
> > > -   tester.getRequest().setParameter("text", "text is
> > required");
> > > -   tester.submitForm(page.form);
> > > +   final FormTester formTester2 =
> > tester.newFormTester("form");
> > > +   formTester2.setValue("select", "option1");
> > > +   formTester2.setValue("text", "text is required");
> > > +   formTester2.submit();
> > >
> > > from
> > >
> > https://gitbox.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=0c19cf8;hp=3d8f8b306a92cee71020a633be1d347177d7b7fc
> >
> > Thanks Martin.
> >
> > As I can see from above, you have a Form instance, which we don't have in
> > [2].
> >
> > Moreover, the problem only occurs with MockWebRequest, not with regular
> > operations (e.g. HttpServletRequest), hence I'd need to introduce a Form
> > only to let tests pass...
> >
> > Is there any way to let WicketTester use a different implementation then
> > MockWebRequest?
> >
> 
> This is how we resolve the method:
> 
> +   protected List getParameterValues(String inputName)
> +   {
> +   String method = Form.METHOD_POST;
> +   final Form form = findParent(Form.class);
> +   final Request request = getRequest();
> +   if (getRequest().getContainerRequest() instanceof
> HttpServletRequest)
> +   {
> +   method = ((HttpServletRequest)
> getRequest().getContainerRequest()).getMethod();
> +   }
> +   else if (form != null)
> +   {
> +   method = form.getMethod();
> +   }
> 
> Try with:
> tester.getRequest().setMethod("get");
> tester.getRequest().setParameter("select", page.option1.getValue());
> ...
> 
> 
> > Regards.
> >
> > > On Fri, Jan 10, 2020 at 9:31 AM Francesco Chicchiriccò <
> > ilgro...@apache.org>
> > > wrote:
> > >
> > > > Hi there,
> > > > it seems we have some issues with Wicket Tester, after upgrading to
> > 8.7.0
> > > > from 8.6.1.
> > > >
> > > > In particular, due to the change [1] for WICKET-6708, we have found
> > that
> > > > MockWebRequest is not behaving as expected; no troubles occur instead
> > > > during normal operations with HttpServletRequest.
> > > >
> > > > The test failures occur because MockWebRequest's method is (correctly)
> > set
> > > > to POST but parameters are submitted with URL, when using
> > DropDownChoice
> > > > with onChange behavior [2].
> > > >
> > > > Of course, such situation was fine with code prior to [1] but not
> > working
> > > > anymore: I have verified that expected submit parameters are part of
> > URL,
> > > > hence are available as getQueryParameters() but getPostParameters() is
> > > > invoked instead.
> > > >
> > > > FYI, one of failing test cases in [3].
> > > >
> > > > Please let me know if this is a bug with MockWebRequest or whether we
> > have
> > > > to update our test code, thanks.
> > > >
> > > > Regards.
> > > >
> > > > [1]
> > https://github.com/apache/wicket/commit/9c3129517a15c37cc90fb27a697868a825940aa0#diff-51cf2faf6078497df77cc6d995dd1b98R763
> > > > [2]
> > https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/panels/AbstractLogsPanel.java#L71
> > > > [3]
> > https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/java/org/apache/syncope/fit/console/LogsITCase.java#L57
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Test errors after upgrading to Wicket 8.7.0

2020-01-10 Thread Francesco Chicchiriccò

On 2020/01/10 12:24:49, Martin Grigorov  wrote: 
> Hi Francesco,
> 
> This was a bug in Wicket, a security related one.
> You will need to fix your code.
> 
> The change should look something like this:
> 
> 
> -   tester.getRequest().setParameter("select",
> page.option1.getValue());
> -   tester.getRequest().setParameter("text", "text is required");
> -   tester.submitForm(page.form);
> +   final FormTester formTester2 = tester.newFormTester("form");
> +   formTester2.setValue("select", "option1");
> +   formTester2.setValue("text", "text is required");
> +   formTester2.submit();
> 
> from
> https://gitbox.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=0c19cf8;hp=3d8f8b306a92cee71020a633be1d347177d7b7fc

Thanks Martin.

As I can see from above, you have a Form instance, which we don't have in [2].

Moreover, the problem only occurs with MockWebRequest, not with regular 
operations (e.g. HttpServletRequest), hence I'd need to introduce a Form only 
to let tests pass...

Is there any way to let WicketTester use a different implementation then 
MockWebRequest?

Regards.

> On Fri, Jan 10, 2020 at 9:31 AM Francesco Chicchiriccò 
> wrote:
> 
> > Hi there,
> > it seems we have some issues with Wicket Tester, after upgrading to 8.7.0
> > from 8.6.1.
> >
> > In particular, due to the change [1] for WICKET-6708, we have found that
> > MockWebRequest is not behaving as expected; no troubles occur instead
> > during normal operations with HttpServletRequest.
> >
> > The test failures occur because MockWebRequest's method is (correctly) set
> > to POST but parameters are submitted with URL, when using DropDownChoice
> > with onChange behavior [2].
> >
> > Of course, such situation was fine with code prior to [1] but not working
> > anymore: I have verified that expected submit parameters are part of URL,
> > hence are available as getQueryParameters() but getPostParameters() is
> > invoked instead.
> >
> > FYI, one of failing test cases in [3].
> >
> > Please let me know if this is a bug with MockWebRequest or whether we have
> > to update our test code, thanks.
> >
> > Regards.
> >
> > [1] 
> > https://github.com/apache/wicket/commit/9c3129517a15c37cc90fb27a697868a825940aa0#diff-51cf2faf6078497df77cc6d995dd1b98R763
> > [2] 
> > https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/panels/AbstractLogsPanel.java#L71
> > [3] 
> > https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/java/org/apache/syncope/fit/console/LogsITCase.java#L57

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Test errors after upgrading to Wicket 8.7.0

2020-01-09 Thread Francesco Chicchiriccò

Hi there,
it seems we have some issues with Wicket Tester, after upgrading to 8.7.0 from 
8.6.1.

In particular, due to the change [1] for WICKET-6708, we have found that 
MockWebRequest is not behaving as expected; no troubles occur instead during 
normal operations with HttpServletRequest.

The test failures occur because MockWebRequest's method is (correctly) set to 
POST but parameters are submitted with URL, when using DropDownChoice with 
onChange behavior [2].

Of course, such situation was fine with code prior to [1] but not working 
anymore: I have verified that expected submit parameters are part of URL, hence 
are available as getQueryParameters() but getPostParameters() is invoked 
instead.

FYI, one of failing test cases in [3].

Please let me know if this is a bug with MockWebRequest or whether we have to 
update our test code, thanks.

Regards.

[1] 
https://github.com/apache/wicket/commit/9c3129517a15c37cc90fb27a697868a825940aa0#diff-51cf2faf6078497df77cc6d995dd1b98R763
[2] 
https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/panels/AbstractLogsPanel.java#L71
[3] 
https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/java/org/apache/syncope/fit/console/LogsITCase.java#L57

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicketstuff 8.5.0?

2019-06-06 Thread Francesco Chicchiriccò

Thanks Maxim.

FYI, I have opened

https://github.com/MarcGiffing/wicket-spring-boot/issues/157

Feel free to join.
Regards.

On 2019/06/06 08:42:44, Maxim Solodovnik  wrote: 
> Hello Francesco,
> 
> I'm planning to perform a release this weekend
> Was hoping to get this [1] discussion resolved first, but it seems to
> be not very active
> 
> [1] https://github.com/wicketstuff/core/pull/652
> 
> On Thu, 6 Jun 2019 at 15:38, Francesco Chicchiriccò  
> wrote:
> >
> > Hi there,
> > I was wondering if there are plans to release Wicketstuff 8.5.0 any time 
> > soon.
> >
> > ATM I have a startup exception when using Wicket Spring Boot [1] with 
> > Wicket 8.5.0 because it detects a mismatch between Wicket's and 
> > Wicketstuff's versions [2].
> >
> > I understand this is not a fault per-se, of course...
> >
> > Thanks.
> > Regards.
> >
> > [1] https://github.com/MarcGiffing/wicket-spring-boot
> > [2] 
> > https://github.com/MarcGiffing/wicket-spring-boot/blob/wicket-spring-boot-starter-parent-2.1.6/wicket-spring-boot-starter/src/main/java/com/giffing/wicket/spring/boot/starter/app/verifier/WicketDependencyVersionChecker.java#L60-L66

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicketstuff 8.5.0?

2019-06-06 Thread Francesco Chicchiriccò

Hi there,
I was wondering if there are plans to release Wicketstuff 8.5.0 any time soon.

ATM I have a startup exception when using Wicket Spring Boot [1] with Wicket 
8.5.0 because it detects a mismatch between Wicket's and Wicketstuff's versions 
[2].

I understand this is not a fault per-se, of course...

Thanks.
Regards.

[1] https://github.com/MarcGiffing/wicket-spring-boot
[2] 
https://github.com/MarcGiffing/wicket-spring-boot/blob/wicket-spring-boot-starter-parent-2.1.6/wicket-spring-boot-starter/src/main/java/com/giffing/wicket/spring/boot/starter/app/verifier/WicketDependencyVersionChecker.java#L60-L66

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: 7.10.0 -> 7.11.0 error with WicketTester

On 2018/12/03 13:29:37, Martin Grigorov  wrote: 
> Yes,
> 
> I will do it later today!

Great, thank you.

> On Mon, Dec 3, 2018 at 3:25 PM Francesco Chicchiriccò 
> wrote:
> 
> > On 2018/12/03 13:08:26, Martin Grigorov  wrote:
> > > Check whether there is only one version of Wicket in your classpath,
> > maybe
> > > some dependency (like Wicket-Bootstrap) brings something else than 7.11.0
> > > in the classpath.
> >
> > Nice catch Martin, that was it.
> >
> > For the moment, I'll exclude as follows:
> >
> >   
> > de.agilecoders.wicket
> > wicket-bootstrap-core
> > ${wicket-bootstrap.version}
> > 
> >   
> > org.apache.wicket
> > wicket-request
> >   
> >   
> > org.apache.wicket
> > wicket-util
> >   
> >     
> >   
> >
> > Is there any wicket-bootstrap release planned anytime soon, which depends
> > on Wicket 7.11.0? Thanks.
> >
> > > On Mon, Dec 3, 2018 at 3:06 PM Francesco Chicchiriccò <
> > ilgro...@apache.org>
> > > wrote:
> > >
> > > > On 2018/12/03 12:57:00, Maxim Solodovnik  wrote:
> > > > > The method is here
> > > > >
> > > >
> > https://github.com/apache/wicket/blob/wicket-7.x/wicket-request/src/main/java/org/apache/wicket/request/Url.java#L1123
> > > > > In all branches ...
> > > >
> > > > ..so my JDK must be lying? :-)
> > > >
> > > > > On Mon, 3 Dec 2018 at 19:50, Francesco Chicchiriccò <
> > ilgro...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > > after upgrading from 7.10.0 to 7.11.0, I receive the following
> > > > exception
> > > > > > when executing tests via Wicket Tester:
> > > > > >
> > > > > > java.lang.NoSuchMethodError:
> > > > > > org.apache.wicket.request.Url.setContextRelative(Z)V
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.setParameters(ServletWebRequest.java:173)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:209)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:112)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:82)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.protocol.http.WebApplication.newWebRequest(WebApplication.java:560)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.newServletWebRequest(BaseWicketTester.java:534)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.setupNextRequestCycle(BaseWicketTester.java:474)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:372)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:267)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:240)
> > > > > > at
> > > > > >
> > > >
> > org.apache.wicket.util.tester.WicketTester.(WicketTester.java:203)
> > > > > >
> > > > > > Any clue?
> > > > > >
> > > > > > TIA
> > > > > > Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: 7.10.0 -> 7.11.0 error with WicketTester

On 2018/12/03 13:08:26, Martin Grigorov  wrote: 
> Check whether there is only one version of Wicket in your classpath, maybe
> some dependency (like Wicket-Bootstrap) brings something else than 7.11.0
> in the classpath.

Nice catch Martin, that was it.

For the moment, I'll exclude as follows:

  
de.agilecoders.wicket
wicket-bootstrap-core
${wicket-bootstrap.version}

  
org.apache.wicket
wicket-request
  
  
org.apache.wicket
wicket-util
  

  

Is there any wicket-bootstrap release planned anytime soon, which depends on 
Wicket 7.11.0? Thanks.

> On Mon, Dec 3, 2018 at 3:06 PM Francesco Chicchiriccò 
> wrote:
> 
> > On 2018/12/03 12:57:00, Maxim Solodovnik  wrote:
> > > The method is here
> > >
> > https://github.com/apache/wicket/blob/wicket-7.x/wicket-request/src/main/java/org/apache/wicket/request/Url.java#L1123
> > > In all branches ...
> >
> > ..so my JDK must be lying? :-)
> >
> > > On Mon, 3 Dec 2018 at 19:50, Francesco Chicchiriccò  > >
> > > wrote:
> > >
> > > > Hi all,
> > > > after upgrading from 7.10.0 to 7.11.0, I receive the following
> > exception
> > > > when executing tests via Wicket Tester:
> > > >
> > > > java.lang.NoSuchMethodError:
> > > > org.apache.wicket.request.Url.setContextRelative(Z)V
> > > > at
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.setParameters(ServletWebRequest.java:173)
> > > > at
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:209)
> > > > at
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:112)
> > > > at
> > > >
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:82)
> > > > at
> > > >
> > org.apache.wicket.protocol.http.WebApplication.newWebRequest(WebApplication.java:560)
> > > > at
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.newServletWebRequest(BaseWicketTester.java:534)
> > > > at
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.setupNextRequestCycle(BaseWicketTester.java:474)
> > > > at
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:372)
> > > > at
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:267)
> > > > at
> > > >
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:240)
> > > > at
> > > >
> > org.apache.wicket.util.tester.WicketTester.(WicketTester.java:203)
> > > >
> > > > Any clue?
> > > >
> > > > TIA
> > > > Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: 7.10.0 -> 7.11.0 error with WicketTester

On 2018/12/03 12:57:00, Maxim Solodovnik  wrote: 
> The method is here
> https://github.com/apache/wicket/blob/wicket-7.x/wicket-request/src/main/java/org/apache/wicket/request/Url.java#L1123
> In all branches ...

..so my JDK must be lying? :-)

> On Mon, 3 Dec 2018 at 19:50, Francesco Chicchiriccò 
> wrote:
> 
> > Hi all,
> > after upgrading from 7.10.0 to 7.11.0, I receive the following exception
> > when executing tests via Wicket Tester:
> >
> > java.lang.NoSuchMethodError:
> > org.apache.wicket.request.Url.setContextRelative(Z)V
> > at
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.setParameters(ServletWebRequest.java:173)
> > at
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:209)
> > at
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:112)
> > at
> > org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:82)
> > at
> > org.apache.wicket.protocol.http.WebApplication.newWebRequest(WebApplication.java:560)
> > at
> > org.apache.wicket.util.tester.BaseWicketTester.newServletWebRequest(BaseWicketTester.java:534)
> > at
> > org.apache.wicket.util.tester.BaseWicketTester.setupNextRequestCycle(BaseWicketTester.java:474)
> > at
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:372)
> > at
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:267)
> > at
> > org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:240)
> > at
> > org.apache.wicket.util.tester.WicketTester.(WicketTester.java:203)
> >
> > Any clue?
> >
> > TIA
> > Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

7.10.0 -> 7.11.0 error with WicketTester

Hi all,
after upgrading from 7.10.0 to 7.11.0, I receive the following exception when 
executing tests via Wicket Tester:

java.lang.NoSuchMethodError: 
org.apache.wicket.request.Url.setContextRelative(Z)V
at 
org.apache.wicket.protocol.http.servlet.ServletWebRequest.setParameters(ServletWebRequest.java:173)
at 
org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:209)
at 
org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:112)
at 
org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:82)
at 
org.apache.wicket.protocol.http.WebApplication.newWebRequest(WebApplication.java:560)
at 
org.apache.wicket.util.tester.BaseWicketTester.newServletWebRequest(BaseWicketTester.java:534)
at 
org.apache.wicket.util.tester.BaseWicketTester.setupNextRequestCycle(BaseWicketTester.java:474)
at 
org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:372)
at 
org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:267)
at 
org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:240)
at 
org.apache.wicket.util.tester.WicketTester.(WicketTester.java:203)

Any clue? 

TIA
Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DynamicJQueryResourceReference deprecated - now what?

2018-10-03 Thread Francesco Chicchiriccò

On 2018/10/03 15:54:18, Maxim Solodovnik  wrote: 
> Version 8.x will set V2 by default (no specific code is required)
> Version 9.x will set V3
> 
> You can change this behavior adding
> getJavaScriptLibrarySettings().setJQueryReference(JQueryResourceReference.getV3());
> to Application.init()

Thank you very much, now it's clear.
Regards.
 
> On Wed, 3 Oct 2018 at 22:51, Francesco Chicchiriccò 
> wrote:
> 
> > On 2018/10/03 15:40:21, Maxim Solodovnik  wrote:
> > > I guess I't time to move to V2/V3
> > > IE 6/7/8/9 is extremely outdated .
> >
> > I agree, but I don't see how this relates to my question: the javadoc for
> > DynamicJQueryResourceReference says that
> >
> > For IE 6/7/8 jQuery ver. 1.x will be used, for any other browser - ver.
> > 2.x.
> >
> > Fair enough; now, since the class is deprecated, how am I expected to
> > modify my code? This is what I don't get.
> >
> > FYI the line is
> >
> >
> > https://github.com/apache/syncope/blob/master/client/console/src/main/java/org/apache/syncope/client/console/SyncopeConsoleApplication.java#L182
> >
> > Regards.
> >
> > > On Wed, 3 Oct 2018 at 22:37, Francesco Chicchiriccò  > >
> > > wrote:
> > >
> > > > Hi there,
> > > > I can see that DynamicJQueryResourceReference [1] is deprecated in 8.x
> > and
> > > > removed from master branch.
> > > >
> > > > From the @Deprecated annotation, however, I cannot find how to upgrade
> > my
> > > > current code: could you please shade some light? Thanks.
> > > >
> > > > Regards.
> > > >
> > > > [1]
> > > >
> > https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/resource/DynamicJQueryResourceReference.java
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > > For additional commands, e-mail: users-h...@wicket.apache.org
> > > >
> > > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> -- 
> WBR
> Maxim aka solomax
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DynamicJQueryResourceReference deprecated - now what?

2018-10-03 Thread Francesco Chicchiriccò

On 2018/10/03 15:40:21, Maxim Solodovnik  wrote: 
> I guess I't time to move to V2/V3
> IE 6/7/8/9 is extremely outdated .

I agree, but I don't see how this relates to my question: the javadoc for 
DynamicJQueryResourceReference says that

For IE 6/7/8 jQuery ver. 1.x will be used, for any other browser - ver. 2.x.

Fair enough; now, since the class is deprecated, how am I expected to modify my 
code? This is what I don't get.

FYI the line is

https://github.com/apache/syncope/blob/master/client/console/src/main/java/org/apache/syncope/client/console/SyncopeConsoleApplication.java#L182

Regards.

> On Wed, 3 Oct 2018 at 22:37, Francesco Chicchiriccò 
> wrote:
> 
> > Hi there,
> > I can see that DynamicJQueryResourceReference [1] is deprecated in 8.x and
> > removed from master branch.
> >
> > From the @Deprecated annotation, however, I cannot find how to upgrade my
> > current code: could you please shade some light? Thanks.
> >
> > Regards.
> >
> > [1]
> > https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/resource/DynamicJQueryResourceReference.java
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> -- 
> WBR
> Maxim aka solomax
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

DynamicJQueryResourceReference deprecated - now what?

2018-10-03 Thread Francesco Chicchiriccò

Hi there,
I can see that DynamicJQueryResourceReference [1] is deprecated in 8.x and 
removed from master branch.

>From the @Deprecated annotation, however, I cannot find how to upgrade my 
>current code: could you please shade some light? Thanks.

Regards.

[1] 
https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/resource/DynamicJQueryResourceReference.java

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Seeking help for a HotSwapAgent's Wicket plugin

2018-07-16 Thread Francesco Chicchiriccò

Hi Thomas,
thanks for your reply.

I have taken your WicketPlugin, reworked it a bit and generated

https://gist.github.com/ilgrosso/c12fa371a5033de1e92b0a35115b6456

Unfortunately, it does not seem to work: once started Tomcat with hotswap-agent 
enabled, I can successfully reload Java classes, but changes to properties 
files just have no effect.

I have also been debugging the WicketPlugin class, and I can see that the 
Command is effectively invoked and completes with no exceptions.

What could I be missing? Also, do you have any idea why I don't get any change 
in HTML files reloaded? I have added my src/main/resources folder to 
extraClassPath as you did.

Maybe something missing in my WicketApplications' settings?

Thanks for your support.
Regards.

On 2018/07/13 16:50:16, Thomas Heigl  wrote: 
> Hi Francesco,
> 
> I faced the same situation last week.
> 
> I wrote a Wicket plugin that clears the Localizer cache. It does not clear
> the resource bundle cache because I use Spring's ReloadableResourceBundle,
> but that should be very easy to add.
> 
> Configuration is a little more difficult than with JRebel. I had to add
> src/main/resources as extraClasspath for some reason, to get it to reload
> HTML and property files.
> 
> Here is a gist with my Wicket plugin and my working
> hotswap-agent.properties:
> 
> https://gist.github.com/theigl/6ff4a505eac8f166b9bd079017884474
> 
> Best,
> 
> Thomas
> 
> On Fri, Jul 13, 2018 at 4:53 PM, Francesco Chicchiriccò  > wrote:
> 
> > Hi all,
> > at Syncope we recently switched from JRebel to HotSwapAgent, mostly
> > because the MyJRebel program has ended.
> > All works quite well for Java classes, but we do have issues with HTML and
> > properties files (for Resource Bundles) used by Wicket.
> >
> > Please consider that we do package our Wicket application as JAR with
> > web-fragment [1], and HTML and properties files are kept under
> > src/main/resources [2].
> >
> > I have started building a Wicket plugin for HotSwapAgent following the
> > instructions at [3] and the samples at [4]: the MyFaces plugin [5] looks
> > promising, at least because it says that it's clearing out the Resource
> > Bundle cache.
> >
> > So my question is: assuming that HotSwapAgent correctly replaces the HTML
> > and properties file in the classloader, how can I trigger Wicket to reload?
> >
> > TIA
> > Regards.
> >
> > [1] https://github.com/apache/syncope/tree/master/client/console
> > [2] https://github.com/apache/syncope/tree/master/client/
> > console/src/main/resources/org/apache/syncope/client/console
> > [3] http://hotswapagent.org/mydoc_custom_plugins.html
> > [4] https://github.com/HotswapProjects/HotswapAgent/
> > blob/master/README.md#java-frameworks-plugins
> > [5] https://github.com/HotswapProjects/HotswapAgent/
> > blob/master/plugin/hotswap-agent-myfaces-plugin/src/main/
> > java/org/hotswap/agent/plugin/myfaces/MyFacesPlugin.java

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Seeking help for a HotSwapAgent's Wicket plugin

2018-07-13 Thread Francesco Chicchiriccò

Hi all,
at Syncope we recently switched from JRebel to HotSwapAgent, mostly because the 
MyJRebel program has ended.
All works quite well for Java classes, but we do have issues with HTML and 
properties files (for Resource Bundles) used by Wicket.

Please consider that we do package our Wicket application as JAR with 
web-fragment [1], and HTML and properties files are kept under 
src/main/resources [2].

I have started building a Wicket plugin for HotSwapAgent following the 
instructions at [3] and the samples at [4]: the MyFaces plugin [5] looks 
promising, at least because it says that it's clearing out the Resource Bundle 
cache.

So my question is: assuming that HotSwapAgent correctly replaces the HTML and 
properties file in the classloader, how can I trigger Wicket to reload?

TIA
Regards.

[1] https://github.com/apache/syncope/tree/master/client/console
[2] 
https://github.com/apache/syncope/tree/master/client/console/src/main/resources/org/apache/syncope/client/console
[3] http://hotswapagent.org/mydoc_custom_plugins.html
[4] 
https://github.com/HotswapProjects/HotswapAgent/blob/master/README.md#java-frameworks-plugins
[5] 
https://github.com/HotswapProjects/HotswapAgent/blob/master/plugin/hotswap-agent-myfaces-plugin/src/main/java/org/hotswap/agent/plugin/myfaces/MyFacesPlugin.java

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: FormTester, FinishButton and Wicket 8.0

2018-06-13 Thread Francesco Chicchiriccò

I have spent some time investigating this issue, and I have finally found that 
the actual problem lies at

https://github.com/apache/syncope/blob/SYNCOPE-1323/client/console/src/main/java/org/apache/syncope/client/console/wizards/AjaxWizard.java#L198

e.g. 

RequestCycle.get().find(AjaxRequestTarget.class)

returns an Optional holding null, when onFinish() is invoked by WicketTester 
(actual execution works fine, as said below).

Does this ring any bell?
Regards.

On 2018/06/11 10:43:32, Francesco Chicchiriccò  wrote: 
> On 2018/06/07 16:43:58, Sven Meier  wrote: 
> > Hi,
> > 
> > I'm not able to run the test in Intellij nor in Eclipse:
> > 
> > java.lang.NoSuchMethodError: 
> > org.junit.platform.commons.util.ReflectionUtils.getDefaultClassLoader
> 
> Thanks for reporting, it seems that the problem was due to an accidental 
> inclusion of the old junit artifact in the test classpath.
> Anyway, what you can currently find on the Syncope master branch is still 
> based on Wicket 7 (and the tests run fine); the Wicket 8 branch is not 
> published.
>  
> > I suspect your problem might be caused by WICKET-6541, but I don't see 
> > why the changes should fail during tests.
> 
> Thanks for pointing this out, I will look at it.
> 
> Regards.
> 
> > Am 06.06.2018 um 19:00 schrieb Sven Meier:
> > > I'll take a look.
> > >
> > > Have fun
> > > Sven
> > >
> > >
> > > Am 06.06.2018 um 17:16 schrieb Francesco Chicchiriccò:
> > >> Hi all,
> > >> I am migrating the Syncope master branch from Wicket 7 to 8.
> > >> It seems all is working fine when dealing via browser, but the 
> > >> integration tests are mostly failing.
> > >>
> > >> As Syncope heavily uses Wizards, the reason seems that FormTester 
> > >> fails somehow to submit the Finish button (though no error is 
> > >> reported); the failing statement is (for example):
> > >>
> > >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L64
> > >>  
> > >>
> > >>
> > >> but I can see that no submit was effectively performed by
> > >>
> > >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L62
> > >>  
> > >>
> > >>
> > >> hence no feedback message was generated.
> > >> Strange is that I am also sure that the Next button is effectively 
> > >> submitted by
> > >>
> > >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L56
> > >>  
> > >>
> > >>
> > >> Is there anything relevant that was changed in WicketTester with 
> > >> Wicket 8? The code above works fine with Wicket 7, and performing the 
> > >> same actions via browser works fine too.
> > >>
> > >> TIA.
> > >> Regards.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > >> For additional commands, e-mail: users-h...@wicket.apache.org
> > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: FormTester, FinishButton and Wicket 8.0

2018-06-11 Thread Francesco Chicchiriccò

On 2018/06/07 16:43:58, Sven Meier  wrote: 
> Hi,
> 
> I'm not able to run the test in Intellij nor in Eclipse:
> 
> java.lang.NoSuchMethodError: 
> org.junit.platform.commons.util.ReflectionUtils.getDefaultClassLoader

Thanks for reporting, it seems that the problem was due to an accidental 
inclusion of the old junit artifact in the test classpath.
Anyway, what you can currently find on the Syncope master branch is still based 
on Wicket 7 (and the tests run fine); the Wicket 8 branch is not published.
 
> I suspect your problem might be caused by WICKET-6541, but I don't see 
> why the changes should fail during tests.

Thanks for pointing this out, I will look at it.

Regards.

> Am 06.06.2018 um 19:00 schrieb Sven Meier:
> > I'll take a look.
> >
> > Have fun
> > Sven
> >
> >
> > Am 06.06.2018 um 17:16 schrieb Francesco Chicchiriccò:
> >> Hi all,
> >> I am migrating the Syncope master branch from Wicket 7 to 8.
> >> It seems all is working fine when dealing via browser, but the 
> >> integration tests are mostly failing.
> >>
> >> As Syncope heavily uses Wizards, the reason seems that FormTester 
> >> fails somehow to submit the Finish button (though no error is 
> >> reported); the failing statement is (for example):
> >>
> >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L64
> >>  
> >>
> >>
> >> but I can see that no submit was effectively performed by
> >>
> >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L62
> >>  
> >>
> >>
> >> hence no feedback message was generated.
> >> Strange is that I am also sure that the Next button is effectively 
> >> submitted by
> >>
> >> https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L56
> >>  
> >>
> >>
> >> Is there anything relevant that was changed in WicketTester with 
> >> Wicket 8? The code above works fine with Wicket 7, and performing the 
> >> same actions via browser works fine too.
> >>
> >> TIA.
> >> Regards.
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

FormTester, FinishButton and Wicket 8.0

2018-06-06 Thread Francesco Chicchiriccò

Hi all,
I am migrating the Syncope master branch from Wicket 7 to 8.
It seems all is working fine when dealing via browser, but the integration 
tests are mostly failing.

As Syncope heavily uses Wizards, the reason seems that FormTester fails somehow 
to submit the Finish button (though no error is reported); the failing 
statement is (for example):

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L64

but I can see that no submit was effectively performed by

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L62

hence no feedback message was generated.
Strange is that I am also sure that the Next button is effectively submitted by

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/ParametersITCase.java#L56

Is there anything relevant that was changed in WicketTester with Wicket 8? The 
code above works fine with Wicket 7, and performing the same actions via 
browser works fine too.

TIA.
Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Upgrade to Wicket 8.0.0-M7

2017-08-23 Thread Francesco Chicchiriccò



On 2017-08-23 12:39, Andrea Del Bene  wrote: 
> There are 2 versions of Wicket 8 in your dependency tree: M7 and M6
> inherited from wicket-bootstrap-core. This should create a conflict as
> resolveLocale()
> was introduced only in M7. You could try using the snapshot version for
> wicket-bootstrap-core.

Thanks for your suggestion, Andrea: since wicket-bootstrap latest SNAPSHOT is 
still on wicket 8.0.0-M6 [1], I've added some exclusions in the Syncope pom.xml 
and it worked.

Now I have some JS troubles (especially wicket-chartjs), but that's a 
completely different story...

Regards.

[1] https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/wicket-8.x/pom.xml#L71

> On Wed, Aug 23, 2017 at 12:23 PM, Francesco ChicchiriccÃ² <
> ilgro...@apache.org> wrote:
> 
> > On 2017-08-23 12:07, Andrea Del Bene  wrote:
> > > Hi,
> > >
> > > it seems a problem with the classpath. Looks like you are still referring
> > > to 7.8.0.
> >
> > Hi Andrea,
> > mvn dependency:tree says I'm all with 8.0.0-M7:
> >
> > https://paste.apache.org/PRVi
> >
> > Any other hint?
> > Regards.
> >
> > > On Wed, Aug 23, 2017 at 11:50 AM, Francesco ChicchiriccÃ² <
> > > ilgro...@apache.org> wrote:
> > >
> > > > Hi all,
> > > > I am trying to update the Apache Syncope codebase (master branch,
> > version
> > > > 2.1.0-SNAPSHOT) to Wicket 8.0.0-M7 (from Wicket 7.8.0).
> > > >
> > > > After some changes, the code now builds fine, but when accessing the
> > > > HomePage, I receive the following exception:
> > > >
> > > > java.lang.NoSuchMethodError: org.apache.wicket.core.request.mapper.
> > > > AbstractBookmarkableMapper.resolveLocale()Ljava/util/Locale;
> > > > at org.apache.wicket.core.request.mapper.
> > > > AbstractBookmarkableMapper.newPageParameters(
> > AbstractBookmarkableMapper.
> > > > java:488)
> > > > at org.apache.wicket.core.request.mapper.MountedMapper.
> > > > parseRequest(MountedMapper.java:133)
> > > > at org.apache.wicket.core.request.mapper.HomePageMapper.
> > > > parseRequest(HomePageMapper.java:85)
> > > > at org.apache.wicket.core.request.mapper.
> > > > AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.
> > java:322)
> > > > at org.apache.wicket.request.mapper.CompoundRequestMapper.
> > > > mapRequest(CompoundRequestMapper.java:147)
> > > > at org.apache.wicket.request.cycle.RequestCycle.
> > > > resolveRequestHandler(RequestCycle.java:193)
> > > > at org.apache.wicket.request.cycle.RequestCycle.
> > > > processRequest(RequestCycle.java:243)
> > > > at org.apache.wicket.request.cycle.RequestCycle.
> > > > processRequestAndDetach(RequestCycle.java:221)
> > > > at org.apache.wicket.protocol.ws.AbstractUpgradeFilter.
> > > > processRequestCycle(AbstractUpgradeFilter.java:70)
> > > > at org.apache.wicket.protocol.http.WicketFilter.
> > > > processRequest(WicketFilter.java:204)
> > > > at org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > > > WicketFilter.java:286)
> > > > at org.apache.catalina.core.ApplicationFilterChain.
> > > > internalDoFilter(ApplicationFilterChain.java:193)
> > > > at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > > > ApplicationFilterChain.java:166)
> > > > at org.apache.catalina.core.StandardWrapperValve.invoke(
> > > > StandardWrapperValve.java:198)
> > > > at org.apache.catalina.core.StandardContextValve.invoke(
> > > > StandardContextValve.java:96)
> > > > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> > > > AuthenticatorBase.java:478)
> > > > at org.apache.catalina.core.StandardHostValve.invoke(
> > > > StandardHostValve.java:140)
> > > > at org.apache.catalina.valves.ErrorReportValve.invoke(
> > > > ErrorReportValve.java:80)
> > > > at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> > > > AbstractAccessLogValve.java:650)
> > > > at org.apache.catalina.core.StandardEngineValve.invoke(
> > > > StandardEngineValve.java:87)
> > > > at org.apache.catalina.connector.CoyoteAdapter.service(
> > > > CoyoteAdapter.java:342)
> > > > at org.apache.coyote.http11.Http11Processor.service(
> > > > Http11Processor.java:799)
> > > > at org.apache.coyote.AbstractProcessorLight.process(
> > > > AbstractProcessorLight.java:66)
> > > > at org.apache.coyote.AbstractProtocol$
> > ConnectionHandler.process(
> > > > AbstractProtocol.java:868)
> > > > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> > > > doRun(NioEndpoint.java:1457)
> > > > at org.apache.tomcat.util.net.SocketProcessorBase.run(
> > > > SocketProcessorBase.java:49)
> > > > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > > > ThreadPoolExecutor.java:1149)
> > > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > > > ThreadPoolExecutor.java:624)
> > > > at

Re: Upgrade to Wicket 8.0.0-M7

2017-08-23 Thread Francesco Chicchiriccò

On 2017-08-23 12:07, Andrea Del Bene  wrote: 
> Hi,
> 
> it seems a problem with the classpath. Looks like you are still referring
> to 7.8.0.

Hi Andrea,
mvn dependency:tree says I'm all with 8.0.0-M7:

https://paste.apache.org/PRVi

Any other hint?
Regards.

> On Wed, Aug 23, 2017 at 11:50 AM, Francesco ChicchiriccÃ² <
> ilgro...@apache.org> wrote:
> 
> > Hi all,
> > I am trying to update the Apache Syncope codebase (master branch, version
> > 2.1.0-SNAPSHOT) to Wicket 8.0.0-M7 (from Wicket 7.8.0).
> >
> > After some changes, the code now builds fine, but when accessing the
> > HomePage, I receive the following exception:
> >
> > java.lang.NoSuchMethodError: org.apache.wicket.core.request.mapper.
> > AbstractBookmarkableMapper.resolveLocale()Ljava/util/Locale;
> > at org.apache.wicket.core.request.mapper.
> > AbstractBookmarkableMapper.newPageParameters(AbstractBookmarkableMapper.
> > java:488)
> > at org.apache.wicket.core.request.mapper.MountedMapper.
> > parseRequest(MountedMapper.java:133)
> > at org.apache.wicket.core.request.mapper.HomePageMapper.
> > parseRequest(HomePageMapper.java:85)
> > at org.apache.wicket.core.request.mapper.
> > AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:322)
> > at org.apache.wicket.request.mapper.CompoundRequestMapper.
> > mapRequest(CompoundRequestMapper.java:147)
> > at org.apache.wicket.request.cycle.RequestCycle.
> > resolveRequestHandler(RequestCycle.java:193)
> > at org.apache.wicket.request.cycle.RequestCycle.
> > processRequest(RequestCycle.java:243)
> > at org.apache.wicket.request.cycle.RequestCycle.
> > processRequestAndDetach(RequestCycle.java:221)
> > at org.apache.wicket.protocol.ws.AbstractUpgradeFilter.
> > processRequestCycle(AbstractUpgradeFilter.java:70)
> > at org.apache.wicket.protocol.http.WicketFilter.
> > processRequest(WicketFilter.java:204)
> > at org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > WicketFilter.java:286)
> > at org.apache.catalina.core.ApplicationFilterChain.
> > internalDoFilter(ApplicationFilterChain.java:193)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > ApplicationFilterChain.java:166)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(
> > StandardWrapperValve.java:198)
> > at org.apache.catalina.core.StandardContextValve.invoke(
> > StandardContextValve.java:96)
> > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> > AuthenticatorBase.java:478)
> > at org.apache.catalina.core.StandardHostValve.invoke(
> > StandardHostValve.java:140)
> > at org.apache.catalina.valves.ErrorReportValve.invoke(
> > ErrorReportValve.java:80)
> > at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> > AbstractAccessLogValve.java:650)
> > at org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:87)
> > at org.apache.catalina.connector.CoyoteAdapter.service(
> > CoyoteAdapter.java:342)
> > at org.apache.coyote.http11.Http11Processor.service(
> > Http11Processor.java:799)
> > at org.apache.coyote.AbstractProcessorLight.process(
> > AbstractProcessorLight.java:66)
> > at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> > AbstractProtocol.java:868)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> > doRun(NioEndpoint.java:1457)
> > at org.apache.tomcat.util.net.SocketProcessorBase.run(
> > SocketProcessorBase.java:49)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1149)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:624)
> > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> > TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:748)
> >
> > Since no org.apache.syncope.* classes are referenced, it is not immediate
> > to me to see where is the problem: could you please help? Thanks!
> >
> > Side question: any plan to remove commons-collections4 as dependency,
> > since Wicket 8 is based on Java 8 where streams and lambda can be empowered
> > for such purpose?
> >
> > Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Upgrade to Wicket 8.0.0-M7

2017-08-23 Thread Francesco Chicchiriccò

Hi all,
I am trying to update the Apache Syncope codebase (master branch, version 
2.1.0-SNAPSHOT) to Wicket 8.0.0-M7 (from Wicket 7.8.0).

After some changes, the code now builds fine, but when accessing the HomePage, 
I receive the following exception:

java.lang.NoSuchMethodError: 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.resolveLocale()Ljava/util/Locale;
at 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.newPageParameters(AbstractBookmarkableMapper.java:488)
at 
org.apache.wicket.core.request.mapper.MountedMapper.parseRequest(MountedMapper.java:133)
at 
org.apache.wicket.core.request.mapper.HomePageMapper.parseRequest(HomePageMapper.java:85)
at 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:322)
at 
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:147)
at 
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:193)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:243)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
at 
org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:204)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:286)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1457)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Since no org.apache.syncope.* classes are referenced, it is not immediate to me 
to see where is the problem: could you please help? Thanks!

Side question: any plan to remove commons-collections4 as dependency, since 
Wicket 8 is based on Java 8 where streams and lambda can be empowered for such 
purpose?

Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Log tailer sample?

2017-01-11 Thread Francesco Chicchiriccò


On 11/01/2017 16:39, Martin Grigorov wrote:

Thanks for sharing, Francesco!

Small feedback:

- for us (Wicket users) it would be useful to have an url to the
implementation of the log viewer (Apache Git or GitHub)


Here you go:

https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/pages/LogViewer.java
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/resources/org/apache/syncope/client/console/pages/LogViewer.html
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/panels/LogStatementPanel.java
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/resources/org/apache/syncope/client/console/panels/LogStatementPanel.html


- mount the pages so that they have a nicer (user friendly) url instead of
/wicket/bookmarkable/


Yep I know, though I don't see it so necessary as the sole way to get to 
it is to authenticate to the main application and click onto the 
dedicated button... I will think about this option anyway, thanks!


Regards.


On Wed, Jan 11, 2017 at 12:01 PM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:


Hi,
FYI here are the results:

http://blog.tirasa.net/apache-syncope-2.0-the-new-log-viewer.html

Regards.


On 05/01/2017 13:38, Francesco Chicchiriccò wrote:


On 05/01/2017 13:28, Martin Grigorov wrote:


On Thu, Jan 5, 2017 at 1:23 PM, Francesco Chicchiriccò <
ilgro...@apache.org>
wrote:

On 03/01/2017 17:17, Francesco Chicchiriccò wrote:

Hi all,

is there any sample about building a log tailer with Wicket? I have
found
[1] [2] so far.

FYI I went ahead and I am almost done with implementation:

essentially, it
is a ListView dinamically updated with data received via WebSocket.

I have only an issue left at this point: when the ListView is updated,
the
scrollbar is moved to top, while I would like to leave it in the
position
it had before the refresh.
Any idea?

This is because you repaint/replace the whole ListView.

It would be better if you just add the new item at the bottom.
See
http://wicketinaction.com/2008/10/repainting-only-newly-crea
ted-repeater-items-via-ajax/


Thanks, Martin.
I am however not only adding new items at the bottom, but also
potentially removing items from the top (the maximum number of log
statements to keep is fixed, to avoid memory issues).

I thought that jQuery's scroll lock could have been used in this case...

Regards.

[1] 
http://apache-wicket.1842946.n4.nabble.com/How-to-build-a-hudson-jenkins-like-live-log-viewer-td4090224.html
[2] 
https://github.com/steveswinsburg/sakai-logviewer/blob/master/src/java/org/sakaiproject/logviewer/pages/View.java


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Log tailer sample?

2017-01-11 Thread Francesco Chicchiriccò

Hi,
FYI here are the results:

http://blog.tirasa.net/apache-syncope-2.0-the-new-log-viewer.html

Regards.

On 05/01/2017 13:38, Francesco Chicchiriccò wrote:

On 05/01/2017 13:28, Martin Grigorov wrote:
On Thu, Jan 5, 2017 at 1:23 PM, Francesco Chicchiriccò
<ilgro...@apache.org>

wrote:

On 03/01/2017 17:17, Francesco Chicchiriccò wrote:

Hi all,
is there any sample about building a log tailer with Wicket? I have
found

[1] [2] so far.

FYI I went ahead and I am almost done with implementation:
essentially, it

is a ListView dinamically updated with data received via WebSocket.

I have only an issue left at this point: when the ListView is
updated, the
scrollbar is moved to top, while I would like to leave it in the
position

it had before the refresh.
Any idea?

This is because you repaint/replace the whole ListView.
It would be better if you just add the new item at the bottom.
See
http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/

Thanks, Martin.
I am however not only adding new items at the bottom, but also
potentially removing items from the top (the maximum number of log
statements to keep is fixed, to avoid memory issues).

I thought that jQuery's scroll lock could have been used in this case...

Regards.

[1]
http://apache-wicket.1842946.n4.nabble.com/How-to-build-a-hudson-jenkins-like-live-log-viewer-td4090224.html
[2]
https://github.com/steveswinsburg/sakai-logviewer/blob/master/src/java/org/sakaiproject/logviewer/pages/View.java

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Log tailer sample?

2017-01-05 Thread Francesco Chicchiriccò

On 05/01/2017 13:28, Martin Grigorov wrote:

On Thu, Jan 5, 2017 at 1:23 PM, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:

On 03/01/2017 17:17, Francesco Chicchiriccò wrote:

Hi all,
is there any sample about building a log tailer with Wicket? I have found
[1] [2] so far.

FYI I went ahead and I am almost done with implementation: essentially, it
is a ListView dinamically updated with data received via WebSocket.

I have only an issue left at this point: when the ListView is updated, the
scrollbar is moved to top, while I would like to leave it in the position
it had before the refresh.
Any idea?

Thanks, Martin.
I am however not only adding new items at the bottom, but also
potentially removing items from the top (the maximum number of log
statements to keep is fixed, to avoid memory issues).

I thought that jQuery's scroll lock could have been used in this case...

Regards.

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Log tailer sample?

2017-01-05 Thread Francesco Chicchiriccò


On 03/01/2017 17:17, Francesco Chicchiriccò wrote:

Hi all,
is there any sample about building a log tailer with Wicket? I have 
found [1] [2] so far.


FYI I went ahead and I am almost done with implementation: essentially, 
it is a ListView dinamically updated with data received via WebSocket.


I have only an issue left at this point: when the ListView is updated, 
the scrollbar is moved to top, while I would like to leave it in the 
position it had before the refresh.

Any idea?

TIA
Regards.

[1] 
http://apache-wicket.1842946.n4.nabble.com/How-to-build-a-hudson-jenkins-like-live-log-viewer-td4090224.html
[2] 
https://github.com/steveswinsburg/sakai-logviewer/blob/master/src/java/org/sakaiproject/logviewer/pages/View.java


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe


On 04/01/2017 10:41, Martin Grigorov wrote:

Hi,

My question was: have you updated Tomcat lately?
Maybe you have upgraded from older and working version to latest/broken one.


Ah, I understand: you might be right, then.

It seems that the features connected to web sockets are working fine 
anyway; at first access, no error message; subsequent accesses report 
errors in the logs when switching across pages.


Hence, I guess that the problem occurs because somehow the web socket is 
not closed when going into a new page.


Regards.


On Wed, Jan 4, 2017 at 10:29 AM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:


On 04/01/2017 10:14, Martin Grigorov wrote:


Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could lead
to
this.
In the same time there were many improvements in Tomcat WebSocket code,
and
this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest
versions available.

I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <

ilgro...@apache.org> wrote:


Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
  at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
  at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
  at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
  at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
  at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:47
1)
~[?:1.8.0_111]
  at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:
124)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelector
Pool.java:183)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
sion.java:600)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java
:522)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processDataControl(W
sFrameBase.java:348)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameB
ase.java:290)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(W
sFrameBase.java:131)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvail
able(WsFrameServer.java:71)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
(NioEndpoint.java:1520)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
NioEndpoint.java:1476)
~[tomcat-coyot

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe


On 04/01/2017 10:29, Francesco Chicchiriccò wrote:

On 04/01/2017 10:14, Martin Grigorov wrote:

Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could 
lead to

this.
In the same time there were many improvements in Tomcat WebSocket 
code, and

this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest 
versions available.


I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


It seems that the features connected to web sockets are working fine 
anyway; at first access, no error message; subsequent accesses report 
errors in the logs when switching across pages.


Hence, I guess that the problem occurs because somehow the web socket is 
not closed when going into a new page.


Regards.

On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò 
<ilgro...@apache.org> wrote:

Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
 at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
 at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
 at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)

~[?:1.8.0_111]
 at 
org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr

iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr

ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream

.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) 
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe

r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe

r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe

ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe

ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe

ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe

adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletInputStream.

onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi

spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler

.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)

~[tomcat-coyote.jar:8.0.39]
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

[?:1.8.0_111]
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

[?:1.8

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe


On 04/01/2017 10:14, Martin Grigorov wrote:

Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could lead to
this.
In the same time there were many improvements in Tomcat WebSocket code, and
this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest 
versions available.


I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:

Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
 at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
 at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
 at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
~[?:1.8.0_111]
 at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
~[tomcat-coyote.jar:8.0.39]
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_111]
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_111]
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
~[tomcat-util.jar:8.0.39]
 at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

The error is repeated for each page, with connection id incremented.

This used to work fine with Wicket 7.4.0; with Wicket 7.5.0 we had to
introduce this backport [3] which seems anyway not affecting the problem
above.

Could you please shade some light? Thanks!
Regard

After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe


Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the 
following error in the logs:


10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint - 
An error occurred in web socket connection with id : 0

java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) 
~[?:1.8.0_111]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
~[?:1.8.0_111]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
~[?:1.8.0_111]

at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
~[?:1.8.0_111]
at 
org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWriteInternal(NioServletOutputStream.java:94) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWrite(NioServletOutputStream.java:61) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(AbstractServletOutputStream.java:165) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(AbstractServletOutputStream.java:132) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:98) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:79) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:453) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:341) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:273) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:185) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:198) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:96) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:661) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476) 
~[tomcat-coyote.jar:8.0.39]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:1.8.0_111]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:1.8.0_111]
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 
~[tomcat-util.jar:8.0.39]

at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

The error is repeated for each page, with connection id incremented.

This used to work fine with Wicket 7.4.0; with Wicket 7.5.0 we had to 
introduce this backport [3] which seems anyway not affecting the problem 
above.


Could you please shade some light? Thanks!
Regards.

[1] 
https://github.com/apache/syncope/commit/830fdee246eff396118938fbab61e076fa499678
[2] 
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/pages/BasePage.java#L91-L110
[3] 
https://github.com/apache/syncope/commit/830fdee246eff396118938fbab61e076fa499678#diff-c8d9c2a6a0a2e892467d2b3ef8c0c925


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA

Log tailer sample?

2017-01-03 Thread Francesco Chicchiriccò


Hi all,
is there any sample about building a log tailer with Wicket? I have 
found [1] [2] so far.


Thanks in advance.
Regards.

[1] 
http://apache-wicket.1842946.n4.nabble.com/How-to-build-a-hudson-jenkins-like-live-log-viewer-td4090224.html
[2] 
https://github.com/steveswinsburg/sakai-logviewer/blob/master/src/java/org/sakaiproject/logviewer/pages/View.java


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems with Wicket 7.5.0 and Wicket Bootstrap 0.10.10 using a custom NotificationPanel

2016-10-30 Thread Francesco Chicchiriccò



On 2016-10-28 14:37 (+0100), Martin Grigorov  wrote: 
> On Fri, Oct 28, 2016 at 12:01 PM, Francesco ChicchiriccÃ² <
> ilgro...@apache.org> wrote:
> 
> > On 2016-10-27 14:18 (+0200), Martin Grigorov  wrote:
> > > Hi,
> > >
> > > Good news!
> > > It is a bug in Wicket Bootstrap:
> > > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/wicket-
> > 7.x/bootstrap-core/src/main/java/de/agilecoders/wicket/
> > core/markup/html/bootstrap/dialog/Alert.html#L10
> > >
> > > This  uses a Label in Java. (No idea why).
> > > Since https://issues.apache.org/jira/browse/WICKET-6219 this is not
> > > possible.
> >
> > Hi,
> > we are still having problems when upgrading to Wicket 7.5.0 [1], possibly
> > because of the same reason as above (e.g. WICKET-6219): in deployment mode
> > everything works fine, but in development mode a stacktrace is reported (as
> > shown in [1]): could you please explain what is needed to change, taking
> > [2] as reference?
> >
> 
> I've added a comment in the ticket explaining what was the problem in
> Wicket Bootstrap.
> Looking at AbstractFieldPanel and its specializations I have the feeling
> the problem is the same.

FYI we have solved all Syncope admin console issues with Wicket 7.5.0 and 
resolved SYNCOPE-962.

The actual fix was

https://git-wip-us.apache.org/repos/asf?p=syncope.git;a=blobdiff;f=client/console/src/main/resources/org/apache/syncope/client/console/wicket/markup/html/bootstrap/dialog/BaseModal.html;h=ddf2c9ef8ee4c311e0578862cf7d887fa94e91d5;hp=30689677a83ff9715603cde96e2b1ebe5c7dd30b;hb=dd9e95e;hpb=1bc21e3eb330f44c490baf3448565b4fa6598308

for modal windows.

> Anyway we could improve the error message by adding the relative path to
> the page, so it is more easier to find which component has problems.

Oh, this would be good anyway.
Regards.

> > [1] https://issues.apache.org/jira/browse/SYNCOPE-962
> > [2] https://github.com/apache/syncope/blob/2_0_X/client/
> > console/src/main/resources/org/apache/syncope/client/
> > console/wicket/markup/html/form/AbstractFieldPanel.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems with Wicket 7.5.0 and Wicket Bootstrap 0.10.10 using a custom NotificationPanel

2016-10-28 Thread Francesco Chicchiriccò

On 2016-10-27 14:18 (+0200), Martin Grigorov  wrote: 
> Hi,
> 
> Good news!
> It is a bug in Wicket Bootstrap:
> https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/wicket-7.x/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/dialog/Alert.html#L10
> 
> This  uses a Label in Java. (No idea why).
> Since https://issues.apache.org/jira/browse/WICKET-6219 this is not
> possible.

Hi,
we are still having problems when upgrading to Wicket 7.5.0 [1], possibly 
because of the same reason as above (e.g. WICKET-6219): in deployment mode 
everything works fine, but in development mode a stacktrace is reported (as 
shown in [1]): could you please explain what is needed to change, taking [2] as 
reference?

Thank you very much.
Regards.

[1] https://issues.apache.org/jira/browse/SYNCOPE-962
[2] 
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/resources/org/apache/syncope/client/console/wicket/markup/html/form/AbstractFieldPanel.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems with Wicket 7.5.0 and Wicket Bootstrap 0.10.10 using a custom NotificationPanel



On 2016-10-27 14:40 (+0200), Joachim Rohde  wrote: 
> Great. Thanks for the fast reply Martin. Do you have already a clue when a 
> new version of Wicket Bootstrap will be released?

..or an easy way to backport your fix?

Regards.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: BootstrapPagingNavigator - Wicket-Boostrap 0.10.10 and Wicket 7.5.0

Same here.

On 2016-10-27 13:10 (+0200), Francois Meillet  
wrote: 
> Wicket-Boostrap 0.10.10 and Wicket 7.5.0
> When using a BootstrapPagingNavigator, I get this error : 
> 
> 
> Last cause: The component(s) below failed to render. Possible reasons could 
> be that: 1) you have added a component in code but forgot to reference it in 
> the markup (thus the component will never be rendered), 2) if your components 
> were added in a parent container then make sure the markup for the child 
> container includes them in .
> 
> 1. [Component id = pageNumber]
> The label with id 'pageNumber' that failed to render was constructed
>  at 
> de.agilecoders.wicket.core.markup.html.bootstrap.navigation.BootstrapPagingNavigator$1.populateItem(BootstrapPagingNavigator.java:106)
>  at org.apache.wicket.Page.onBeforeRender(Page.java:801)
>  at org.apache.wicket.Page.internalPrepareForRender(Page.java:242)
>  at org.apache.wicket.Page.renderPage(Page.java:1018)
>  at 
> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
>  at 
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:236)
>  at 
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
>  at 
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
>  at 
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
>  at 
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
> 
> With Wicket 7.4.0, all is fine
> 
> FranÃ§ois

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems upgrading from 7.4.0 to 7.5.0

On 2016-10-27 12:24 (+0200), Martin Grigorov  wrote: 
> On Thu, Oct 27, 2016 at 12:19 PM, Francesco ChicchiriccÃ² <
> ilgro...@apache.org> wrote:
> 
> > On 2016-10-27 11:26 (+0200), Martin Grigorov  wrote:
> > > Hi,
> > >
> > > On Thu, Oct 27, 2016 at 10:28 AM, Francesco ChicchiriccÃ² 
> > >  wrote:
> > >
> > > > Hi all,
> > > > I am trying to upgrade the Apache Syncope console from 7.4.0 to recent
> > > > 7.5.0, but I am experiencing some troubles.
> > > >
> > > > First, I had to remove
> > > >
> > > > 
> > > >
> > > > from [1], since Wicket was complaining that the  element had
> > to be
> > > > closed (?): now things are working fine again (as it used to do up to
> > > > 7.4.0), but I honestly do not understand why.
> > > >
> > >
> > > What do you mean by "now it works fine" ?
> > > How do you get the i18n-ed value of "submit" now ?
> >
> > This was answered by Sven.
> >
> > > > Now I am getting [2] and AFAIU this depends on the fact that the
> > > > WebSocketSettings I am using in [3] have a null or empty
> > 'filterPrefix':
> > > > again, this works perfectly fine with 7.4.0.
> > > >
> > >
> > > Please file a bug for [2]. It is a regression.
> >
> > Sure: WICKET-6262
> >
> 
> Thanks!
> 
> 
> >
> > Any clever workaround, in the meanwhile?
> >
> 
> The only way I see is to copy/paste the whole #renderHead() and replace Args
> .notEmpty(filterPrefix, "filterPrefix"); with Args.notNull(filterPrefix, "
> filterPrefix");
> 

Unfortunately, BaseWebSocketBehavior#resourceName is private...

> >
> > > Most probably [1] is also a bug but I have to try it. Please create a
> > > ticket for it too.
> >
> > Given Sven's reply, I will not create a ticket for this.
> >
> 
> I'll see whether it is possible to give a better error message
> 
> 
> >
> > Thanks for your support.
> > Regards.
> >
> > > > Any hint? Thanks.
> > > > Regards.
> > > >
> > > > [1] https://github.com/apache/syncope/blob/2_0_X/client/
> > > > console/src/main/resources/org/apache/syncope/client/
> > > > console/pages/Login.html#L58-L59
> > > > [2] https://paste.apache.org/YSzq
> > > > [3] https://github.com/apache/syncope/blob/2_0_X/client/
> > > > console/src/main/java/org/apache/syncope/client/console/
> > > > pages/BasePage.java#L91

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems upgrading from 7.4.0 to 7.5.0

On 2016-10-27 11:26 (+0200), Martin Grigorov  wrote: 
> Hi,
> 
> On Thu, Oct 27, 2016 at 10:28 AM, Francesco ChicchiriccÃ² <
> ilgro...@apache.org> wrote:
> 
> > Hi all,
> > I am trying to upgrade the Apache Syncope console from 7.4.0 to recent
> > 7.5.0, but I am experiencing some troubles.
> >
> > First, I had to remove
> >
> > 
> >
> > from [1], since Wicket was complaining that the  element had to be
> > closed (?): now things are working fine again (as it used to do up to
> > 7.4.0), but I honestly do not understand why.
> >
> 
> What do you mean by "now it works fine" ?
> How do you get the i18n-ed value of "submit" now ?

This was answered by Sven.

> > Now I am getting [2] and AFAIU this depends on the fact that the
> > WebSocketSettings I am using in [3] have a null or empty 'filterPrefix':
> > again, this works perfectly fine with 7.4.0.
> >
> 
> Please file a bug for [2]. It is a regression.

Sure: WICKET-6262

Any clever workaround, in the meanwhile?

> Most probably [1] is also a bug but I have to try it. Please create a
> ticket for it too.

Given Sven's reply, I will not create a ticket for this.

Thanks for your support.
Regards.

> > Any hint? Thanks.
> > Regards.
> >
> > [1] https://github.com/apache/syncope/blob/2_0_X/client/
> > console/src/main/resources/org/apache/syncope/client/
> > console/pages/Login.html#L58-L59
> > [2] https://paste.apache.org/YSzq
> > [3] https://github.com/apache/syncope/blob/2_0_X/client/
> > console/src/main/java/org/apache/syncope/client/console/
> > pages/BasePage.java#L91
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problems upgrading from 7.4.0 to 7.5.0

On 2016-10-27 11:30 (+0200), Sven Meier  wrote: 
> Hi,
> 
> [1] does your button have a model object?

Yes, it does.
 
> Since WICKET-6225 the model object is used to replace the component 
> body, if you're using a  tag.
> Previously the model object was used for the value of an  tag only.

Ah, now it makes sense, thanks.

I would suggest adding this to the 7.5.0 release notes, which pretend it to be 
a "drop-in replacement".

Regards.

> Am 27.10.2016 um 10:28 schrieb Francesco Chicchiricc:
> > Hi all,
> > I am trying to upgrade the Apache Syncope console from 7.4.0 to recent 
> > 7.5.0, but I am experiencing some troubles.
> >
> > First, I had to remove
> >
> > 
> >
> > from [1], since Wicket was complaining that the  element had to be 
> > closed (?): now things are working fine again (as it used to do up to 
> > 7.4.0), but I honestly do not understand why.
> >
> > Now I am getting [2] and AFAIU this depends on the fact that the 
> > WebSocketSettings I am using in [3] have a null or empty 'filterPrefix': 
> > again, this works perfectly fine with 7.4.0.
> >
> > Any hint? Thanks.
> > Regards.
> >
> > [1] 
> > https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/resources/org/apache/syncope/client/console/pages/Login.html#L58-L59
> > [2] https://paste.apache.org/YSzq
> > [3] 
> > https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/pages/BasePage.java#L91
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Problems upgrading from 7.4.0 to 7.5.0