Re: Issues with refreshing panel with form

2020-08-04 Thread Martin Grigorov
On Tue, Aug 4, 2020 at 2:53 PM Zimen, Michal 
wrote:

> Thanks,
>
>  Well, snippets from source code might come later. My concerns are, that
> the issue I’m facing is related to this
> https://issues.apache.org/jira/browse/WICKET-6041
> None weird logs have been found on both sides.
>
> DialogA with a nested form uses POST to update its stuff, but the dialogB
> handle its work through GET only(no form submission).
>
> I was trying to catch the root form submission in form.onSubmit(), but I
> found out, that this is not called, since the
> wantSubmitOnNestedFormSubmit() returns false.
> Therefore I conclude, that after POST request, other references among
> components are broken.
>

What do you mean with this ?


>
> The question might be: How to "refresh" or keep these references after
> nested form is submitted?
>
> Thanks a lot,
>
>
>  M.
>
> -Original Message-
> From: Martin Grigorov 
> Sent: Tuesday, August 4, 2020 10:31 AM
> To: users@wicket.apache.org
> Subject: Re: Issues with refreshing panel with form
>
> Hi,
>
> On Mon, Aug 3, 2020 at 2:53 PM Zimen, Michal 
> wrote:
>
> > Hi Wicket Users,
> >
> >
> >I've just started to learn the Wicket by fixing some issues in our
> > legacy backlog repository.
> >
> > Therefore, I need some clarification to manage my blockpoints. Having
> > spent enough time to fix it by myself, I finally must turn out to this
> > help.
> >
> > The weird problem could be described following:
> >
> >
> >   1.  A base form contains components and links to
> > AbstractFormDialog(Jquery-ui) for user inputs.
> >   2.  When the formDialogA is submitted, some parent components are
> > updated, some remain empty, as it is expected.
> >   3.  Another modal formDialogB is open and submitted and expecting
> > components are not updated.
> >
> > When this procedure is done in swapped sequence - firstly formDialogB
> > and then formDialogA is opened, everything works ok.
> >
> > Seems as if, the submitting formDialogA breaks the references for
> > submission formDialogB.
> >
> > Could you please clarify me, what should be checked to avoid this
> problem?
> >
>
> I'd suggest these two things:
> 1) check for errors both in the server logs and in the browser
> 2) use a FeedbackPanel to show any validation errors in all Forms. I.e. if
> you override #onSubmit()/#onUpdate() then make sure you also override
> #onError() and if you use Ajax then add the FeedbackPanel to the
> AjaxRequestTarget
>
>
> >
> > Thanks,
> >
> >M.
> >
> >
> >
> > Michal Zimen
> > e-mail: michal.zi...@anasoft.com
> >
> >
>


Re: Issues with refreshing panel with form

2020-08-04 Thread Martin Grigorov
Hi,

On Mon, Aug 3, 2020 at 2:53 PM Zimen, Michal 
wrote:

> Hi Wicket Users,
>
>
>I've just started to learn the Wicket by fixing some issues in our
> legacy backlog repository.
>
> Therefore, I need some clarification to manage my blockpoints. Having
> spent enough time to fix it by myself,
> I finally must turn out to this help.
>
> The weird problem could be described following:
>
>
>   1.  A base form contains components and links to
> AbstractFormDialog(Jquery-ui) for user inputs.
>   2.  When the formDialogA is submitted, some parent components are
> updated, some remain empty, as it is expected.
>   3.  Another modal formDialogB is open and submitted and expecting
> components are not updated.
>
> When this procedure is done in swapped sequence - firstly formDialogB and
> then formDialogA is opened, everything works ok.
>
> Seems as if, the submitting formDialogA breaks the references for
> submission formDialogB.
>
> Could you please clarify me, what should be checked to avoid this problem?
>

I'd suggest these two things:
1) check for errors both in the server logs and in the browser
2) use a FeedbackPanel to show any validation errors in all Forms. I.e. if
you override #onSubmit()/#onUpdate() then make sure you also override
#onError() and if you use Ajax then add the FeedbackPanel to the
AjaxRequestTarget


>
> Thanks,
>
>M.
>
>
>
> Michal Zimen
> e-mail: michal.zi...@anasoft.com
>
>


Re: Page with AjaxSelfUpdatingTimerBehavior in multiple browser tabs

2020-07-28 Thread Martin Grigorov
Hi,

On Tue, Jul 28, 2020 at 11:09 AM Zbynek Vavros 
wrote:

> Hi,
>
> We have a page with AjaxSelfUpdatingTimerBehavior and now one of our
> customers is complaining about "weird" behavior when this page is opened in
> multiple browser tabs (yeah yeah we told him not to do it...).
>
> What happens is that after opening this page in new tab, the previous tab
> gets ajax redirect on mentioned timer.
>
> After some digging I found out that this is happening because the page is
> stateful.
> Excerpt from Wicket code:
>
> // If the page is stateful then we cannot assume that the listener
> interface is
> // invoked on its initial state (right after page initialization) and that
> its
> // component and/or behavior will be available. That's why the listener
> interface
> // should be ignored and the best we can do is to re-paint the newly
> constructed
> // page.
>
> I did use StatelessChecker (very useful!) and found out that the reason is
> this AjaxSelfUpdatingTimerBehavior.
>
> Googling around I found this thread from 2011 -
>
> http://apache-wicket.1842946.n4.nabble.com/Stateless-page-with-an-auto-update-section-td3795927.html
> .
> The suggestion here is to "roll your own timer behavior".
>
> Well, I spent some time with Wicket already but this is beyond my
> knowledge. Can anyone please point me the right direction? Is this even
> possible? I just have to say the AjaxSelfUpdatingTimerBehavior must stay -
> this page displays progress bar of background task that is non-negotiable.
>

Try by overwriting AjaxSelfUpdatingTimerBehavior#getStatelessHint() and
return true.
Depending on how complex is your logic in #onTimer() it may work or not.
See https://stackoverflow.com/a/10589807/497381 for more details. We
integrated the Jolira's Wicket-Stateless approach in Wicket core since
ver.7.4.0.


>
> Thanks,
> Zbynek
>


Re: Lambda expressions on StringResourceModel does not work

2020-07-14 Thread Martin Grigorov
Hi again,

On Tue, Jul 14, 2020 at 10:46 AM Martin Grigorov 
wrote:

> Hi,
>
> On Tue, Jul 14, 2020 at 10:10 AM Alberto  wrote:
>
>>
>> Hello,
>>
>> I have a StringResourceModel in a parent abstract class of all pages.
>>
>> IModel titleModel = new StringResourceModel("contentTitle",
>> getModel());
>>
>> where "contentTitle" is a property specified for every child page in
>> specific
>> property files and getModel() returns a chain of a CompoundPropertyModel
>> and a
>> LoadableDetachableModel.
>>
>> If I simple use it, it works:
>>
>> add(new Label("pageTitle", titleModel));
>>
>>
>> But if I apply a lambda expression to it (for example):
>>
>> add(new Label("pageTitle", titleModel.map(String::trim)));
>>
>> I have an exception.:
>>
>> java.util.MissingResourceException: Unable to find property:
>> 'contentTitle'.
>> Locale: null, style: null
>>
>>
>> Why it happens?
>>
>
> Because .map() returns a new IModel that does not
> implement IComponentAssignedModel and Wicket cannot find the property in
> the visible resource bundles.
> I.e. your properties are in MyPage.properties and Wicket does not look
> into them because the model does not know the Component it is assigned to.
> If the property is in MyApplication.properties then it will work, because
> this is not related to specific Component.
>
> Please file a ticket in JIRA. I think this could be improved.
>

I just took a look at your ticket (
https://issues.apache.org/jira/browse/WICKET-6801) and it is not exactly as
I thought it is.

add(new Label("pageTitle", titleModel.map(String::trim)));

at this line titleModel doesn't yet know its component because at the time
IModel#map() is called titleModel is not yet added as a model to the Label
and thus IComponentAssignedModel is not yet involved.
The new IModel returned by .map() does not implement
IComponentAssignedModel and thus it cannot delegate the
#wrapOnAssignment(Component) call.

The good news for you is that you can use IModel titleModel = new
StringResourceModel("contentTitle", *this*, getModel()); to solve your
problem. By passing 'this' as parameter you tell StringResourceModel to use
it instead of depending on
the Component it is added to (the Label in this case).

I'll see what I can do for WICKET-6801!


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


Re: Change pageId Parameter structure

2020-07-14 Thread Martin Grigorov
On Tue, Jul 14, 2020 at 3:54 PM Ravi Knox  wrote:

> Hi Martin,
>
>
>
> that was a good starting point, thank you.
>
> I had to overwrite basically all Mappers within the SystemMapper and mounts
> (since they create mappers themselves).
>
>
>
> The following Methods I had to overwrite:
>
> -#encodePageComponentInfo - for adding the custom page param
>
> -#getPageComponentInfo - for reading the custom page param as
> component id
>
> -#extractPageParameters - to remove the custom page param from the
> parameter list
>
>
>
> Does that make sense to you or did I miss something?
>

I didn't expect that you will need to overwrite all mappers but I haven't
tried myself such thing so I am not fully certain how many changes are
needed.
I've expected that you will need MyPageInstanceMapper registered and this
one is either consulted before the original one or produces a better
compatibility score.


>
>
>
> Thanks,
>
>
>
> Ravi
>
>
>
> 
>
> Hi Ravi,
>
>
>
> The logic you look for is at
>
>
> https://github.com/apache/wicket/blob/267fb06eec31e8e530fb5f0a4f691a0782e3d5
>
> b8/wicket-core/src/main/java/org/apache/wicket/core/request/mapper/AbstractC
> omponentMapper.java#L79
> 
>
> It is called by:
>
>
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/a
> pache/wicket/core/request/mapper/PageInstanceMapper.java#L133
> 
>
>
>
> You will need to use custom version of PageInstanceMapper that overrides
>
> protected void encodePageComponentInfo(Url url, PageComponentInfo info)
>
>
>
> On Mon, Jul 13, 2020 at 8:40 AM Ravi Knox  wrote:
>
>
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > my client has a website, where he includes our Wicket application (Wicket
>
> > 8.3.0) via JQuery.load() in his template.
>
> >
>
> > Because of a Reverse-Proxy, he has to whitelist all PageParameters.
>
> >
>
> >
>
> >
>
> > To keep it short;
>
> >
>
> > We need to change the pageId Parameter to something like
>
> > "myapp.com/homepage?pageId=1".
>
> >
>
> >
>
> >
>
> > After reading source code and googleing I couldn't find a way to do this.
>
> >
>
> > Is it even possible? If so, where would be the place to look for?
>
> >
>
> >
>
> >
>
> > Thanks for any hints,
>
> >
>
> >
>
> >
>
> > Ravi
>
> >
>
> >
>
>
>
> 
>
> Quoted from:
>
>
> http://apache-wicket.1842946.n4.nabble.com/Change-pageId-Parameter-structure
> -tp4684229p4684233.html
> 
>
>


Re: Lambda expressions on StringResourceModel does not work

2020-07-14 Thread Martin Grigorov
Hi,

On Tue, Jul 14, 2020 at 10:10 AM Alberto  wrote:

>
> Hello,
>
> I have a StringResourceModel in a parent abstract class of all pages.
>
> IModel titleModel = new StringResourceModel("contentTitle",
> getModel());
>
> where "contentTitle" is a property specified for every child page in
> specific
> property files and getModel() returns a chain of a CompoundPropertyModel
> and a
> LoadableDetachableModel.
>
> If I simple use it, it works:
>
> add(new Label("pageTitle", titleModel));
>
>
> But if I apply a lambda expression to it (for example):
>
> add(new Label("pageTitle", titleModel.map(String::trim)));
>
> I have an exception.:
>
> java.util.MissingResourceException: Unable to find property:
> 'contentTitle'.
> Locale: null, style: null
>
>
> Why it happens?
>

Because .map() returns a new IModel that does not
implement IComponentAssignedModel and Wicket cannot find the property in
the visible resource bundles.
I.e. your properties are in MyPage.properties and Wicket does not look into
them because the model does not know the Component it is assigned to.
If the property is in MyApplication.properties then it will work, because
this is not related to specific Component.

Please file a ticket in JIRA. I think this could be improved.


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


Re: Change pageId Parameter structure

2020-07-13 Thread Martin Grigorov
Hi Ravi,

The logic you look for is at
https://github.com/apache/wicket/blob/267fb06eec31e8e530fb5f0a4f691a0782e3d5b8/wicket-core/src/main/java/org/apache/wicket/core/request/mapper/AbstractComponentMapper.java#L79
It is called by:
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/request/mapper/PageInstanceMapper.java#L133

You will need to use custom version of PageInstanceMapper that overrides
protected void encodePageComponentInfo(Url url, PageComponentInfo info)

On Mon, Jul 13, 2020 at 8:40 AM Ravi Knox  wrote:

> Hi all,
>
>
>
> my client has a website, where he includes our Wicket application (Wicket
> 8.3.0) via JQuery.load() in his template.
>
> Because of a Reverse-Proxy, he has to whitelist all PageParameters.
>
>
>
> To keep it short;
>
> We need to change the pageId Parameter to something like
> "myapp.com/homepage?pageId=1".
>
>
>
> After reading source code and googleing I couldn't find a way to do this.
>
> Is it even possible? If so, where would be the place to look for?
>
>
>
> Thanks for any hints,
>
>
>
> Ravi
>
>


Re: Preventing the ModalWindow from being rendered as iframe

2020-07-07 Thread Martin Grigorov
Hi,

On Tue, Jul 7, 2020 at 1:26 PM Lukas Fülling 
wrote:

> Hi,
>
> I'm currently trying to get Javascript callbacks from/to a Wicket
> ModalWindow to work.
> Currently, the WebPage the ModalWindow consis of is being redered as an
> iframe.
>
> The Wicket documentation states the following:
>
> > Modal window is a draggable window (with either div or iframe content)
> > that prevent user from interacting the rest of page (using a mask)
> > until the window is closed.
> (
> https://ci.apache.org/projects/wicket/apidocs/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.html
> )
>
> Unfortunately I can't find any info on how to make the ModalWindow being
> rendered as a div instead of an iframe and I wondered if someone on this
> list knows how to do it.
>

You should use ModelWindow#setContent(new SomePanel()) instead of passing
it a Page with ModalWindow#setPageCreator().


>
> Thanks for you help
>
> Lukas
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Page locked for a long time

2020-07-06 Thread Martin Grigorov
On Sun, Jul 5, 2020 at 9:16 PM Sven Meier  wrote:

> Hi Maxim,
>
> you'll have to upload these files to a resource separately.
>
> I'm not aware of a reusable solution for that.
>

Here is a blog article on this topic:
http://wicketinaction.com/2012/11/uploading-files-to-wicket-iresource/ and
its demo app: https://github.com/martin-g/blogs/tree/master/file-upload


>
> Have fun
> Sven
>
>
> On 05.07.20 17:20, Maxim Solodovnik wrote:
> > Hello All,
> >
> > our app allows huge file uploads
> > I have noticed the page is locked while incoming input stream is being
> > copied
> > (might take more than an hour)
> >
> >   at java.base@11.0.7/java.io.InputStream.read(InputStream.java:205)
> > at org.apache.commons.fileupload.util.Streams.copy(Streams.java:98)
> > at org.apache.commons.fileupload.util.Streams.copy(Streams.java:68)
> > at
> >
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:346)
> > at
> >
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequestImpl.parseFileParts(MultipartServletWebRequestImpl.java:196)
> > at
> org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1470)
> >
> > Are there any options to prevent page lock?
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Focusout event fires twice

2020-06-13 Thread Martin Grigorov
Hi Claudia,

I'd suggest you to use your browser's Dev Tools and put a breakpoint on
'focusout' event and see how many times it fires and what is the
reason/initiator.

On Fri, Jun 12, 2020 at 11:56 AM Claudia Beck  wrote:

> Hi all,
>
> i came across the issue when binding a focusout event to a text field,
> it fires twices each time when leaving the textfield.
>
> Example code:
>
> TextField textbox = new TextField<>("textbox");
> textbox.add(new AjaxEventBehavior("focusout") {
>  @Override
>  protected void onEvent(AjaxRequestTarget target) {
>  System.out.println("Focus lost on TextField");
>  }
> });
> add(textbox);
>
> This does not happen for blur event. Can this may be caused by event
> bubbling of focusout?
>
> Best regards,
> Claudia Beck
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Locatable UnsupportedOperationException

2020-06-01 Thread Martin Grigorov
https://issues.apache.org/jira/browse/WICKET-6796

On Mon, Jun 1, 2020 at 4:08 PM Sven Meier  wrote:

> +1 that should have no negative impact
>
> Sven
>
> On 01.06.20 11:22, Martin Grigorov wrote:
> > Hi,
> >
> > I like the idea to catch UnsupportedOperationException at
> > org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
> > throw new WicketRuntimeException("You need to use read/write Model for
> > component '{}", this.getPageRelativePath(), uox)
> >
> > Does anyone see a drawback ?
> >
> > Martin
> >
> > On Sat, May 30, 2020 at 11:42 PM Sven Meier  wrote:
> >
> >> Hi,
> >>
> >> just put a breakpoint on IModel#setObject().
> >>
> >> Once your problem hits that breakpoint, you'll be able to derive the
> >> offending component/model from the stacktrace/variables in your favorite
> >> IDE.
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >> On 30.05.20 17:13, smallufo wrote:
> >>> Is it possible to try { setObjectObject(value) } catch { e }
> >>> and pinpoint which class/model causes this problem ?
> >>> Or is it too costly ?
> >>>
> >>>
> >>> Francois Meillet  於 2020年5月30日 週六
> 下午11:02寫道:
> >>>
> >>>> Hope that help
> >>>>
> >>>> During the process of throwing an exception, the Java Virtual Machine
> >>>> abruptly completes, one by one, any expressions, statements, method
> and
> >>>> constructor invocations, initializers, and field initialization
> >> expressions
> >>>> that have begun but not completed execution in the current thread.
> This
> >>>> process continues until a handler is found that indicates that it
> >> handles
> >>>> that particular exception by naming the class of the exception or a
> >>>> superclass of the class of the exception (§11.2 <
> >>>>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2
> >>> ).
> >>>> If no such handler is found, then the exception may be handled by one
> >> of a
> >>>> hierarchy of uncaught exception handlers (§11.3 <
> >>>>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3
> >>> )
> >>>> - thus every effort is made to avoid letting an exception go
> unhandled.
> >>>>
> >>>> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
> >>>> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
> >>>>
> >>>>
> >>>> François
> >>>>
> >>>>
> >>>>
> >>>>> Le 30 mai 2020 à 16:52, smallufo  a écrit :
> >>>>>
> >>>>> Francois Meillet  於 2020年5月30日 週六
> >> 下午10:48寫道:
> >>>>>> sompage?67-1.-border-content-border_body-form is the path to your
> >> model
> >>>>> Yes , but it may contains deep-nested model
> >>>>>
> >>>>> The form contains FormComponentPanel and contains another
> >>>>> FormComponentPanels and widgets , very deep ...
> >>>>> The error may lay under very deep model , which is very hard to
> debug.
> >>>>> And the error message should be able to pinpoint which model causes
> the
> >>>>> problem
> >> -
> >> 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: Locatable UnsupportedOperationException

2020-06-01 Thread Martin Grigorov
Hi,

I like the idea to catch UnsupportedOperationException at
org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
throw new WicketRuntimeException("You need to use read/write Model for
component '{}", this.getPageRelativePath(), uox)

Does anyone see a drawback ?

Martin

On Sat, May 30, 2020 at 11:42 PM Sven Meier  wrote:

> Hi,
>
> just put a breakpoint on IModel#setObject().
>
> Once your problem hits that breakpoint, you'll be able to derive the
> offending component/model from the stacktrace/variables in your favorite
> IDE.
>
> Have fun
> Sven
>
>
> On 30.05.20 17:13, smallufo wrote:
> > Is it possible to try { setObjectObject(value) } catch { e }
> > and pinpoint which class/model causes this problem ?
> > Or is it too costly ?
> >
> >
> > Francois Meillet  於 2020年5月30日 週六 下午11:02寫道:
> >
> >> Hope that help
> >>
> >> During the process of throwing an exception, the Java Virtual Machine
> >> abruptly completes, one by one, any expressions, statements, method and
> >> constructor invocations, initializers, and field initialization
> expressions
> >> that have begun but not completed execution in the current thread. This
> >> process continues until a handler is found that indicates that it
> handles
> >> that particular exception by naming the class of the exception or a
> >> superclass of the class of the exception (§11.2 <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2
> >).
> >> If no such handler is found, then the exception may be handled by one
> of a
> >> hierarchy of uncaught exception handlers (§11.3 <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3
> >)
> >> - thus every effort is made to avoid letting an exception go unhandled.
> >>
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
> >>
> >>
> >> François
> >>
> >>
> >>
> >>> Le 30 mai 2020 à 16:52, smallufo  a écrit :
> >>>
> >>> Francois Meillet  於 2020年5月30日 週六
> 下午10:48寫道:
> >>>
>  sompage?67-1.-border-content-border_body-form is the path to your
> model
> 
> >>> Yes , but it may contains deep-nested model
> >>>
> >>> The form contains FormComponentPanel and contains another
> >>> FormComponentPanels and widgets , very deep ...
> >>> The error may lay under very deep model , which is very hard to debug.
> >>> And the error message should be able to pinpoint which model causes the
> >>> problem
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: WebSocket concurrent modification

2020-05-28 Thread Martin Grigorov
On Thu, May 28, 2020 at 9:43 AM fanfy  wrote:

> Hello,I finally found the problem ... It seems that I didn't understood
> very
> well how to use WebSocketMessageBroadcaster from wicket-spring-boot. The
> proper way to broadcast websocket messages from an ajax call is to use
> org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster with an
> additional configuration of the Executor that must broadcast the messages
> using a separate threadFor example, if using springframework (with wicket
> application as a bean) you must configure the executor:
> java.util.concurrent.Executor executor =
> Executors.newSingleThreadExecutor();
>
> WebSocketSettings.Holder.get(webApplication).setWebSocketPushMessageExecutor(new
> Executor() {@Override
>  public void run(Runnable command) {
> executor.execute(command);  }   });
> To broadcast messages from business code you can use spring events
> (published from your business code) To broadcast from ajax handlers inject
> this bean and call broadcastToAll(event) directly.
> /** *  * @author Elvis Ciocoiu * */@Componentpublic class
> TaskEventWebSocketBroadcaster { private WebSocketPushBroadcaster
> broadcaster;@Autowired private Application application;
>  @PostConstruct
> public void init() {WebSocketSettings webSocketSettings =
> WebSocketSettings.Holder.get(application);
> IWebSocketConnectionRegistry
> webSocketConnectionRegistry = webSocketSettings.getConnectionRegistry();
>
> broadcaster = new WebSocketPushBroadcaster(webSocketConnectionRegistry);
>   }
> @EventListener  public void onTaskEvent(TaskEvent taskEvent) {
> broadcastToAll(taskEvent);  }   public void
> broadcastToAll(TaskEvent
> taskEvent) {broadcaster.broadcastAll(application, new
> TaskEventWebSocketPushMessage(taskEvent));  }   /**
> *   * @author Elvis
> Ciocoiu  *   */ public static class TaskEventWebSocketPushMessage
> implements
> IWebSocketPushMessage { private static final long serialVersionUID
> = 1L;
> private TaskEvent taskEvent;public
> TaskEventWebSocketPushMessage(TaskEvent taskEvent) {
> this.taskEvent =
> taskEvent;  }   public TaskEvent
> getTaskEvent() {   return taskEvent;   }
>}}
> I think these distinct scenarios (broadcast from ajaxhandler and from
> business thread) should be documented a little more in user guide. Sorry to
> waste your time.Thank you
>

https://issues.apache.org/jira/browse/WICKET-6791
https://github.com/apache/wicket/pull/435
Thank you!


>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version

2020-05-26 Thread Martin Grigorov
On Tue, May 26, 2020 at 11:59 AM Daniel Stoch 
wrote:

> I know that and for me this is not an issue either ;).
> But this "issue" is reported by some security scanners which checks
> for obsolete and backup files by adding "_old", "_bak", "_backup"
> suffix to filename of selected resource (css, js). And our Wicket
> application is serving such files as if indeed such old copies were
> available.
> So I'm only loudly thinking is it really no problem that we serve
> files with any text attached on the end of file name.
>

This is by design.
If it is not desired then you can use a custom strategy.


>
> --
> Daniel
>
>
> pon., 25 maj 2020 o 21:14 Carl-Eric Menzel 
> napisał(a):
> >
> > Sorry, didn't mean to sound dismissive. It's a valid point, just I'm
> > not seeing that anybody could get to anything otherwise unavailable.
> >
> > On Mon, 25 May 2020 21:02:08 +0200
> > Carl-Eric Menzel  wrote:
> >
> > > I think the point of this version decoration is not to ensure a
> > > particular version is requested, because typically only one version of
> > > a file is available in the application.
> > >
> > > The point is instead to defeat any caching, both in the browser and by
> > > proxies, which might serve the user an outdated version. So I don't
> > > think there needs to be any checking of that string.
> > >
> > > Or is there an actual security impact that I'm missing?
> > >
> > > Carl-Eric
> > >
> > > On Mon, 25 May 2020 20:47:36 +0200
> > > Daniel Stoch  wrote:
> > >
> > > > Hi,
> > > >
> > > > Each resource in Wicket is decorated using a version string in a
> > > > file name by default. It is implemented in
> > > > FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
> > > > or DEPLOYMENT mode it looks like:
> > > > jquery-ver-1590158412000.css
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
> > > >
> > > > There is a small security issue, that this strategy does not check
> > > > if this version is correctly calculated for specific resource and
> > > > accepts any string as a version identifier, eg.:
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
> > > > jquery-ver-XYZABCDEF.css
> > > > etc.
> > > >
> > > > Maybe we should add a check if version passed in request is correct?
> > > > There is partially such check done in decorateResponse() method. So
> > > > maybe it is enough to add else block here and raise some exception?
> > > >
> > > > @Override
> > > > public void decorateResponse(AbstractResource.ResourceResponse
> > > > response, IStaticCacheableResource resource) {
> > > >   String requestedVersion =
> > > > RequestCycle.get().getMetaData(URL_VERSION); String
> > > > calculatedVersion = this.resourceVersion.getVersion(resource); if
> > > > (calculatedVersion != null &&
> > > > calculatedVersion.equals(requestedVersion))
> > > > { response.setCacheDurationToMaximum();
> > > > response.setCacheScope(WebResponse.CacheScope.PUBLIC); } }
> > > >
> > > > --
> > > > Best regards,
> > > > Daniel Stoch
> > > >
> > > > -
> > > > 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
> > >
> >
> > 000
> >
> > -
> > 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: Wicket and Vue.js synergy

2020-05-08 Thread Martin Grigorov
Hi Илья,

7 years ago I've made a (small) integration with Ractive.js:
https://github.com/martin-g/wicket-ractive and blogged about it
https://wicketinaction.com/2013/08/surgical-ajax-updates-with-ractive-js/
IMO Vue.js has started as a fork from Ractive.js but Rich Harris says it
just influenced it: https://twitter.com/mtgrigorov/status/806531052743311360
 :-)
I like them both a lot!
You can use wicket-ractive as an inspiration! It just uses Ractive.js for
the Ajax updates (instead of Wicket's XML approach). I didn't go any
deeper, like integrating on component level

Have fun!

On Thu, May 7, 2020 at 6:40 AM Илья Нарыжный  wrote:

> Hello,
>
> I code on Wicket for around 10 years and on Vue JS for a few months
> and found a lot of in common between these frameworks. There are 100
> and 1 ways in Wicket how to integrate a front-end framework. But with
> pre-created Wicket library - integration might be even deeper and lead
> to a synergy effect.
>
> I've started to collect some ideas and "design notes" about the
> library which allows integrating Wicket and Vue on another level. I
> will really appreciate any feedback and more ideas and comments. Here
> is this document:
>
> https://docs.google.com/document/d/1Lj4LqebeZFkYGsfyC2K7upUl8VpBeAE49Q-BLtvhpFM/edit?usp=sharing
> Feel free to comment, edit or reply to this email.
>
>
> P.S. If you use telegram: lets chat in the group around Wicket -
> https://t.me/apache_wicket
> P.P.S. Reminder: here is a curated list of "awesome things" around
> Wicket: https://github.com/PhantomYdn/awesome-wicket . If you have
> something to propose: please feel free to make a PR or an issue.
>
> Thanks,
> Ilya
> -
> Orienteer(http://orienteer.org) - open source Business Application
> Platform
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: WebSocket onClose/onError/onAbort is not being called

2020-05-05 Thread Martin Grigorov
Hi Maxim,

On Fri, May 1, 2020 at 2:22 PM Maxim Solodovnik 
wrote:

> On Fri, 1 May 2020 at 18:15, Martin Grigorov  wrote:
>
> > Hi Maxim,
> >
> > On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
> > wrote:
> >
> > > Hello Martin,
> > >
> > > WicketEndpoint#onError is being called
> > >  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > [EventExec-e2-t9] - An error occurred in web socket connection with id
> :
> > > 10"
> > >
> > > The problem WebSocketBehavior#onError is not being called
> > > So my application doesn't get notified the connection has been closed
> > 
> > >
> >
> > Then it must be somewhere in Wicket.
> > Check that [2] is called.
> >
>
> Yes it is called
>
>
> > Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
> >
>
> [3] and [4] are not called
> As you can see from the log branch at
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L299
> is in effect:
>

At
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L223
we
check
whether the connection is still opened or it is a ClosedMessage.
ClosedMessage is broadcasted exactly for this reason:
https://github.com/apache/wicket/commit/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6
We should simplify this condition to allow ErrorMessage too. Maybe even
AbortedMessage.
For the erroneous kind of messages we can even remove the connection from
the registry at the bottom of this method.
Please play with it and suggest a change!

Martin


> DEBUG 05-01 16:10:21.741 o.a.w.p.w.a.AbstractWebSocketProcessor:299
> [EventExec-e2-t9] - Either there is no
>
> connection(org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection@43539f89
> )
> or it is closed.
>
>
>
>
> > won't find your behavior if it is not enabled or any of if its component
> > hierarchy is disabled/invisible.
> >
> >
> > 2.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
> > 3.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
> > 4. *
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > <
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > >*
> > 5.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86
> >
> >
> > > :(
> > >
> > > On Fri, 1 May 2020 at 17:12, Martin Grigorov 
> > wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > If WicketEndpoint#onError() [1] is not called then probably there is
> a
> > > bug
> > > > in Tomcat.
> > > > I suggest you to post this question at Tomcat's users@.
> > > >
> > > > 1.
> > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
> > > >
> > > >
> > > > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm having weird situation: WebSocket connection is closed on page
> > > > reload,
> > > > > but none of my onClose/onError/onAbort handlers are being called
> > > > > I have changed wicket version to latest SNAPSHOT and got some debug
> > > logs:
> > > > >
> > 

Re: WebSocket onClose/onError/onAbort is not being called

2020-05-01 Thread Martin Grigorov
Hi Maxim,

On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
wrote:

> Hello Martin,
>
> WicketEndpoint#onError is being called
>  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> [EventExec-e2-t9] - An error occurred in web socket connection with id :
> 10"
>
> The problem WebSocketBehavior#onError is not being called
> So my application doesn't get notified the connection has been closed 
>

Then it must be somewhere in Wicket.
Check that [2] is called.
Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
won't find your behavior if it is not enabled or any of if its component
hierarchy is disabled/invisible.


2.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
3.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
4. 
*https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
<https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69>*
5.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86


> :(
>
> On Fri, 1 May 2020 at 17:12, Martin Grigorov  wrote:
>
> > Hi Maxim,
> >
> > If WicketEndpoint#onError() [1] is not called then probably there is a
> bug
> > in Tomcat.
> > I suggest you to post this question at Tomcat's users@.
> >
> > 1.
> >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
> >
> >
> > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik 
> > wrote:
> >
> > > Hello,
> > >
> > > I'm having weird situation: WebSocket connection is closed on page
> > reload,
> > > but none of my onClose/onError/onAbort handlers are being called
> > > I have changed wicket version to latest SNAPSHOT and got some debug
> logs:
> > >
> > > *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > [EventExec-e2-t9] - An error occurred in web socket connection with id
> > > : 10
> > > java.io.IOException: java.io.IOException: Broken pipe
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> > > at
> > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> > > at
> > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> > > at org.apache.wicket.protocol.ws
> > >
> >
> .javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
> > > at
> > >
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
> > > at
> > >
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
> > > at org.apache.wicket.protocol.ws
> > > .WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
> > > at
> > >

Re: WebSocket onClose/onError/onAbort is not being called

2020-05-01 Thread Martin Grigorov
Hi Maxim,

If WicketEndpoint#onError() [1] is not called then probably there is a bug
in Tomcat.
I suggest you to post this question at Tomcat's users@.

1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92


On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik 
wrote:

> Hello,
>
> I'm having weird situation: WebSocket connection is closed on page reload,
> but none of my onClose/onError/onAbort handlers are being called
> I have changed wicket version to latest SNAPSHOT and got some debug logs:
>
> *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> [EventExec-e2-t9] - An error occurred in web socket connection with id
> : 10
> java.io.IOException: java.io.IOException: Broken pipe
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> at
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> at
> org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> at
> org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> at org.apache.wicket.protocol.ws
> .javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
> at org.apache.wicket.protocol.ws
> .WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:94)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:73)
> at
> org.apache.openmeetings.core.remote.KurentoHandler.sendClient(KurentoHandler.java:209)
> at
> org.apache.openmeetings.core.remote.KStream.lambda$createEndpoint$5(KStream.java:224)
> at
> org.kurento.client.internal.client.RemoteObjectInvocationHandler.propagateEventTo(RemoteObjectInvocationHandler.java:281)
> at
> org.kurento.client.internal.client.RemoteObjectInvocationHandler$1.onEvent(RemoteObjectInvocationHandler.java:208)
> at
> org.kurento.client.internal.client.RemoteObject.fireEvent(RemoteObject.java:345)
> at
> org.kurento.client.internal.client.RomClientObjectManager.processEvent(RomClientObjectManager.java:58)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.processEvent(RomClientJsonRpcClient.java:206)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.access$000(RomClientJsonRpcClient.java:74)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient$1.handleRequest(RomClientJsonRpcClient.java:182)
> at
> org.kurento.jsonrpc.internal.JsonRpcHandlerManager.handleRequest(JsonRpcHandlerManager.java:142)
> at
> org.kurento.jsonrpc.client.AbstractJsonRpcClientWebSocket$15.run(AbstractJsonRpcClientWebSocket.java:577)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.io.IOException: Broken pipe
> at java.base/sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at java.base/sun.nio.ch
> .SocketDispatcher.write(SocketDispatcher.java:47)
> at
> java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:113)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:79)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
> at java.base/sun.nio.ch
> .SocketChannelImpl.write(SocketChannelImpl.java:466)
> at org.apache.tomcat.util.net
> .SecureNioChannel.flush(SecureNioChannel.java:145)
> at org.apache.tomcat.util.net
> .SecureNioChannel.write(SecureNioChannel.java:851)
> at org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1491)
>

Re: SessionStore on database

2020-04-29 Thread Martin Grigorov
Hi

On Wed, Apr 29, 2020, 19:55 Andrea Del Bene  wrote:

> Hi,
>
> if you haven't done it yet you should have a look at WicketStuff data
> store projects:
>
> https://github.com/wicketstuff/core/tree/master/datastores-parent
>
>
> this should give you some good ideas.
>

The data stores distribute the pages.
Something else should be used to distribute the http sessions.


> On 29/04/20 17:30, Shengche Hsiao wrote:
> > Thomas, thanks for your opinion, I'll try it
> >
> > On Wed, Apr 29, 2020 at 2:49 PM Thomas Heigl 
> wrote:
> >
> >> Hi,
> >>
> >> There are two options I'm aware of:
> >>
> >> - You can use a session manager in your application server that stores
> your
> >> session in the database. I.e. Tomcat's JDBC store.
> >> - You can use Spring Session with a JDBC store
> >>
> >> I recently implemented Spring Session for Wicket with Redis as a backing
> >> store. There are minor issues with page locking that require some custom
> >> code, but otherwise it works fine.
> >>
> >> Best regards,
> >>
> >> Thomas
> >>
> >> On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao 
> wrote:
> >>
> >>> Dear all
> >>>
> >>> I want to implement cross datacenter session replication for my web
> app,
> >>> can I persist session on shared database? If it does, how can I do?
> >>>
> >>> I searched the web, and found org.apache.wicket.protocol.http.
> >>> SecondLevelCacheSessionStore.IClusteredPageStore
> >>>
> >>> I have an idea for implement above interface and persist session on
> >> target
> >>> database, right?
> >>>
> >>> 
> >>> --->
> >>> To boldly go where no man has gone before.
> >>> 
> >>> --->
> >>> We do this not because it is easy. We do this because it is hard.
> >>> -
> >>> -->
> >>> If I have seen further it is by standing on the shoulders of giants.
> >>> --
> >>> ->
> >>> front...@gmail.com
> >>>
> >>>
> >>
> ->
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: The AutoCompleteTextField model callback setObject() not working

2020-04-28 Thread Martin Grigorov
Hi,

On Tue, Apr 28, 2020 at 9:54 AM kyc  wrote:

> I am using wicket 7.14
>

Try to upgrade to 7.16.


>
> The following setObject is not called if I select the item from the list
> showing from AutoCompleteTextField.
> However, it will be called if I type something on the textfield.  I tried
>

If it works when you type something but it doesn't when you select an item
then it looks like a JavaScript error.
Check the browser Dev Tools Console for JS error and Network tab for Ajax
request.


> the wicket example with form surrounding the input tag and add
> AjaxFormSubmitBehavior which was still not working.  I also tried the blur
> event  suggested by some forum which also not work.   I was stuck on the
> problem for many days.
>
>
> final IModel model = new IModel()
> {
> private String value = null;
>
> @Override
> public String getObject()
> {
> return value;
> }
>
> @Override
> public void setObject(String object)
> {
> value = object;
> }
>
> @Override
> public void detach()
> {
> }
> };
>
>
> final AutoCompleteTextField sampleField = new
> AutoCompleteTextField("sample", model, String.class, settings){
> private static final long
> serialVersionUID = -2129392693264844597L;
>
>..
> }
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Martin Grigorov
Hi,


On Fri, Apr 24, 2020, 22:13 Igor Khvostenkov
 wrote:

> Problem is not in the application but in the configuration put proxy which
> does the redirect in front of the any application with form submit. IMHO
> this change https://issues.apache.org/jira/browse/WICKET-6708 does not
> keep in mind that it could be redirect call with GET request with POST
> parameters.
>

This change is fixing a security related issue.
In my opinion your proxy config is wrong. I don't understand "redirect call
with GET request with POST parameters".
Redirects are always GET. And their parameters are in the query string.

What does your proxy do with multipart POSTs?
What does it do with single part body that is too long to be in the query
string? Does it truncate it?


> -Igor.
>
> On 24. Apr 2020, at 20:57, Martin Grigorov  mgrigo...@apache.org>> wrote:
>
> Please create a demo application so we can take a look!
>
> On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov
>  igor.khvosten...@lindenbaum.eu.invalid>> wrote:
>
> Sven,
>
> Same stuff with crypto off. Here is with debugger on getParameterValues:
>
>
>
> -Igor.
>
> On 24. Apr 2020, at 18:51, Sven Meier  s...@meiers.net>> wrote:
>
> Hi,
>
> Request URL:
>
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
> Request Method:
> GET
>
> that is a GET request with query parameters.
>
> Form inputs should be able to pick up the values from the query parameters.
>
> Maybe the problem is related to the cryptoMapper? Could you disable it for
> a test?
>
> Have fun
> Sven
>
>
> On 24.04.20 17:43, Igor Khvostenkov wrote:
>
> Hi Sven,
>
> Yes exactly, but in fact this is POST. This is GET with POST parameters.
> And then FormComponent#getParameterValues(String inputName)
>
> case Form.METHOD_GET:
> parameters = request.getQueryParameters();
> break;
>
> Instead of
>
> case Form.METHOD_POST:
> parameters = request.getPostParameters();
> break;
>
> And I lost my POST parameters. Nothing works after.
>
> -Igor.
>
>
> On 24. Apr 2020, at 15:07, Sven Meier  mailto:s...@meiers.net mailto:s...@meiers.net>>>> wrote:
>
> Hi Igor,
>
> so the browser sends the request a second time via "get".
>
> That shouldn't be a problem, since in that case all FormComponents will
> read their parameters from the query parameters.
>
> So what is your actual problem?
>
> Have fun
> Sven
>
>
> On 24.04.20 11:34, Igor Khvostenkov wrote:
> Hi Martin,
>
> Thanks for the hint with "Preserve log”. Looks like still this is exactly
> what I described in reply to Sven. Browser does really POST request:
>
>
> *
> Request URL:
>
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
> *
> Request Method:
> POST
> *
> Status Code:
> 302
> *
> Remote Address:
> xxx:443
> *
> Referrer Policy:
> no-referrer-when-downgrade
>  1.  Response Headers
> *
> cache-control:
> no-cache, no-store
> *
> content-length:
> 0
> *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
> *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
> *
> location:
> ./DHB1U_x9J1dRXqDe8wegYw/DHB6d
> *
> pragma:
> no-cache
> *
> server:
> nginx
> *
> status:
> 302
>
> And then it gets redirect from proxy-server. And next request Browser
> substitutes POST to GET, as stated in RFC:
>
>
> *
> Request URL:
>
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
> *
> Request Method:
> GET
> *
> Status Code:
> 302
> *
> Remote Address:
> 10.1.37.99:443
> *
> Referrer Policy:
> no-referrer-when-downgrade
>  1.  Response Headers
> *
> cache-control:
> no-cache, no-store
> *
> content-length:
> 0
> *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
> *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
> *
> location:
> ./login.html?wicket-crypt=0SaMcpSjW2Y
> *
> pragma:
> no-cache
> *
> server:
> nginx
> *
> status:
> 302
>
> Am I missing something?
>
> -I

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Martin Grigorov
Please create a demo application so we can take a look!

On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov
 wrote:

> Sven,
>
> Same stuff with crypto off. Here is with debugger on getParameterValues:
>
>
>
> -Igor.
>
> On 24. Apr 2020, at 18:51, Sven Meier  wrote:
>
> Hi,
>
> >Request URL:
> >
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
> >Request Method:
> >GET
>
> that is a GET request with query parameters.
>
> Form inputs should be able to pick up the values from the query parameters.
>
> Maybe the problem is related to the cryptoMapper? Could you disable it for
> a test?
>
> Have fun
> Sven
>
>
> On 24.04.20 17:43, Igor Khvostenkov wrote:
>
> Hi Sven,
>
> Yes exactly, but in fact this is POST. This is GET with POST parameters.
> And then FormComponent#getParameterValues(String inputName)
>
> case Form.METHOD_GET:
>  parameters = request.getQueryParameters();
>  break;
>
> Instead of
>
> case Form.METHOD_POST:
>  parameters = request.getPostParameters();
>  break;
>
> And I lost my POST parameters. Nothing works after.
>
> -Igor.
>
>
> On 24. Apr 2020, at 15:07, Sven Meier  mailto:s...@meiers.net >> wrote:
>
> Hi Igor,
>
> so the browser sends the request a second time via "get".
>
> That shouldn't be a problem, since in that case all FormComponents will
> read their parameters from the query parameters.
>
> So what is your actual problem?
>
> Have fun
> Sven
>
>
> On 24.04.20 11:34, Igor Khvostenkov wrote:
> Hi Martin,
>
> Thanks for the hint with "Preserve log”. Looks like still this is exactly
> what I described in reply to Sven. Browser does really POST request:
>
>
>  *
> Request URL:
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
>  *
> Request Method:
> POST
>  *
> Status Code:
> 302
>  *
> Remote Address:
> xxx:443
>  *
> Referrer Policy:
> no-referrer-when-downgrade
>   1.  Response Headers
>  *
> cache-control:
> no-cache, no-store
>  *
> content-length:
> 0
>  *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
>  *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
>  *
> location:
> ./DHB1U_x9J1dRXqDe8wegYw/DHB6d
>  *
> pragma:
> no-cache
>  *
> server:
> nginx
>  *
> status:
> 302
>
> And then it gets redirect from proxy-server. And next request Browser
> substitutes POST to GET, as stated in RFC:
>
>
>  *
> Request URL:
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
>  *
> Request Method:
> GET
>  *
> Status Code:
> 302
>  *
> Remote Address:
> 10.1.37.99:443
>  *
> Referrer Policy:
> no-referrer-when-downgrade
>   1.  Response Headers
>  *
> cache-control:
> no-cache, no-store
>  *
> content-length:
> 0
>  *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
>  *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
>  *
> location:
> ./login.html?wicket-crypt=0SaMcpSjW2Y
>  *
> pragma:
> no-cache
>  *
> server:
> nginx
>  *
> status:
> 302
>
>  Am I missing something?
>
> -Igor.
>
> On 24. Apr 2020, at 09:41, Martin Grigorov  mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote:
>
> On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
>  igor.khvosten...@lindenbaum.eu.invalid> igor.khvosten...@lindenbaum.eu.invalid>> wrote:
>
> Hi Martin,
>
> Yes, this is login form with special “token".
>
> If this is PRG should I see POST request in Browser console? I see only
> GET. Exactly one I’ve posted. Meaning that Browser does the substitution.
>
>
> Yes, you should see POST with status 302 and then GET.
> But to see them both you need to check "Preserve log" in the Network tab.
> Otherwise the browser shows only the requests for the last load of the page
> (including the request for the page itself and all resources like
> css/js/images)
>
>
>
> -Igor.
>
> On 24. Apr 2020, at 06:02, Martin Grigorov  mgrigo...@apache.org><mailto:mgrigo

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Martin Grigorov
On Fri, Apr 24, 2020 at 12:34 PM Igor Khvostenkov
 wrote:

> Hi Martin,
>
> Thanks for the hint with "Preserve log”. Looks like still this is exactly
> what I described in reply to Sven. Browser does really POST request:
>
>
>  *
> Request URL:
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
>  *
> Request Method:
> POST
>  *
> Status Code:
> 302
>  *
> Remote Address:
> xxx:443
>  *
> Referrer Policy:
> no-referrer-when-downgrade
>   1.  Response Headers
>  *
> cache-control:
> no-cache, no-store
>  *
> content-length:
> 0
>  *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
>  *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
>  *
> location:
> ./DHB1U_x9J1dRXqDe8wegYw/DHB6d
>  *
> pragma:
> no-cache
>  *
> server:
> nginx
>  *
> status:
> 302
>
> And then it gets redirect from proxy-server. And next request Browser
> substitutes POST to GET, as stated in RFC:
>
>
>  *
> Request URL:
>
> https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
>  *
> Request Method:
> GET
>  *
> Status Code:
> 302
>  *
> Remote Address:
> 10.1.37.99:443
>  *
> Referrer Policy:
> no-referrer-when-downgrade
>   1.  Response Headers
>  *
> cache-control:
> no-cache, no-store
>  *
> content-length:
> 0
>  *
> date:
> Fri, 24 Apr 2020 09:17:33 GMT
>  *
> expires:
> Thu, 01 Jan 1970 00:00:00 GMT
>  *
> location:
> ./login.html?wicket-crypt=0SaMcpSjW2Y
>  *
> pragma:
> no-cache
>  *
> server:
> nginx
>  *
> status:
> 302
>
>  Am I missing something?
>

I don't know. You tell us :-)
Is there a problem with the functionality ?

As far as I understood until now the problem was that there is no POST
submit. Now you see that there is such.
I hope you have some log statements in your Form#onSubmit() and #onError()
and you can verify either of those is called.


>
> -Igor.
>
> On 24. Apr 2020, at 09:41, Martin Grigorov  mgrigo...@apache.org>> wrote:
>
> On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
>  igor.khvosten...@lindenbaum.eu.invalid>> wrote:
>
> Hi Martin,
>
> Yes, this is login form with special “token".
>
> If this is PRG should I see POST request in Browser console? I see only
> GET. Exactly one I’ve posted. Meaning that Browser does the substitution.
>
>
> Yes, you should see POST with status 302 and then GET.
> But to see them both you need to check "Preserve log" in the Network tab.
> Otherwise the browser shows only the requests for the last load of the page
> (including the request for the page itself and all resources like
> css/js/images)
>
>
>
> -Igor.
>
> On 24. Apr 2020, at 06:02, Martin Grigorov  mgrigo...@apache.org> mgrigo...@apache.org<mailto:mgrigo...@apache.org>>> wrote:
>
> Hi Igor,
>
>
>
> On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
>  igor.khvosten...@lindenbaum.eu.invalid> igor.khvosten...@lindenbaum.eu.invalid igor.khvosten...@lindenbaum.eu.invalid>>> wrote:
>
> Hi Sven,
>
> POST is substituted with GET by the HTTP client (Browser).
>
> A web-server, any web-server, returns a 301 or 302 redirect then Browser,
> on client side, will replace any type of request to GET. No server-side
> configuration or any http headers returned will not change that.
>
> -Igor.
>
>
> On 23. Apr 2020, at 22:47, Sven Meier  s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>> s...@meiers.net<mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote:
>
> Hi Igor,
>
> so you think the "post" is redirected to a "get"? Why should that be the
> case?
>
> Who issues this redirect?
>
> Best regards
> Sven
>
>
> On 23.04.20 22:37, Igor Khvostenkov wrote:
> Hi Sven,
>
> Thank you for your reply. I did some deep investigation in the problem and
> this is what I found:
>
> if the generated HTML contains method="post", the browser will send the
> form as post request.
> This is no exactly true. Or let’s say this is true not in all cases. The
> problem could happen when your web server returns a 301 or 302 redirect
> then Browser will replace any type of request to GE

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Martin Grigorov
On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
 wrote:

> Hi Martin,
>
> Yes, this is login form with special “token".
>
> If this is PRG should I see POST request in Browser console? I see only
> GET. Exactly one I’ve posted. Meaning that Browser does the substitution.
>

Yes, you should see POST with status 302 and then GET.
But to see them both you need to check "Preserve log" in the Network tab.
Otherwise the browser shows only the requests for the last load of the page
(including the request for the page itself and all resources like
css/js/images)


>
> -Igor.
>
> On 24. Apr 2020, at 06:02, Martin Grigorov  mgrigo...@apache.org>> wrote:
>
> Hi Igor,
>
>
>
> On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
>  igor.khvosten...@lindenbaum.eu.invalid>> wrote:
>
> Hi Sven,
>
> POST is substituted with GET by the HTTP client (Browser).
>
> A web-server, any web-server, returns a 301 or 302 redirect then Browser,
> on client side, will replace any type of request to GET. No server-side
> configuration or any http headers returned will not change that.
>
> -Igor.
>
>
> On 23. Apr 2020, at 22:47, Sven Meier  s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>>> wrote:
>
> Hi Igor,
>
> so you think the "post" is redirected to a "get"? Why should that be the
> case?
>
> Who issues this redirect?
>
> Best regards
> Sven
>
>
> On 23.04.20 22:37, Igor Khvostenkov wrote:
> Hi Sven,
>
> Thank you for your reply. I did some deep investigation in the problem and
> this is what I found:
>
> if the generated HTML contains method="post", the browser will send the
> form as post request.
> This is no exactly true. Or let’s say this is true not in all cases. The
> problem could happen when your web server returns a 301 or 302 redirect
> then Browser will replace any type of request to GET:
>
>
> Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068<
> https://tools.ietf.org/html/rfc2068> specify that the client is not
> allowed
>  to change the method on the redirected request.  However, most
>  existing user agent implementations treat 302 as if it were a 303
>  response, performing a GET on the Location field-value regardless
>  of the original request method. The status codes 303 and 307 have
>  been added for servers that wish to make unambiguously clear which
>  kind of reaction is expected of the client.
>
> This is exactly what happens in my case. And I can not really do anything
> here, this is how all Browsers work. This was working good until we
> upgraded to Wicket 7.16. There is one change which “broke” previously
> working stuff. This change
> https://issues.apache.org/jira/browse/WICKET-6708 and more precise this
> code
>
> https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98
> .
> Starting from Wicket 7.16 you distinguish between GET and POST in
> FormComponent#getInputAsArray() and for the form submit this will not work
> in case of redirect.
>
> -Igor.
>
> On 23. Apr 2020, at 17:15, Sven Meier  s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>><mailto:s...@meiers.net>> wrote:
>
> Hi,
>
> if the generated HTML contains method="post", the browser will send the
> form as post request.
>
> Without more detailed information, it's hard to find the error. Can you
> write a quickstart?
>
> Have fun
> Sven
>
>
> On 23.04.20 11:59, Igor Khvostenkov wrote:
> Hi *,
>
> I faced with the problem. When Wicket-generated URL contains jsessionId,
> form submitted with GET request, and not POST. If I remove jsessionId from
> URL, then normal POST request is done. I have no idea where this GET is
> coming from. I ovverode getMethod() to always return POST and issue still
> exist. Any ideas where I can look to figure out why GET request is done?
>
> Generated HTML:
>
> 
>
> 
> wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm"
> method="post"
>
> action="./login.html;jsessionid=8B3813A1300187D10FE8211AF47D9F7F?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm"
> wicketsource="Login.java:39">
> style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden"
> class="hidden-fields"> id="accessForm5_hf_0">  style="display:none"> Konferenz-Teilnehmer  class="form-group">   class="form-control" value="

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-23 Thread Martin Grigorov
Hi Igor,



On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
 wrote:

> Hi Sven,
>
> POST is substituted with GET by the HTTP client (Browser).
>
> A web-server, any web-server, returns a 301 or 302 redirect then Browser,
> on client side, will replace any type of request to GET. No server-side
> configuration or any http headers returned will not change that.
>
> -Igor.
>
>
> On 23. Apr 2020, at 22:47, Sven Meier  s...@meiers.net>> wrote:
>
> Hi Igor,
>
> so you think the "post" is redirected to a "get"? Why should that be the
> case?
>
> Who issues this redirect?
>
> Best regards
> Sven
>
>
> On 23.04.20 22:37, Igor Khvostenkov wrote:
> Hi Sven,
>
> Thank you for your reply. I did some deep investigation in the problem and
> this is what I found:
>
> if the generated HTML contains method="post", the browser will send the
> form as post request.
> This is no exactly true. Or let’s say this is true not in all cases. The
> problem could happen when your web server returns a 301 or 302 redirect
> then Browser will replace any type of request to GET:
>
>
> Note: RFC 1945 and RFC 2068<
> https://tools.ietf.org/html/rfc2068> specify that the client is not
> allowed
>   to change the method on the redirected request.  However, most
>   existing user agent implementations treat 302 as if it were a 303
>   response, performing a GET on the Location field-value regardless
>   of the original request method. The status codes 303 and 307 have
>   been added for servers that wish to make unambiguously clear which
>   kind of reaction is expected of the client.
>
> This is exactly what happens in my case. And I can not really do anything
> here, this is how all Browsers work. This was working good until we
> upgraded to Wicket 7.16. There is one change which “broke” previously
> working stuff. This change
> https://issues.apache.org/jira/browse/WICKET-6708 and more precise this
> code
> https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98.
> Starting from Wicket 7.16 you distinguish between GET and POST in
> FormComponent#getInputAsArray() and for the form submit this will not work
> in case of redirect.
>
> -Igor.
>
> On 23. Apr 2020, at 17:15, Sven Meier  s...@meiers.net>> wrote:
>
> Hi,
>
> if the generated HTML contains method="post", the browser will send the
> form as post request.
>
> Without more detailed information, it's hard to find the error. Can you
> write a quickstart?
>
> Have fun
> Sven
>
>
> On 23.04.20 11:59, Igor Khvostenkov wrote:
> Hi *,
>
> I faced with the problem. When Wicket-generated URL contains jsessionId,
> form submitted with GET request, and not POST. If I remove jsessionId from
> URL, then normal POST request is done. I have no idea where this GET is
> coming from. I ovverode getMethod() to always return POST and issue still
> exist. Any ideas where I can look to figure out why GET request is done?
>
> Generated HTML:
>
> 
>
>  wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm"
> method="post"
> action="./login.html;jsessionid=8B3813A1300187D10FE8211AF47D9F7F?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm"
> wicketsource="Login.java:39"> style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden"
> class="hidden-fields"> id="accessForm5_hf_0">  style="display:none"> Konferenz-Teilnehmer  class="form-group">   class="form-control" value="" name=“code"
> wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_code"
> placeholder=“Code" wicketsource="LoginForm.java:50">  class="input-group-btn">  wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_wicket__message__attr__6578556"
> value="Teilnehmen">
>
> 
> Request Headers:
>
>
>   1.
> :authority:
> xxx
>   2.
> :method:
> GET
>   3.
> :path:
>
> /conference/ng/login.html?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm
>

Is that a login form that you try to submit ?
Or it is another form and the server sees that you are not authenticated
and this is the reason to redirect you to login.html ?

Another explanation for the misterious GET could be that Wicket uses
RedirectAfterPost pattern to prevent double submits. See
https://en.wikipedia.org/wiki/Post/Redirect/Get for more details.

  4.
> :scheme:
> https
>   5.
> accept:
>
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
>   6.
> accept-encoding:
> gzip, deflate, br
>   7.
> accept-language:
> de
>   8.
> cookie:
> JSESSIONID=8B3813A1300187D10FE8211AF47D9F7F
>   9.
> referer:
> 

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-16 Thread Martin Grigorov
s at all (for Wicket 9 at least).
> > >>>>
> > >>>> The old page manager implementation had so many special concepts and
> > >>>> solutions, it's easy to miss one.
> > >>>>
> > >>>> A soft reference feature can easily be added/restored. I'm already
> > >>>> checking where it fits best.
> > >>>>
> > >>>> Thanks for your thorough testing.
> > >>>>
> > >>>> Best regards
> > >>>> Sven
> > >>>>
> > >>>>
> > >>>> On 11.04.20 10:58, Thomas Heigl wrote:
> > >>>>> Hi all,
> > >>>>>
> > >>>>> Bad news. My application was caught in a GC loop after running for
> 8
> > >>>> hours.
> > >>>>> The old generation was exhausted.
> > >>>>>
> > >>>>> I couldn't get a heap dump at that time but restarted the
> > application,
> > >>>> took
> > >>>>> a heap dump after about an hour, and reverted back to Wicket 8.
> > >>>>>
> > >>>>> The problem is this: The heap was full of objects referencing
> > >>>>> InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My
> > >> first
> > >>>>> thought was that there is something wrong with the implementation
> of
> > >> that
> > >>>>> store and pages do not get limited or removed correctly.  So I
> > debugged
> > >>>>> it locally but everything is working fine.
> > >>>>>
> > >>>>> Then I noticed that there are a lot of instances of Hibernate
> > entities
> > >> on
> > >>>>> the heap. So there definitely is an issue with models somewhere in
> my
> > >>>>> application. To be sure that this is not a new issue, I took
> another
> > >> heap
> > >>>>> dump from production - now running Wicket 8 again - and compared
> it.
> > >>>>> There are undetached entity models on the heap as well.
> > >>>>>
> > >>>>> So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
> > >>>>> (roughly the equivalent of InMemoryPageStore in Wicket 9) uses
> > >>>>> SoftReferences for storing pages. InMemoryPageStore does not and GC
> > >>>> cannot
> > >>>>> reclaim memory from it.
> > >>>>>
> > >>>>> So while this surfaced some issues in my application that I just
> > >> fixed, I
> > >>>>> believe that InMemoryPageStore should use SoftReferences or another
> > >>>>> implementation based on SoftReferences should be added to Wicket
> 9. A
> > >>>> cache
> > >>>>> should not consume all the memory if it can easily re-fetch
> > >>>>> the value from persistent storage.
> > >>>>>
> > >>>>> I guess the reason for not using SoftReferences in
> InMemoryPageStore
> > is
> > >>>>> that it can theoretically be used as a "persistent" store for
> pages.
> > If
> > >>>> that
> > >>>>> behavior is really required, I suggest adding another
> implementation
> > >>>> using
> > >>>>> SoftReferences.
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Thomas
> > >>>>>
> > >>>>> On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov <
> > mgrigo...@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl  >
> > >>>> wrote:
> > >>>>>>> FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k
> > >>>> requests
> > >>>>>>> served and no issues so far.
> > >>>>>>>
> > >>>>>> Awesome!
> > >>>>>> Thank you for testing it!
> > >>>>>>
> > >>>>>>
> > >>>>>>> Great work!
> > >>>>>>>
> > >>>>>>> Thomas
> > >>>>>>>
> > >>>>&

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-10 Thread Martin Grigorov
On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl  wrote:

> FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k requests
> served and no issues so far.
>

Awesome!
Thank you for testing it!


>
> Great work!
>
> Thomas
>
> On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:
>
> > Many thanks Maxim!
> >
> > Sven
> >
> > On 08.04.20 14:29, Maxim Solodovnik wrote:
> > > Released :)
> > >
> > > On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 
> > wrote:
> > >> OK
> > >>
> > >> Will start new release process in couple of hours
> > >> Please stop me if you will find any blocker :)
> > >>
> > >> On Wed, 8 Apr 2020 at 14:36, Thomas Heigl 
> wrote:
> > >>> Hi Maxim,
> > >>>
> > >>> It works for me now!
> > >>>
> > >>> Thomas
> > >>>
> > >>> On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik <
> solomax...@gmail.com>
> > >>> wrote:
> > >>>
> >  Thanks a million!
> > 
> >  On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 
> > wrote:
> > > Hi Maxim,
> > >
> > > I'm testing against the snapshot now. Will get back to you shortly.
> > >
> > > Thomas
> > >
> > > On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik <
> > solomax...@gmail.com>
> > > wrote:
> > >
> > >> Hello All,
> > >>
> > >> M5 seems to be broken (deploy has failed more than 10 times during
> > my
> > >> build attempts)
> > >> I have to start another release
> > >> Could you please tell when can I start?
> > >>
> > >> On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > >> wrote:
> > >>> Hello Thomas,
> > >>>
> > >>> Please test M6-SNAPSHOT (so I don't have to release M5.2 :
> > >>>
> > >>> On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 
> >  wrote:
> >  Hi Maxim,
> > 
> >  That would be great. I want to do some more extensive testing
> and
> >  then
> >  deploy M5 into production. ;)
> > 
> >  Thomas
> > 
> >  On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik <
> >  solomax...@gmail.com>
> >  wrote:
> > 
> > > I can pack another release
> > > later this week ...
> > >
> > > On Wed, 8 Apr 2020 at 00:48, Thomas Heigl  >
> > >> wrote:
> > >> Thanks Sven!
> > >>
> > >> Did your changes make it into the release? Or did they just
> >  miss
> > >> it?
> > >> Thomas
> > >>
> > >> On Tue, Apr 7, 2020 at 7:43 PM Sven Meier 
> >  wrote:
> > >>> Hi Thomas,
> > >>>
> > >>> yes, you're right:
> > >>>
> > >>> wicketstuff data stores missed some adjustments to the latest
> > >> updates
> > > in
> > >>> wicket-core.
> > >>>
> > >>> And SessionQuotaManagingDataStore$DelegatedPage must be
> > >> serializable of
> > >>> course.
> > >>>
> > >>> I've pushed changes to wicketstuff master.
> > >>>
> > >>> Thanks
> > >>> Sven
> > >>>
> > >>>
> > >>> On 07.04.20 14:14, Thomas Heigl wrote:
> >  And one more thing. There is now a warning logged just
> >  before
> > >>> serialization:
> >  WARN o.a.w.pageStore.AsynchronousPageStore: Delegated
> >  page
> > >> store
> > > 'org.apache.wicket.pageStore.SerializingPageStore' can
> >  not be
> > >>> asynchronous
> > 
> >  On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl <
> > >> tho...@umschalt.com>
> > > wrote:
> > > The cause is the following MetaData entry in the session:
> > >
> > > class
> > 
> >
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
> > > On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl <
> > >> tho...@umschalt.com>
> > >>> wrote:
> > >> Hi Sven,
> > >>
> > >> I just found time to give this a try with Wicket
> >  9.0.0-M5.
> > >> There
> > > seem
> > >>> to
> > >> be issues with serialization now.
> > >>
> > >> My new config:
> > >>
> > >> protected IPageStore newCachingStore(IPageStore
> >  pageStore) {
> > >>> return new CachingPageStore(pageStore, new
> > >>> InMemoryPageStore(getName(),
> > >>> MAX_PAGES_CACHED_PER_SESSION));
> > >>> }
> > >>> protected IPageStore newPersistentStore() {
> > >>> final RedissonRedisCache redisCache = new
> > >>> RedissonRedisCache(redissonClient);
> > >>> final RedisDataStore redisDataStore = new
> > > RedisDataStore(getName(),
> > >>> redisCache, new RedisSettings());
> > >>> return new 

Re: Quick Start Error with 8.7.0 - The desired archetype does not exist

2020-04-10 Thread Martin Grigorov
Hi,

It works fine for me:

 mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=8.7.0
-DgroupId=4MyTestCompany -DartifactId=testWicket8 -DarchetypeRepository=
https://repository.apache.org/ -DinteractiveMode=false
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom
>---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom
]-
[INFO]
[INFO] >>> maven-archetype-plugin:3.0.1:generate (default-cli) >
generate-sources @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:3.0.1:generate (default-cli) <
generate-sources @ standalone-pom <<<
[INFO]
[INFO]
[INFO] --- maven-archetype-plugin:3.0.1:generate (default-cli) @
standalone-pom ---
[INFO] Generating project in Batch mode
[INFO] Archetype repository not defined. Using the one from
[org.apache.wicket:wicket-archetype-quickstart:9.0.0-M4] found in catalog
remote
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-archetype-quickstart/8.7.0/wicket-archetype-quickstart-8.7.0.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-archetype-quickstart/8.7.0/wicket-archetype-quickstart-8.7.0.pom
(2.7 kB at 21 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-parent/8.7.0/wicket-parent-8.7.0.pom
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-parent/8.7.0/wicket-parent-8.7.0.pom
(42 kB at 629 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-archetype-quickstart/8.7.0/wicket-archetype-quickstart-8.7.0.jar
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/wicket/wicket-archetype-quickstart/8.7.0/wicket-archetype-quickstart-8.7.0.jar
(30 kB at 475 kB/s)
[INFO]

[INFO] Using following parameters for creating project from Archetype:
wicket-archetype-quickstart:8.7.0
[INFO]

[INFO] Parameter: groupId, Value: 4MyTestCompany
[INFO] Parameter: artifactId, Value: testWicket8
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: 4MyTestCompany
[INFO] Parameter: packageInPathFormat, Value: 4MyTestCompany
[INFO] Parameter: package, Value: 4MyTestCompany
[INFO] Parameter: groupId, Value: 4MyTestCompany
[INFO] Parameter: artifactId, Value: testWicket8
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Project created from Archetype in dir: /tmp/testWicket8
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time:  2.944 s
[INFO] Finished at: 2020-04-10T15:35:22+03:00
[INFO]


On Fri, Apr 10, 2020 at 3:28 PM Bruce Lombardi  wrote:

> Hi,
>
>
>
> I tried to use the Quick Start to get wicket 8.7.0 .
>
>
>
> The command line generated on the Wicked site is as follows (except I added
> the -X switch and ran it again after getting the error to get more
> information).
>
>
>
> mvn -X archetype:generate -DarchetypeGroupId=org.apache.wicket
> -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=8.7.0
> -DgroupId=4MyTestCompany -DartifactId=testWicket8
> -DarchetypeRepository=https://repository.apache.org/
> -DinteractiveMode=false
>
>
>
>
>
> The full trace is below, but the error seems to be:
>
>
>
> "The desired archetype does not exist
> (org.apache.wicket:wicket-archetype-quickstart:8.7.0)"
>
>
>
> Is this really missing or is there something wrong with my Maven set up?
>
>
>
> Bruce
>
>
>
>
>
> [DEBUG]   Included: org.codehaus.groovy:groovy:jar:1.8.3
>
> [DEBUG]   Included: antlr:antlr:jar:2.7.7
>
> [DEBUG]   Included: asm:asm:jar:3.2
>
> [DEBUG]   Included: asm:asm-commons:jar:3.2
>
> [DEBUG]   Included: asm:asm-util:jar:3.2
>
> [DEBUG]   Included: asm:asm-analysis:jar:3.2
>
> [DEBUG]   Included: asm:asm-tree:jar:3.2
>
> [DEBUG]   Included: org.beanshell:bsh:jar:2.0b4
>
> [DEBUG]   Included:
> org.apache.maven.shared:maven-script-interpreter:jar:1.0
>
> [DEBUG]   Included: org.apache.ant:ant:jar:1.8.1
>
> [DEBUG]   Excluded: org.apache.maven:maven-model:jar:2.0.8
>
> [DEBUG]   Excluded: org.apache.maven:maven-project:jar:2.0.8
>
> [DEBUG]   Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.8
>
> [DEBUG]   Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
>
> [DEBUG]   Excluded: junit:junit:jar:4.8.2
>
> [DEBUG]   Excluded: org.apache.maven:maven-plugin-api:jar:2.0.8
>
> [DEBUG]   Excluded: org.apache.maven:maven-core:jar:2.0.8
>
> [DEBUG]   Excluded: 

Re: About XML Injection

2020-04-09 Thread Martin Grigorov
I still do not understand what exactly is the issue here.

The client/browser submits the values as key/value pairs
(application/x-www-form-urlencoded).
The server responds with XML that is processed by wicket-ajax.js.
How validation of the submit values could help with the XML injection ?!


On Thu, Apr 9, 2020 at 2:52 PM Shengche Hsiao 
wrote:

> Thank you, I'll do that and see if works
>
> On Thu, Apr 9, 2020 at 6:35 PM Martin Terra <
> martin.te...@koodaripalvelut.com> wrote:
>
> > Can you solve this by simple validation if submitted values are legal?
> This
> > way it does not matter if client tries to override the submit.
> >
> > **
> > Martin
> >
> > to 9. huhtik. 2020 klo 12.22 Shengche Hsiao (shengchehs...@gmail.com)
> > kirjoitti:
> >
> > > I got a report , it suggest our web site to deal with xml injection
> > issue.
> > > We use DropDownChoice with OnChangeAjaxBehavior to invoke another
> > > DropDownChoice via wicket-ajax buit-in xml payload, and the reporters
> > > used Burpsuite
> > > to inject xml on xmlpayload, such as inject 
> > >
> > >
> > >  image.png
> > > <
> > >
> >
> https://drive.google.com/file/d/1U9nls1Z7tfs_zqEvbLLYsef89BFMopeY/view?usp=drive_web
> > > >
> > >
> > >
> > > and resulted in some abnormal response
> > >
> > >
> > >  image.png
> > > <
> > >
> >
> https://drive.google.com/file/d/1RcAegoREfmkdPNm1DCw9ouUyfI20lh7K/view?usp=drive_web
> > > >
> > >
> > >
> > > As a result, I have to prevent the xml injection, do I check the entire
> > > payload or only check there value we need ?
> > >
> > > On Thu, Apr 9, 2020 at 4:57 PM Martin Grigorov 
> > > wrote:
> > >
> > > > The images didn't make it to the mailing list.
> > > > Please use some online image paste bin.
> > > >
> > > > On Thu, Apr 9, 2020 at 11:33 AM Shengche Hsiao <
> > shengchehs...@gmail.com>
> > > > wrote:
> > > >
> > > > > I got a report , it suggest our web site to deal with xml injection
> > > > issue.
> > > > > We use DropDownChoice with OnChangeAjaxBehavior to invoke another
> > > > > DropDownChoice via wicket-ajax buit-in xml payload, and the
> reporters
> > > > used
> > > > >  Burpsuite to inject xml on xmlpayload, such as inject 
> > > > >
> > > > > [image: image.png]
> > > > >
> > > > > and resulted in some abnormal response
> > > > >
> > > > > [image: image.png]
> > > > >
> > > > > As a result, I have to prevent the xml injection, do I check the
> > entire
> > > > > payload or only check there value we need ?
> > > > >
> > > > > On Thu, Apr 9, 2020 at 4:11 PM Martin Grigorov <
> mgrigo...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > >> On Thu, Apr 9, 2020 at 11:09 AM Shengche Hsiao <
> > > shengchehs...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Yes, I need to know overriding which methods
> > > > >> >
> > > > >>
> > > > >> I still do not understand what exactly you need to accomplish.
> > > > >> Please be more specific!
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > On Thu, Apr 9, 2020 at 16:03 Martin Grigorov <
> > mgrigo...@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > On Thu, Apr 9, 2020 at 10:27 AM ShengChe Hsiao <
> > > front...@gmail.com>
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > > Dear all
> > > > >> > > >
> > > > >> > > > I use built-in ajax dropdownchoice component, it's default
> > > payload
> > > > >> is
> > > > >> > xml
> > > > >> > > > entity, but if I need to prevent xml injection ,how can i
> do?
> > > > >> > > >
> > > > >> > >
> > > > >> > &g

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

2020-04-09 Thread Martin Grigorov
It is not my day today! :-)
This is the second description of an issue here in users@ which I don't
understand.
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
> > >
> > >
> >
>
> -
> 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

2020-04-09 Thread Martin Grigorov
Hi,

Why do you need to use PageManager ?
By default WicketTester uses MockPageManager without a backing PageStore.

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
>
>


Re: About XML Injection

2020-04-09 Thread Martin Grigorov
The images didn't make it to the mailing list.
Please use some online image paste bin.

On Thu, Apr 9, 2020 at 11:33 AM Shengche Hsiao 
wrote:

> I got a report , it suggest our web site to deal with xml injection issue.
> We use DropDownChoice with OnChangeAjaxBehavior to invoke another
> DropDownChoice via wicket-ajax buit-in xml payload, and the reporters used
>  Burpsuite to inject xml on xmlpayload, such as inject 
>
> [image: image.png]
>
> and resulted in some abnormal response
>
> [image: image.png]
>
> As a result, I have to prevent the xml injection, do I check the entire
> payload or only check there value we need ?
>
> On Thu, Apr 9, 2020 at 4:11 PM Martin Grigorov 
> wrote:
>
>> On Thu, Apr 9, 2020 at 11:09 AM Shengche Hsiao 
>> wrote:
>>
>> > Yes, I need to know overriding which methods
>> >
>>
>> I still do not understand what exactly you need to accomplish.
>> Please be more specific!
>>
>>
>> >
>> > On Thu, Apr 9, 2020 at 16:03 Martin Grigorov 
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > On Thu, Apr 9, 2020 at 10:27 AM ShengChe Hsiao 
>> > wrote:
>> > >
>> > > > Dear all
>> > > >
>> > > > I use built-in ajax dropdownchoice component, it's default payload
>> is
>> > xml
>> > > > entity, but if I need to prevent xml injection ,how can i do?
>> > > >
>> > >
>> > > Could you please give some more information what exactly you need?
>> > >
>> > >
>> > > >
>> > > >
>> > > > 
>> > > > --->
>> > > > To boldly go where no man has gone before.
>> > > > 
>> > > > --->
>> > > > We do this not because it is easy. We do this because it is hard.
>> > > > -
>> > > > -->
>> > > > If I have seen further it is by standing on the shoulders of giants.
>> > > > --
>> > > > ->
>> > > > front...@gmail.com
>> > > >
>> > > >
>> > >
>> >
>> ->
>> > > >
>> > >
>> > --
>> >
>> > --->
>> > We do this not because it is easy. We do this because it is hard.
>> > --->
>> > ShengChe Hsiao
>> > --->
>> > front...@gmail.com
>> > front...@tc.edu.tw
>> > --->
>> > VoIP : 070-910-2450
>> > --->
>> >
>>
>
>
> --
>
> --->
> We do this not because it is easy. We do this because it is hard.
> --->
> ShengChe Hsiao
> --->
> front...@gmail.com
> front...@tc.edu.tw
> --->
> VoIP : 070-910-2450
> --->
>


Re: About XML Injection

2020-04-09 Thread Martin Grigorov
On Thu, Apr 9, 2020 at 11:09 AM Shengche Hsiao 
wrote:

> Yes, I need to know overriding which methods
>

I still do not understand what exactly you need to accomplish.
Please be more specific!


>
> On Thu, Apr 9, 2020 at 16:03 Martin Grigorov  wrote:
>
> > Hi,
> >
> > On Thu, Apr 9, 2020 at 10:27 AM ShengChe Hsiao 
> wrote:
> >
> > > Dear all
> > >
> > > I use built-in ajax dropdownchoice component, it's default payload is
> xml
> > > entity, but if I need to prevent xml injection ,how can i do?
> > >
> >
> > Could you please give some more information what exactly you need?
> >
> >
> > >
> > >
> > > 
> > > --->
> > > To boldly go where no man has gone before.
> > > 
> > > --->
> > > We do this not because it is easy. We do this because it is hard.
> > > -
> > > -->
> > > If I have seen further it is by standing on the shoulders of giants.
> > > --
> > > ->
> > > front...@gmail.com
> > >
> > >
> >
> ->
> > >
> >
> --
>
> --->
> We do this not because it is easy. We do this because it is hard.
> --->
> ShengChe Hsiao
> --->
> front...@gmail.com
> front...@tc.edu.tw
> --->
> VoIP : 070-910-2450
> --->
>


Re: About XML Injection

2020-04-09 Thread Martin Grigorov
Hi,

On Thu, Apr 9, 2020 at 10:27 AM ShengChe Hsiao  wrote:

> Dear all
>
> I use built-in ajax dropdownchoice component, it's default payload is xml
> entity, but if I need to prevent xml injection ,how can i do?
>

Could you please give some more information what exactly you need?


>
>
> 
> --->
> To boldly go where no man has gone before.
> 
> --->
> We do this not because it is easy. We do this because it is hard.
> -
> -->
> If I have seen further it is by standing on the shoulders of giants.
> --
> ->
> front...@gmail.com
>
> ->
>


Re: Kendo Material update from 8.3.0 to 8.6.0 adds 'user-select:none'

2020-04-03 Thread Martin Grigorov
Hi Manfred,

On Thu, Apr 2, 2020 at 6:23 PM Bergmann Manfred 
wrote:

> Hi.
>
> We’ve just realized that none of the texts when changing this library
> version are selectable/copyable.
> Is this intentional?
>

It sounds like the change is in Kendo Material sources, not in Wicket
JQuery UI, so the question should be addressed to Kendo Material developers.


> How can it be fixed other than reverting to 8.3.0?
>

You can always overwrite any CSS rules by adding your own CSS rules *after*
the ones you want to overwrite.
E.g.:
https://kendo.ui/.../material.css"/>
https://my.server.com/my-overwrites.css"/>

Martin


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


Re: MetaData for websocket connections

2020-03-26 Thread Martin Grigorov
On Thu, Mar 26, 2020 at 10:59 AM Thomas Heigl  wrote:

> Hi Martin,
>
> It is not really necessary as you pointed out, but an external registry
> forces me to override the default IWebSocketConnectionRegistry so I can
> update the external registry when connections are
> added and removed.
>

I guess you don't want to use WebSocketBehavior's onConnect() and
onClose/onError() callbacks due to the "avoid loading the page if not
necessary" problem.


>
> If connections themselves would support metadata, there would be no need
> for an external registry plus the required glue code for keeping the
> registry up to date.
>
> But if you prefer not to add functionality I can go ahead and implement an
> external solution and see how it goes.
>

Anyone else having an opinion on this?


>
> Best regards,
>
> Thomas
>
> On Wed, Mar 25, 2020 at 7:19 PM Martin Grigorov 
> wrote:
>
> > Hi Thomas,
> >
> > Is this really necessary?
> > You can achieve the same today by using an external registry.
> > E.g. List channels = channelRegistry.get(webSocketConnection);
> > internally the registry can use WebSocketConnection's
> > getApplication().getName(), getSessionId() and getKey() to construct the
> > key.
> >
> > MetaData would do the job as well, but I'd prefer to not add more
> > functionality unless really needed.
> >
> > Regards,
> > Martin
> >
> > On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl 
> wrote:
> >
> > > Hi all,
> > >
> > > I'd like to add metadata to websocket connections. For instance, which
> > > events or channels a connection is subscribed to.
> > >
> > > What do you think about adding MetaDataEntry[] metaData to
> connections
> > > and setMetaData/getMetaData to IWebSocketConnection?
> > >
> > > Best regards,
> > >
> > > Thomas
> > >
> >
>


Re: MetaData for websocket connections

2020-03-25 Thread Martin Grigorov
Hi Thomas,

Is this really necessary?
You can achieve the same today by using an external registry.
E.g. List channels = channelRegistry.get(webSocketConnection);
internally the registry can use WebSocketConnection's
getApplication().getName(), getSessionId() and getKey() to construct the
key.

MetaData would do the job as well, but I'd prefer to not add more
functionality unless really needed.

Regards,
Martin

On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl  wrote:

> Hi all,
>
> I'd like to add metadata to websocket connections. For instance, which
> events or channels a connection is subscribed to.
>
> What do you think about adding MetaDataEntry[] metaData to connections
> and setMetaData/getMetaData to IWebSocketConnection?
>
> Best regards,
>
> Thomas
>


Re: jquery-weekdays

2020-03-19 Thread Martin Grigorov
Hi,

I am not aware of an integration of Wicket with
https://github.com/nikolasmagno/jquery-weekdays.
You can use Wicket Bootstrap code for inspiration how to integrate it. For
example
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/wicket-8.x-bootstrap-4.x/bootstrap-extensions/src/main/java/de/agilecoders/wicket/extensions/markup/html/bootstrap/tour

On Thu, Mar 19, 2020 at 9:10 AM Arunachalam Sibisakkaravarthi <
arunacha...@mcruncher.com> wrote:

> Hi guys,
> I am trying to use jquey-weekdays to select multiple days.
> How do integrate with Wicket?
> Is there any Wicket component for this?
> Is there any other solution to achieve this
>
>
>
> *Thanks And RegardsSibi.ArunachalammCruncher*
>


Re: PerSessionPageStore thread-safety

2020-02-28 Thread Martin Grigorov
; discuss such change.
>
>
> To summarize:
>
> I'm using Spring Session that is a simple, container-neutral, transparent
> solution for clustering sessions. Wicket
> works fine with Spring Session. Except for one minor issue:
> PageAccessSynchronizer does not work because
> sessions are not held in memory but (de)serialized on every request. Thus
> the internal lock map is not shared
> between requests. Moving the lock map into global or application scope
> solves the issue with the downside of
> increased concurrency to the, now shared, map but should not require any
> additional locking or synchronization.
> It is quite trivial to write such a global synchronizer, but it could be
> much easier if some additional methods
> in the default access manager were public and lock handling would be
> encapsulated in an interface.
>
> I hope I managed to explain myself. The topic is quite complex ;)
>

Thank you for this comprehensive explanation, Thomas! :-)
Please create a Pull Request with your suggested changes!

Martin


>
> Best,
>
> Thomas
>
>
>
> On Thu, Feb 27, 2020 at 1:47 PM Martin Grigorov 
> wrote:
>
> > Hi Thomas,
> >
> > Could you please explain how exactly Spring Session works ? This will
> help
> > us both understand where the problem comes from.
> > Also how exactly do you integrate it with Wicket ? Which extension points
> > do you use ?
> >
> > Since it is backed by Redis it means that it is distributed.
> > But at the same time you try to use PerSessionPageStore which is
> in-memory
> > store, i.e. it lives only in the memory of one of the web container
> nodes.
> > Another node has its own instance of this class.
> >
> > Here is how it works in normal Servler environment:
> >
> > The HttpSession instances are managed by the web container, e.g. Tomcat.
> > The container keeps them in memory! The container may persist them for
> > failover/restart but usually the HttpSessions are kept in memory.
> >
> > 1) if there is just one web container node then Wicket asks the container
> > for the javax.servler.HttpSession: httpServletRequest.getSession()
> > Then Wicket extracts the org.apache.wicket.Session from the HttpSession
> > attributes.
> > The Wicket Session class has a member instance of PageAccessSynchronizer
> > that is specific for the current instance of the Session.
> > PageAccessSynchronizer has a Map, i.e. pageId ->
> > PageLock.
> > Whenever a request needs to use a specific Wicket Page then the current
> > session's PageAccessSynchronizer is used to acquire a lock on it. This
> > makes sure that a specific page instance is used by at most one request
> in
> > the *current* server node.
> >
> > 2) if there is session replication in place, i.e. more than one server
> > nodes, then:
> > The web container fetches the HttpSessions for its backend. In case of
> > Tomcat - it keeps the HttpSessions in memory but there is a
> ClusterManager
> > that replicates the HttpSessions' which have been modified, i.e. their
> > #setAttibute() has been called.
> > In cluster mode there will be one HttpSession per server node,
> respectfully
> > one Wicket Session instance per node, and one PageAccessSynchronizer per
> > session per node.
> > Using Wicket or not if you don't use sticky sessions you may face timing
> > related issues in such environment. Every distributed software has this
> > problem.
> >
> >
> > On Wed, Feb 26, 2020 at 9:17 PM Thomas Heigl 
> wrote:
> >
> > > Hi Sven,
> > >
> > > Thanks for the link but I'm not using asynchronous serialization.
> > >
> > > I thought some more about the issue and I think I figured it out. My
> > setup
> > > looks like this:
> > >
> > > 1. Spring Session Redis
> > > 2. [Session Cache] (Not used because it is transient and stored with
> > > writeObject/readObject and does not get serialized into Redis as we do
> > not
> > > use Java serialization)
> > > 3. PerSessionPageStore (Application-level cache held in memory)
> > > 4. RedisDataStore (Synchronous)
> > >
> > > Observations:
> > >
> > > 1. If i disable second-level cache or use the serializing second-level
> > > cache provided by the DefaultPageManager, there are no issues
> > > 2. As soon as I enable the PerSessionPageStore we run into concurrency
> > > issues
> > >
> > > Analysis:
> > >
> > > I first thought that there were some thread-safety issues
> > > with PerSessionP

Re: PerSessionPageStore thread-safety

2020-02-27 Thread Martin Grigorov
Hi Thomas,

Could you please explain how exactly Spring Session works ? This will help
us both understand where the problem comes from.
Also how exactly do you integrate it with Wicket ? Which extension points
do you use ?

Since it is backed by Redis it means that it is distributed.
But at the same time you try to use PerSessionPageStore which is in-memory
store, i.e. it lives only in the memory of one of the web container nodes.
Another node has its own instance of this class.

Here is how it works in normal Servler environment:

The HttpSession instances are managed by the web container, e.g. Tomcat.
The container keeps them in memory! The container may persist them for
failover/restart but usually the HttpSessions are kept in memory.

1) if there is just one web container node then Wicket asks the container
for the javax.servler.HttpSession: httpServletRequest.getSession()
Then Wicket extracts the org.apache.wicket.Session from the HttpSession
attributes.
The Wicket Session class has a member instance of PageAccessSynchronizer
that is specific for the current instance of the Session.
PageAccessSynchronizer has a Map, i.e. pageId ->
PageLock.
Whenever a request needs to use a specific Wicket Page then the current
session's PageAccessSynchronizer is used to acquire a lock on it. This
makes sure that a specific page instance is used by at most one request in
the *current* server node.

2) if there is session replication in place, i.e. more than one server
nodes, then:
The web container fetches the HttpSessions for its backend. In case of
Tomcat - it keeps the HttpSessions in memory but there is a ClusterManager
that replicates the HttpSessions' which have been modified, i.e. their
#setAttibute() has been called.
In cluster mode there will be one HttpSession per server node, respectfully
one Wicket Session instance per node, and one PageAccessSynchronizer per
session per node.
Using Wicket or not if you don't use sticky sessions you may face timing
related issues in such environment. Every distributed software has this
problem.


On Wed, Feb 26, 2020 at 9:17 PM Thomas Heigl  wrote:

> Hi Sven,
>
> Thanks for the link but I'm not using asynchronous serialization.
>
> I thought some more about the issue and I think I figured it out. My setup
> looks like this:
>
> 1. Spring Session Redis
> 2. [Session Cache] (Not used because it is transient and stored with
> writeObject/readObject and does not get serialized into Redis as we do not
> use Java serialization)
> 3. PerSessionPageStore (Application-level cache held in memory)
> 4. RedisDataStore (Synchronous)
>
> Observations:
>
> 1. If i disable second-level cache or use the serializing second-level
> cache provided by the DefaultPageManager, there are no issues
> 2. As soon as I enable the PerSessionPageStore we run into concurrency
> issues
>
> Analysis:
>
> I first thought that there were some thread-safety issues
> with PerSessionPageStore but that is not the case because even a fully
> synchronized version shows these problems.
>
> The reason why disabling the 2nd-level cache or using a serializing variant
> works, is because they do not operate on the same *instance* of the page.
> Each thread gets their
> own instance because the page is deserialized before being accessed.
>
> PerSessionPageStore stores the page in memory without serializing it, thus
> all threads share the same instance. This is also the case when using the
> session cache or
> the session-based stores, but the PageAccessSynchronizer bound to the
> session takes care of ensuring that only single request can manipulate the
> page at any given time.
>
> So how does the synchronizer work? It keeps a Map in the
> session and checks whether the page is locked on every request. In a
> non-replicated
> environment this works as expected as the session object lives in the
> servlet container and is the same for each concurrent request. In my case,
> the session
> is not provided by the servlet container, but fetched from Redis by Spring
> Session on every request. So each concurrent thread has *their own version*
> of the session and
> the locks are *not shared between threads* because the session is only
> saved back to Redis after the request has finished.
>
> So the problematic flow looks like this
>
> 1. A request comes in, we fetch the session from Redis, the request
> acquires the session-scoped lock and starts processing
> 2. Before the request is finished, another request comes in, fetches the
> session from Redis, the lock map is empty because the state of request #1
> has not been persisted to Redis
> 3. Now both requests can modify the page and we run into concurrency issues
>
> Summary:
>
> PageAccessSynchronizer does not work with Spring Session or other solutions
> that replace the servlet container session.
>
> Possible solutions:
>
> 1. We could ensure that session locks are updated in Redis immediately but
> that still leaves a couple of milliseconds for race conditions and 

Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility

2020-01-22 Thread Martin Grigorov
On Wed, Jan 22, 2020 at 8:55 AM Sven Meier  wrote:

> Ah, our old friends 'enclosures'!
>
> Problem is that a component inside an enclosure  is really inside it only
> during rendering of its markup.
> But the strategy walking through the component hierarchy to render all
> headers doesn't know anything about that enclosure o_O
>
> As it has been written many times on this list, enclosures are best
> avoided in anything than the simplest setup.
>

The recommended solution is to use EnclosureContainer instead of
.


>
> Have fun
> Sven
>
> Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde <
> rob.audenae...@gmail.com>:
> >Hi Sven,
> >
> >Thanks for double-checking!
> >
> >The weird thing is that I thought this solved my problem, but when I
> >tried
> >to create the quickstart; I couldn't reproduce it either :o. I seem to
> >have
> >been mistakenly assuming it was this piece of code that fixed the
> >problem.
> >
> >So I tried to build it more towards our application and I saw a
> > that causes this behavior (the
> >isVisibleInHierarchy() is
> >not working there).
> >
> >I attached the quickstart for those who want to experiment with it.
> >
> >-Rob
> >
> >On Mon, Jan 20, 2020 at 7:17 PM Sven Meier  wrote:
> >
> >> Hi Rob,
> >>
> >> actually I wasn't able to reproduce the problem on a second try (not
> >> sure what I tested before).
> >>
> >> Can you create a a quickstart showing the problem?
> >>
> >> Sven
> >>
> >> On 20.01.20 13:18, Sven Meier wrote:
> >> > Hi Rob,
> >> >
> >> >> the 'correct' way to solve this?
> >> >
> >> > the component is explicitly added to the Ajax request for an
> >update,
> >> > but decides to hide itself in onConfigure().
> >> > Perfectly valid usecase IMHO, but the head will be rendered
> >> > nevertheless :/
> >> >
> >> > Just tested with 7.x, 8.x and master, this seems to have been that
> >way
> >> > forever.
> >> > But maybe we can improve that in Wicket core?
> >> >
> >> > Sven
> >> >
> >> >
> >> > On 20.01.20 10:36, Rob Audenaerde wrote:
> >> >> Hi all,
> >> >>
> >> >> I recently got some javascript errors that came from behaviors of
> >> >> components that where triggered to be visible or invisible in the
> >dom
> >> >> (using onConfigure()) in an ajax request.
> >> >>
> >> >> Typically something like:
> >> >>
> >> >> Wicket.Ajax:  Cannot bind a listener for event "change" on element
> >> >> "format1dd" because the element is not in the DOM
> >> >>
> >> >> I solve this by adding an isVisibleInHierarchy() check in the
> >> >> renderHead()
> >> >> like this:
> >> >>
> >> >> @Override
> >> >>
> >> >> public void renderHead(final Component component, final
> >IHeaderResponse
> >> >> response) {
> >> >>  if (component.isVisibleInHierarchy()) {
> >> >>  super.renderHead(component, response);
> >> >>  }
> >> >> }
> >> >>
> >> >> I was wondering if this is the 'correct' way to solve this? Or am
> >I
> >> >> doing
> >> >> something wrong?
> >> >>
> >> >> Please advise :)
> >> >>
> >> >> -Rob
> >> >>
> >> >
> >> >
> >-
> >> > 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: Need an event later than 'done'

2020-01-22 Thread Martin Grigorov
On Tue, Jan 21, 2020 at 11:59 PM Entropy  wrote:

> That seems promising.  If you could look how you did it in your other
> project
> that would be great.  I suppose if I could get access to the response XML I
> could look for the redirect in that.  I'm not sure where it is though or
> even if it's provided to this event.
>

You can use the Ajax (jQuery) response and check whether it has "Location"
header


>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: An open source devops platform completely created with Wicket

2020-01-17 Thread Martin Grigorov
Thank you for sharing it with us, Robin!

It looks awesome!

On Fri, Jan 17, 2020 at 2:26 AM Robin Shen  wrote:

> Dear wicket users,
>
> I'd like to introduce OneDev, an open source all-in-one devops platform:
> https://github.com/theonedev/onedev
>
> It is created completely with Wicket with only one person. I know that
> there are modern and fashion techniques such as React/Vue, but I still feel
> that Wicket is the most suitable framework for this product, considering
> that I can work with the same set of code from front-end to back-end, with
> Java's mature libraries and toolings. I must say I gain great productivity
> with Wicket.
>
> Hope this product is useful to someone.
>
> Robin
>


Re: Test errors after upgrading to Wicket 8.7.0

2020-01-10 Thread Martin Grigorov
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
>
>


Re: Test errors after upgrading to Wicket 8.7.0

2020-01-10 Thread Martin Grigorov
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


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
>
>


Re: Best way to refresh entire NestedTree

2019-12-29 Thread Martin Grigorov
Hi Chris,

On Sun, Dec 29, 2019 at 11:22 AM Chris Colman 
wrote:

> Sorry for the duplication. These messages did not appear in the mail
> group until about 8 hours after they were posted. I thought I must have
>

This is because you are not subscribed to the mailing list and your
messages are moderated.


> 'misdirected' the first one. Was there a problem with the mail group today?
>
> Anyway - I eventually worked out how to do it!
>
> The secret was in the source code of the TreeModelProvider class - which
> we don't use but it has a method called
>
> update(AbstractTree tree, AjaxRequestTarget target)
>
> which did this magic (among other things):
>
> ...
> if (completeUpdate)
> target.add(new Componen[]{tree});
> ...
> this,detach();
>
>
> So I added a similar method, called completeUpdate, to pagebloom's own
> ITreeProvider implementation, TreeNodeProvider and it all worked
> amazingly well, after adding some additional detachment of the root nodes.
>
>
>
>
> On 29/12/2019 2:09 pm, chrisco wrote:
> > I have a UI layout where selection changes in one component need to
> result in
> > a complete repopulation of the nodes in an associated NestedTree.
> >
> > Obviously I don't want to do a complete page refresh so I was wondering
> what
> > the best way is to do an AJAX refresh of the entire NestedTree after I've
> > told it, somehow, that all of its nodes need to be replaced.
> >
> > Is it as simple as just replacing the ITreeProvider and then adding the
> > NestedTree to the AJAX request target or is there something more
> involved?
> >
> > Merry Christmas/Holiday everyone,
> >
> > Regards,
> >
> > Chris
> >
> > --
> > Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>


Re: Is there an example project for wicket-spring-boot with gradle and webpack?

2019-12-08 Thread Martin Grigorov
Hi,

I would suggest you to generate your application with JHipster and then
remove the front-end (Angular/React) and add Wicket instead.

On Sun, Dec 8, 2019, 10:02 Per Newgro  wrote:

> Hello *,
>
> i try to setup a spring boot project based on wicket-spring-boot-parent.
> To built my frontend assets (sass, js, svg minify etc) i like to use
> webpack.
>
> But if i start my project the assets are not loaded. So i hope to find an
> example project,
> where i can find some inspirations how i could setup everything.
>
> Btw. i built everything with gradle.
>
> Thanks for your support
> Per
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Partial update of DataGridView when adding new items

2019-12-04 Thread Martin Grigorov
Hi Chris,

Please read
https://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/
The article explains how to do this with ListView but the idea is the same
for all other repeaters.

On Wed, Dec 4, 2019 at 6:53 AM Chris Colman  wrote:

> We're using a DataGridView and we're happily doing partial updates of
> existing items for select/deselect and when content changes.
>
> Updating existing items is fine because we can work out the changed Item
> (Component) and just add it to the AJAX request target.
>
> However, we're wondering if it's possible to do partial updates of newly
> added items? Currently for that we're adding the whole DataGridView to
> the AJAX target but it causes a refresh which resets the current scroll
> position so it's a bit annoying to the user.
>
> The trouble is we add new model items to the underlying collection that
> the IDataProvider exposes but not sure how we work out which Item is
> added for that and then how to tell it to update just that item in the UI.
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: FileUpload class still implements IClusterable

2019-12-03 Thread Martin Grigorov
On Tue, Dec 3, 2019 at 3:42 PM Ernesto Reinaldo Barreiro 
wrote:

> Hi Martin,
>
>
> On Tue, Dec 3, 2019 at 3:09 PM Martin Grigorov 
> wrote:
>
> > Hi Ernesto,
> >
> > Yes, I think FileUpload should not be Serializable.
> > FileUploadField uses transient reference to the list of file uploads for
> > this reason:
> >
> >
> https://github.com/apache/wicket/blob/ad6ecac7fdebefc25d310361f3a92aa481c36b1f/wicket-core/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java#L50
>
>
> Yes I'm aware of this behaviour: I just fixed some related issue in our
> project and while doing that I noticed mentioned problem? Shall I create an
> issue for this or just a PR?
>

Issue + commit (you have the permissions).
But maybe only in Wicket 9.x because otherwise Clirr plugin will complain
that it is an API break.


>
> --
> Regards - Ernesto Reinaldo Barreiro
>


Re: FileUpload class still implements IClusterable

2019-12-03 Thread Martin Grigorov
Hi Ernesto,

Yes, I think FileUpload should not be Serializable.
FileUploadField uses transient reference to the list of file uploads for
this reason:
https://github.com/apache/wicket/blob/ad6ecac7fdebefc25d310361f3a92aa481c36b1f/wicket-core/src/main/java/org/apache/wicket/markup/html/form/upload/FileUploadField.java#L50


On Tue, Dec 3, 2019 at 10:56 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> FileUpload still implements IClusterable but it contains a field of type
> FileItem: which is no longer Serializable. Should IClusterable be dropped?
>
> --
> Regards - Ernesto Reinaldo Barreiro
>


Re: Application # newSession # sessionUnbound - RuntimeException

2019-11-21 Thread Martin Grigorov
On Thu, Nov 21, 2019 at 6:30 PM Sven Meier  wrote:

> Hi,
>
> actually #sessionUnbound() is called *on* the application instance, so
> the ExceptionMapper is available.
>

oh, right. silly me!



> But ExceptionMapper maps an exception to a requestHandler, this doesn't
> make sense for an exception happening on a worker thread.
>

you meant on *non*-worker thread ?

Francois, please give us the stack trace.


> Hope this helps
> Sven
>
>
> On 21.11.19 16:37, Martin Grigorov wrote:
> > Hi Francois,
> >
> > #sessionUnbound() is called in two contexts:
> > 1) the user clicked the Logout button - in this case the call is executed
> > in http worker thread where there is a ThreadContext, i.e.
> > Application.get(), Session.get() and RequestCycle.get() would work
> > here, I think, Wicket should use the ExceptionMapper
> > 2) when the user session has timed out - in this case the web container
> > (Tomcat/Jetty) will execute this method in non-worker thread and
> > Application.get() would be null, so we cannot get a reference to the
> > ExceptionMapper
> >
> > On Thu, Nov 21, 2019 at 5:01 PM Francois Meillet <
> francois.meil...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Any RuntimeException thrown in Application # newSession(Request request,
> >> Response response) is handled by the DefaultExceptionMapper #
> >> mapUnexpectedExceptions(Exception e, final Application application)
> >>
> >> but
> >>
> >> Any RuntimeException thrown in Application # sessionUnbound(String
> >> sessionid) is not handled
> >>
> >> Is that normal ?
> >>
> >> François
> >>
> >>
> >>
> >>
> >> -
> >> 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: Application # newSession # sessionUnbound - RuntimeException

2019-11-21 Thread Martin Grigorov
Hi Francois,

#sessionUnbound() is called in two contexts:
1) the user clicked the Logout button - in this case the call is executed
in http worker thread where there is a ThreadContext, i.e.
Application.get(), Session.get() and RequestCycle.get() would work
here, I think, Wicket should use the ExceptionMapper
2) when the user session has timed out - in this case the web container
(Tomcat/Jetty) will execute this method in non-worker thread and
Application.get() would be null, so we cannot get a reference to the
ExceptionMapper

On Thu, Nov 21, 2019 at 5:01 PM Francois Meillet 
wrote:

> Hi,
>
> Any RuntimeException thrown in Application # newSession(Request request,
> Response response) is handled by the DefaultExceptionMapper #
> mapUnexpectedExceptions(Exception e, final Application application)
>
> but
>
> Any RuntimeException thrown in Application # sessionUnbound(String
> sessionid) is not handled
>
> Is that normal ?
>
> François
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Wicket blog

2019-11-10 Thread Martin Grigorov
Done!

https://wicket.apache.org/learn/blogs.html#get-your-blog-listed
https://github.com/apache/wicket-site/commit/6a07ad54303361f583f8182e2516b96bc07f627c

Thank you, Roman!

On Sat, Nov 9, 2019 at 7:03 PM Roman Sery  wrote:

> Hello,
> I have been working with Wicket for many years now and really love it, and
> I've started a blog focusing on Wicket.
> I'm hoping it could be included in this list of blogs:
> https://wicket.apache.org/learn/blogs.html#get-your-blog-listed
>
> Thanks!
> My blog is
> https://www.coderdreams.com/
>


Re: Log feedback messages

2019-10-29 Thread Martin Grigorov
Hi,

On Mon, Oct 28, 2019 at 7:33 PM Entropy  wrote:

> As part of a larger effort to improve our audit logs, I have been requested
> to add the feedback messages that appear as part of validation to those
> audits.  So in the onError() of a button or form, where the validation has
> failed, I need to gather (non-destructively) the feedback messages that
> will
> soon be displayed.
>
> How can I get this list?  getPage().getFeedbackMessages() returns empty
> because, I presume, the errors are on lower level controls.  Is there an
> API
> that gathers the messages for me?
>

Yes, see FeedbackCollector class.


>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Client browser timezone offset

2019-10-28 Thread Martin Grigorov
Hi,

I didn't get what is the problem with the current code.
For me http://examples8x.wicket.apache.org/ajaxhellobrowser/ shows
utcDSTOffset=3
utcOffset=2
which seems to be correct.

On Mon, Oct 28, 2019 at 5:56 PM Maxim Solodovnik 
wrote:

> On the other hand: the old code can be used if TZ is not available
> I'll do some tests and will create PR
>
> On Mon, 28 Oct 2019 at 22:51, Maxim Solodovnik 
> wrote:
>
> > @devs are we supporting IE11 for wicket9? if not we can add this call to
> > standard ClientProperties ...
> > WDYT?
> >
> > On Mon, 28 Oct 2019 at 22:48, Maxim Solodovnik 
> > wrote:
> >
> >> Hello,
> >>
> >> according to stackoverflow [1]
> >> you can use Intl.DateTimeFormat().resolvedOptions().timeZone
> >> ClientProperties can be extended to get this info on server
> >>
> >> [1]
> >>
> https://stackoverflow.com/questions/6939685/get-client-time-zone-from-browser
> >>
> >> On Mon, 28 Oct 2019 at 22:26, Calin Pavel  wrote:
> >>
> >>> I'm trying to detect what is the current timezone offset for a client
> >>> browser accessing my Wicket application.
> >>> I found out that BrowserInfoForm.ClientPropertiesBean contains details
> >>> about:
> >>> - utcOffset
> >>> - utcDstOffset
> >>> but these are calculated at 1.Jan and 1.June.
> >>>
> >>> Is there any way to determine on server side what is the CURRENT
> timezone
> >>> offset of the client?
> >>> I've tried to use ClientPropertiesBean.timeZone, but that is relative /
> >>> guest and not real client timezone.
> >>>
> >>>
> >>> --
> >>>
> >>> Kind Regards,
> >>>
> >>>
> >>> *CALIN PAVELSoftware Engineer - consultant*
> >>> calin.pa...@tvh.com
> >>>
> >>> *TVH PARTS HOLDING NV*
> >>> Vichtseweg 129 • BE-8790 WAREGEM
> >>> T +32 56 43 42 11 <+3256434211> • F +32 56 43 44 88 • www.tvh.com
> >>>
> >>> 
> >>>
> >>> --
> >>>
> >>>
> >>>  DISCLAIMER
> >>>  
> >>>
> >>> This
> >>> message is delivered to all addressees subject to the conditions set
> >>> forth
> >>> in the attached disclaimer, which is an integral part of this message.
> >>>
> >>>
> >>> When you communicate with us via e-mail, telephone, fax or via our
> >>> website,
> >>> we process your personal data. For more information on how we process
> >>> your
> >>> personal data, please consult our Privacy Policy
> >>> . By communicating with us, you
> >>> unambiguously consent to our use of your personal data as explained in
> >>> the
> >>> Privacy Policy.
> >>>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
> --
> WBR
> Maxim aka solomax
>


Re: Is there a way to control Wicket's id generation?

2019-10-27 Thread Martin Grigorov
On Fri, Oct 25, 2019 at 6:06 PM Entropy  wrote:

> I work on a government project and one of our rules is that all of our apps
> scrape the request object and log it so that everything that happens can be
> reviewed.  Partly this is for audit reasons, sometimes it comes in handy
> for
> lawsuits, but mostly it's handy for our L2 support team.
>
> But when a dev fails to provide an explicit name for something, we get
> things in the log like 'radio54' and the like.  Which is understandable as
> the dev failed to provide a name (bad dev! *swats dev with newspaper*).
>
> A recent lawsuit revealed yet another place where the unhelpful 'radio38'
> is
>

You, americans, are crazy with those law suits for everything and nothing!


> logged.  Our PM asked if we can help our devs out because this mistake is
> happening too often.  Can we disable wicket's natural tendency to generate
> these names and force an exception instead?  Thus, the mistake would be
> caught early.
>
> Wicket often exposes 'strategy' objects or other overrides to do this sort
> of thing, so I'm wondering if such a facility exists?  Even if it weren't
> an
> exception, but were some other kind of thing that drew the dev's attention
> it would be useful.
>

Like org.apache.wicket.IMarkupIdGenerator ?
See
org.apache.wicket.Component#getMarkupId(boolean)
and getApplication().getMarkupSettings().getMarkupIdGenerator()


>
> We're in Wicket 6.
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: 404 : https://wicket.apache.org/learn/#javadoc JavaDoc 9.x

2019-10-07 Thread Martin Grigorov
Fixed!

On Mon, Oct 7, 2019, 12:11 Martin Grigorov  wrote:

> Hi Francois,
>
> This is a known issue.
>
> https://markmail.org/message/6owzkxowbsf33jcy
> https://markmail.org/message/ac65iqbmwjdlugz3
>
> I will try to find a working solution for it this week.
>
> Martin
>
>
> On Mon, Oct 7, 2019 at 11:17 AM Francois Meillet <
> francois.meil...@gmail.com> wrote:
>
>> Hi,
>>
>> There is a 404 for
>> https://ci.apache.org/projects/wicket/apidocs/9.x/index.html <
>> https://ci.apache.org/projects/wicket/apidocs/9.x/index.html>
>>
>>
>> François
>>
>>
>>
>>


Re: Wicket Cookie Deletion

2019-10-07 Thread Martin Grigorov
On Mon, Oct 7, 2019 at 12:32 PM Sibgha Nazir  wrote:

> >
> > You don't use *expires *here.
>
>
> Yes it is irrelevant. Please ignore it.
>
>
> This should work.
> > Check what are the response headers in Chrome's Dev Tools > Network. The
> > new max-age value must be set to 0.
>
>
> I went to chrome dev tool -> network. But i cannot see whats max-age and
> where to look for it.
>

You may need to research how Cookies actually work.
Cookies are just data in the HTTP request/response headers.

If there is no Set-Cookie response header then most probably the Wicket
WebResponse you have used when calling #clearCookie() is not the one that
has been used to deliver the HTML response. Most probably your application
has replaced the response object with another one without preserving the
already set headers.


>
>
> On Mon, Oct 7, 2019 at 9:15 AM Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > On Mon, Oct 7, 2019 at 3:14 AM Sibgha Nazir  wrote:
> >
> > > Hi,
> > >
> > > I set a cookie from JavaScript in the chrome browser like
> > >
> > > > var d = new Date();
> > > > d.setTime(d.getTime() + (exdays * 24 * 60 * 60 * 1000));
> > > > var expires = "expires=" + d.toUTCString();
> > > > document.cookie = "test=true;1;path=/";
> > >
> >
> > You don't use *expires *here.
> >
> >
> > >
> > >
> > > So the cookie value in the chrome is "true" (cookie "test"="true")
> > >
> > > then I am trying to clear the cookie in the wicket like
> > >
> > >   WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest();
> > >
> > > WebResponse webResponse = (WebResponse)
> RequestCycle.get().getResponse();
> > >
> > > Cookie cookietest = webRequest.getCookie("test");
> > > > webResponse.clearCookie(cookietest);
> > >
> >
> > This should work.
> > Check what are the response headers in Chrome's Dev Tools > Network. The
> > new max-age value must be set to 0.
> >
> >
> > >
> > >
> > > The cookie is not deleted. I run the wicket web app on tomcat server.
> > Does
> > > anyone know what could be wrong?
> > >
> > >
> > > Just to be clear the cookie we set with JavaScript and the cookie we
> > > retrieve in wicket is pointing to the same space? I am confused why it
> > > wouldn't work. Does it have to anything with the Tomcat server?
> > >
> > > Best Regards,
> > > Sibgha Nazir
> > >
> >
>


Re: Is there a SOAP resource?

2019-10-07 Thread Martin Grigorov
Hi,

I am not aware of such resource. That does not mean that there is no such
out there though!

But SOAP is just XML, i.e. text, so you can read and parse it and do
whatever is needed.

Martin

On Mon, Oct 7, 2019 at 1:22 PM Per Newgro  wrote:

> Hello every1,
>
> i would like to migrate some features of an web app to my wicket app.
>
> The web app is a spring boot app that provides access to data using SOAP.
> The web service extracts the SOAP request and calls my wicket app by using
> rest resource.
>
> But now i need to replace the additional web app by my wicket app.
>
> So far i do everything using rest resource. So i ask myself if there is a
> similiar component for SOAP.
>
> Thanks for your support
> Regards
> Per
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: 404 : https://wicket.apache.org/learn/#javadoc JavaDoc 9.x

2019-10-07 Thread Martin Grigorov
Hi Francois,

This is a known issue.

https://markmail.org/message/6owzkxowbsf33jcy
https://markmail.org/message/ac65iqbmwjdlugz3

I will try to find a working solution for it this week.

Martin


On Mon, Oct 7, 2019 at 11:17 AM Francois Meillet 
wrote:

> Hi,
>
> There is a 404 for
> https://ci.apache.org/projects/wicket/apidocs/9.x/index.html <
> https://ci.apache.org/projects/wicket/apidocs/9.x/index.html>
>
>
> François
>
>
>
>


Re: Wicket Cookie Deletion

2019-10-07 Thread Martin Grigorov
Hi,

On Mon, Oct 7, 2019 at 3:14 AM Sibgha Nazir  wrote:

> Hi,
>
> I set a cookie from JavaScript in the chrome browser like
>
> > var d = new Date();
> > d.setTime(d.getTime() + (exdays * 24 * 60 * 60 * 1000));
> > var expires = "expires=" + d.toUTCString();
> > document.cookie = "test=true;1;path=/";
>

You don't use *expires *here.


>
>
> So the cookie value in the chrome is "true" (cookie "test"="true")
>
> then I am trying to clear the cookie in the wicket like
>
>   WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest();
>
> WebResponse webResponse = (WebResponse) RequestCycle.get().getResponse();
>
> Cookie cookietest = webRequest.getCookie("test");
> > webResponse.clearCookie(cookietest);
>

This should work.
Check what are the response headers in Chrome's Dev Tools > Network. The
new max-age value must be set to 0.


>
>
> The cookie is not deleted. I run the wicket web app on tomcat server. Does
> anyone know what could be wrong?
>
>
> Just to be clear the cookie we set with JavaScript and the cookie we
> retrieve in wicket is pointing to the same space? I am confused why it
> wouldn't work. Does it have to anything with the Tomcat server?
>
> Best Regards,
> Sibgha Nazir
>


Re: Wicket 9.x and wicket-bootstrap status

2019-09-24 Thread Martin Grigorov
2.0.11 (Wicket 8.6.1 + Bootstrap 3.x) and 3.0.0-M12 (Wicket 8.6.1 +
Bootstrap 4.x) are also released!

On Tue, Sep 24, 2019 at 9:18 AM Michał Szwaczko  wrote:

> Thanks Martin :)
>
> > Dnia 23 września 2019 o 15:54 Martin Grigorov < mgrigo...@apache.org
> mailto:mgrigo...@apache.org > napisał(a):
> >
> >
> > Wicket Bootstrap 4.0.0-M3 (Wicket 9.0.0-M3 and Bootstrap 3.x) has
> been
> > released!
> >
> > The other versions will be released on the coming days because
> upload to
> > Sonatype is very slow today.
> >
> > On Thu, Sep 19, 2019 at 3:57 PM Martin Grigorov <
> mgrigo...@apache.org mailto:mgrigo...@apache.org >
> > wrote:
> >
> >
> > > > Hi,
> > >
> > > >
> > > > The branch is there since a long time:
> > > https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/wicket-9.x.
> -SNAPSHOT
> > > builds are deployed at Sonatype OSS repos when TravisCI is
> happy to work.
> > > I am using a -SNAPSHOT build of it for my training application.
> > > Lately I release versions of Wicket-Bootstrap only when:
> > > 1) there is new release of Wicket + WicketStuff
> > > 2) someone asks for a release for a new feature or a bugfix
> > >
> > > >
> > > > I will cut a release in the coming days!
> > >
> > > >
> > > > On Thu, Sep 19, 2019 at 1:32 PM < mi...@wirelabs.net
> mailto:mi...@wirelabs.net > wrote:
> > >
> > > > >> Hi,
> > >>
> > >> What is the status of wicket-bootstrap support with wicket 9.x? I
> can see
> > >> only wicket 8.x supported and I suppose wicket 9.x is just around
> the
> > >> corner? Martin?
> > >>
> > >> Regards
> > >> Michal
> > >
> > >
> >
>


Re: Wicket 9.x and wicket-bootstrap status

2019-09-23 Thread Martin Grigorov
Wicket Bootstrap 4.0.0-M3 (Wicket 9.0.0-M3 and Bootstrap 3.x) has been
released!

The other versions will be released on the coming days because upload to
Sonatype is very slow today.

On Thu, Sep 19, 2019 at 3:57 PM Martin Grigorov 
wrote:

> Hi,
>
> The branch is there since a long time:
> https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/wicket-9.x. -SNAPSHOT
> builds are deployed at Sonatype OSS repos when TravisCI is happy to work.
> I am using a -SNAPSHOT build of it for my training application.
> Lately I release versions of Wicket-Bootstrap only when:
> 1) there is new release of Wicket + WicketStuff
> 2) someone asks for a release for a new feature or a bugfix
>
> I will cut a release in the coming days!
>
> On Thu, Sep 19, 2019 at 1:32 PM  wrote:
>
>> Hi,
>>
>> What is the status of wicket-bootstrap support with wicket 9.x? I can see
>> only wicket 8.x supported and I suppose wicket 9.x is just around the
>> corner? Martin?
>>
>> Regards
>> Michal
>
>


Re: Wicket first time visit check

2019-09-23 Thread Martin Grigorov
Hi,

For this you'd need to persist some flag somewhere. E.g. in a cookie or in
a database.

On Sun, Sep 22, 2019, 16:42 Sibgha Nazir  wrote:

> Hi,
>
> Thanks But it calls the constructor every time the page is rendered. What I
> want is, once the user has seen that page before, I don't want to execute
> that logic again.
>
> I want to trigger a javascript function for the first time users. If I have
> seen the webpage once, the next time I open it, then that javascript must
> not trigger.
>
> Also, can I trigger the javascript in onInitialize() method and how?
>
> Best Regards,
> Sibgha
>
> On Sat, Sep 21, 2019 at 7:08 AM Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > You can execute your logic in the page's constructor or onInitialize()
> > method.
> >
> > On Fri, Sep 20, 2019, 21:25 Sibgha Nazir  wrote:
> >
> > > Hi,
> > >
> > > I have a wicket application and I want to do something when the user
> > opens
> > > the webpage for the first time.
> > >
> > > Could anyone give me a clue on how to check if this is the first visit
> > on a
> > > certain webpage?
> > >
> > > Best Regards,
> > > Sibgha
> > >
> >
>


Re: Wicket first time visit check

2019-09-20 Thread Martin Grigorov
Hi,

You can execute your logic in the page's constructor or onInitialize()
method.

On Fri, Sep 20, 2019, 21:25 Sibgha Nazir  wrote:

> Hi,
>
> I have a wicket application and I want to do something when the user opens
> the webpage for the first time.
>
> Could anyone give me a clue on how to check if this is the first visit on a
> certain webpage?
>
> Best Regards,
> Sibgha
>


Re: Wicket 9.x and wicket-bootstrap status

2019-09-19 Thread Martin Grigorov
Hi,

The branch is there since a long time:
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/wicket-9.x. -SNAPSHOT
builds are deployed at Sonatype OSS repos when TravisCI is happy to work.
I am using a -SNAPSHOT build of it for my training application.
Lately I release versions of Wicket-Bootstrap only when:
1) there is new release of Wicket + WicketStuff
2) someone asks for a release for a new feature or a bugfix

I will cut a release in the coming days!

On Thu, Sep 19, 2019 at 1:32 PM  wrote:

> Hi,
>
> What is the status of wicket-bootstrap support with wicket 9.x? I can see
> only wicket 8.x supported and I suppose wicket 9.x is just around the
> corner? Martin?
>
> Regards
> Michal


Re: Google and DevUtils Inspector Page can kill your WebApp

2019-09-12 Thread Martin Grigorov
Hi Илья,

On Thu, Sep 12, 2019 at 12:04 AM Илья Нарыжный  wrote:

> Hello,
>
> This is real-life story. It started a relatively long time ago: our
> demo server from time to time had OurOfMemory condition. It was
> strange because the solution itself is very well "stress volume
> tested". So we were just rebooting demo server after such incidents.
> But it started to happen more frequently and we performed an
> investigation with interesting results which can be used as Best
> Practice and/or one more issue for Wicket.
>
> 1) We have found that most memory-consuming objects where java
> Threads. Specifically for InspectorPage from Wicket devutils.
> 2) Our applications pages don't have memory leakage condition. But
> there is one trick: some of our pages are built dynamically and
> depends on a data model. Sometimes data model might be recurrent, so
> without special treatment - Wicket will render that forever. We have
> this protection on our pages, but that was a main root-cause
> component: InspectorPage during inspecting of our pages for some
> reason doesn't see that actually recurrent elements are cut during
> rendering.
> 3) But how someone gets into InspectorPage? Apparently that was Google
> - it was trying to index our demo site and there is no protection from
> following to InspectorPage in DevUtils panel.
>
> So, some lessons learned items and comments:
> 1) If it's possible - do not deploy DevUtils - use them during actual
> development.
>

Maybe we should improve the documentation but *dev*-utils means that it is
supposed to be used during development cycle.
Same for DEVELOPMENT configuration type!
Please use DEPLOYMENT config type for production!


> 2) It will be good to investigate InspectorPage - why it's trying to
> build structure infinitely disregard of the fact that on real page
> it's actually cut off.
> 3) It might make sense to include such utils and etc into /robots.txt
> to protect from indexing
>

2) and 3) are specific to your application. Only you can investigate more.


> 4) Also, it might make sense to add "nofollow" to a link in DevUtils
> panel which leads to InspectorPage
>

Please send a Pull Request and we will merge it for the next release!
Thanks!


>
> Thanks,
> Ilia
>
> -
> Orienteer(http://orienteer.org) - open source Business Application
> Platform
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Wicket Kendo UI - Grid/Chart datasources not cleaned up

2019-09-11 Thread Martin Grigorov
Hi Manfred,

See org.apache.wicket.protocol.http.AjaxEnclosureListener for inspiration.
You'll need to do something similar - check whether any of the components
in the passed Map is a parent of a Grid or Chart and destroy it so it
cleans the DOM.

On Tue, Sep 10, 2019 at 6:15 PM Manfred Bergmann 
wrote:

> OK, maybe it's better to follow up on this while it hot.
>
> I'm not entirely certain what to do and where.
> I'd assume that when a user clicks elsewhere, which raises an
> AjaxRequestTarget I'll have to add a functionality to destroy the
> chart/grid
> as part of the AjaxRequestTarget.
> But since the click can be anywhere, should this listener be part of the
> Grid/Chart component?
> Can you briefly guide me on what to do?
>
>
> Manfred
>
>
>
> Manfred Bergmann wrote
> > Hi Martin.
> >
> > OK, thanks. That looks like a doable solution.
> > I'd go for the Listener but I'll probably have to ask some more when I'm
> > going to implement it.
> >
> >
> > Manfred
> >
> >
> >
> > Martin Grigorov-4 wrote
> >> Hi Manfred,
> >>
> >> The #refresh(PartialPageUpdateHandler) methods are useful if you update
> >> the
> >> specific component.
> >> They do not help if you repaint a parent of such a component.
> >> In your case you will need to destroy the component (grid, chart) in
> your
> >> action callback (e.g. onUpdate(), onClick()).
> >> You can do this in your code or with AjaxRequestTarget.Listener. If you
> >> do
> >> the Listener then you can donate it to Wicket JQuery UI project.
> >>
> >> On Tue, Sep 10, 2019 at 10:52 AM Manfred Bergmann 
> >
> >> mb@
> >
> >> 
> >> wrote:
> >>
> >>> Hi Sebastian.
> >>>
> >>> Thanks for the additional explanation.
> >>> But I'm not fully sure for how this is supposed to work in my case
> given
> >>> this structure/hierarchy:
> >>> page -> panel(a) -> panel(b) -> grid/chart
> >>>
> >>> Where panel (a) is replaced. Any instance of panel (b) can have a
> >>> grid/chart
> >>> but it can also host something else (depends on what is being
> >>> displayed).
> >>> I understand that when panel (a) is replaced it is garbage collected
> and
> >>> all
> >>> content on it as well in which case a reload for the grid/chart on
> >>> panel(b)
> >>> won't work?
> >>>
> >>>
> >>> Regards,
> >>> Manfred
> >>>
> >>>
> >>>
> >>>
> >>> Sebastien wrote
> >>> > Hi Manfred,
> >>> >
> >>> > Sorry, my previous answer was incomplete.
> >>> > Kendo components do usually have two methods for ajax, #reload and
> >>> > #refresh.
> >>> > Reload aims to reload the component (ie reattach to the dom) while
> >>> refresh
> >>> > aim to refresh the data only.
> >>> > IIRC, grid and chart are different in the sense that grid does have
> >>> its
> >>> > datasource aware of the request cycle so it is safe to
> reattach/reload
> >>> the
> >>> > component, the datasource will be destroyed from the dom. That's
> >>> > unfortunately not the case of the chart (you can open an issue, I can
> >>> try
> >>> > to figure out if it's achievable).
> >>> > One nice way to refresh the data without having the reload/reattach
> >>> the
> >>> > component is to use the event bus. Your master page/component will
> >>> > send/broadcast a RefreshEvent or RefreshChatEvent that will be
> catched
> >>> by
> >>> > the component hosting the chart (or the chart itself if you have
> >>> overriden
> >>> > it). Then just call refesh...
> >>> >
> >>> > Thanks and best regards,
> >>> > Sebastien
> >>> >
> >>> >
> >>> > On Mon, Sep 9, 2019, 23:29 Manfred Bergmann 
> >>>
> >>> > mb@
> >>>
> >>> >  wrote:
> >>> >
> >>> >> Hi Sebastian.
> >>> >>
> >>> >> OK, but I don't really see how reusing instances of a Kendo Grid
> >>> really
> >>> >> works in a component based design where the parents of where the
> >>> Grids
> >>> >> are
> >>>

Re: Wicket Kendo UI - Grid/Chart datasources not cleaned up

2019-09-10 Thread Martin Grigorov
Hi Manfred,

The #refresh(PartialPageUpdateHandler) methods are useful if you update the
specific component.
They do not help if you repaint a parent of such a component.
In your case you will need to destroy the component (grid, chart) in your
action callback (e.g. onUpdate(), onClick()).
You can do this in your code or with AjaxRequestTarget.Listener. If you do
the Listener then you can donate it to Wicket JQuery UI project.

On Tue, Sep 10, 2019 at 10:52 AM Manfred Bergmann 
wrote:

> Hi Sebastian.
>
> Thanks for the additional explanation.
> But I'm not fully sure for how this is supposed to work in my case given
> this structure/hierarchy:
> page -> panel(a) -> panel(b) -> grid/chart
>
> Where panel (a) is replaced. Any instance of panel (b) can have a
> grid/chart
> but it can also host something else (depends on what is being displayed).
> I understand that when panel (a) is replaced it is garbage collected and
> all
> content on it as well in which case a reload for the grid/chart on panel(b)
> won't work?
>
>
> Regards,
> Manfred
>
>
>
>
> Sebastien wrote
> > Hi Manfred,
> >
> > Sorry, my previous answer was incomplete.
> > Kendo components do usually have two methods for ajax, #reload and
> > #refresh.
> > Reload aims to reload the component (ie reattach to the dom) while
> refresh
> > aim to refresh the data only.
> > IIRC, grid and chart are different in the sense that grid does have its
> > datasource aware of the request cycle so it is safe to reattach/reload
> the
> > component, the datasource will be destroyed from the dom. That's
> > unfortunately not the case of the chart (you can open an issue, I can try
> > to figure out if it's achievable).
> > One nice way to refresh the data without having the reload/reattach the
> > component is to use the event bus. Your master page/component will
> > send/broadcast a RefreshEvent or RefreshChatEvent that will be catched by
> > the component hosting the chart (or the chart itself if you have
> overriden
> > it). Then just call refesh...
> >
> > Thanks and best regards,
> > Sebastien
> >
> >
> > On Mon, Sep 9, 2019, 23:29 Manfred Bergmann 
>
> > mb@
>
> >  wrote:
> >
> >> Hi Sebastian.
> >>
> >> OK, but I don't really see how reusing instances of a Kendo Grid really
> >> works in a component based design where the parents of where the Grids
> >> are
> >> placed are replaced on the page.
> >>
> >> In particular we have a three panes border layout, kind of a
> >> 'master-detail'
> >> plus a tree on the left side.
> >> The right most pane is the 'detail' pane where panels are replaced
> >> depending
> >> on selection on the 'master' pane. Those panels can contain Kendo Grid
> >> but
> >> some do not. So I have no other chance of creating new instances of
> Kendo
> >> Grids (DataTable).
> >> So switching through the 'master' selections creates new Kendo Grids, or
> >> Charts adding up datasources on the DOM root.
> >>
> >> I don't see how just using Chart/DataTable#refresh really should work?
> >>
> >>
> >> Manfred
> >>
> >>
> >>
> >> Sebastien wrote
> >> > Hi Manfred,
> >> >
> >> > The recommended way to refresh kendo ui components - those bound to a
> >> > datasource - is to read from the datasource.
> >> >
> >> > See Chart#refresh, it should solve the problem.
> >> >
> >> > Thanks and best regards,
> >> > Sébastien
> >>
> >>
> >>
> >> --
> >> Sent from:
> >> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
> >>
> >> -
> >> To unsubscribe, e-mail:
>
> > users-unsubscribe@.apache
>
> >> For additional commands, e-mail:
>
> > users-help@.apache
>
> >>
> >>
>
>
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Import Javascript through webjars as maven dependency.

2019-09-09 Thread Martin Grigorov
aResponse.render(JavaScriptHeaderItem.forReference(new
WebjarsJavaScriptResourceReference("jquery.scroll*T*o/current/jquery.scroll
*T*o.js")));

On Mon, Sep 9, 2019 at 2:06 PM Sibgha Nazir  wrote:

> Any idea, how to fix it?
>
> On Mon, Sep 9, 2019 at 10:01 AM Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > I think the problem is in the packaging of this webjar.
> > The folder name in the .jar file
> > is: /META-INF/resources/webjars/jquery.scroll*T*o/ . Note the capiral T
> in
> > scrollTo. It does not match with the Maven artifact id - it uses lower
> case
> > 't'.
> > Because of this WebjarsJavaScriptResourceReference cannot find it.
> >
> > On Sun, Sep 8, 2019 at 3:27 PM Sibgha Nazir  wrote:
> >
> > > Hi,
> > >
> > > I am not able to import the following through webjar as maven
> dependency
> > in
> > > my project.
> > >
> > > https://github.com/flesler/jquery.scrollTo
> > >
> > > I deployed it to the webjar using *bower install jquery.scrollTo* and
> it
> > is
> > > also visible on the webjars.org
> > >
> > > 
> > > org.webjars.bowergithub.flesler
> > > jquery.scrollto
> > > 2.1.1
> > > 
> > >
> > > Add it to the project like
> > >
> > > aResponse.render(JavaScriptHeaderItem.forReference(new
> > >
> > >
> >
> WebjarsJavaScriptResourceReference("jquery.scrollto/current/jquery.scrollto.js")));
> > >
> > >
> > >
> > > The wicket shows the error
> > >
> > >
> > > GET
> > >
> > >
> >
> http://localhost:8080/wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/jquery.scrollto/null/jquery.scrollto.js
> > > net::ERR_ABORTED 404
> > >
> > > What could be the problem?
> > >
> > > Best Regards,
> > > SIbgha
> > >
> >
>


Re: [ANNOUNCE] Apache Wicket 8.6.0 released

2019-09-09 Thread Martin Grigorov
No need to notify ASF.
Just fix the problem and start a vote for 8.6.1.

On Mon, Sep 9, 2019 at 1:19 PM Maxim Solodovnik 
wrote:

> I believe it should be sufficient to start new VOTE
>
> On Mon, 9 Sep 2019 at 17:17, Andrea Del Bene  wrote:
>
> > I'm afraid I did a mistake during the building of this version and I left
> > out some of the last changes :-(. I guess we need to perform a 8.6.1
> asap.
> > Is there any particular action that must be taken in situations like
> this?
> > Should we notify the ASF?
> >
> > On Mon, Sep 9, 2019 at 11:48 AM Olivier DUTRIEUX <
> > olivier.dutri...@pasteur.fr> wrote:
> >
> > > Hi Martin,
> > >
> > > If you check the source
> > > https://github.com/apache/wicket/releases/tag/rel%2Fwicket-8.6.0 , you
> > > don' t see this line
> > >
> >
> https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java#L106
> > >
> > > --
> > > Olivier Dutrieux
> > > Evolution du SI Scientifique et de Gestion (Tél : 31 62)
> > >
> > >
> > > -Message d'origine-
> > > De : Martin Grigorov [mailto:mgrigo...@apache.org]
> > > Envoyé : lundi 9 septembre 2019 11:09
> > > À : users@wicket.apache.org
> > > Objet : Re: [ANNOUNCE] Apache Wicket 8.6.0 released
> > >
> > > Hi Olivier,
> > >
> > > The backport of the commit from 9.x (master) is
> > >
> >
> https://github.com/apache/wicket/commit/efcffbb7be97847bec40aec77cfb9414fc55fa8c
> > > And I see the lines at:
> > >
> > >
> >
> https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java#L106
> > >
> > > And also in the sources of the release tag:
> > > https://github.com/apache/wicket/releases/tag/rel%2Fwicket-8.6.0
> > >
> > > On Mon, Sep 9, 2019 at 11:39 AM Olivier DUTRIEUX <
> > > olivier.dutri...@pasteur.fr> wrote:
> > >
> > > > I check the Improvement [WICKET-6684] on version 8.6.0 but I didn't
> > > > find any trace of it. Maybe I messed something.
> > > >
> > > > Duto
> > > >
> > > > -Message d'origine-
> > > > De : Andrea Del Bene [mailto:adelb...@apache.org] Envoyé : samedi 7
> > > > septembre 2019 19:22 À : d...@wicket.apache.org;
> > > > users@wicket.apache.org; annou...@apache.org;
> > > > annou...@wicket.apache.org Objet : [ANNOUNCE] Apache Wicket 8.6.0
> > > > released
> > > >
> > > > The Apache Wicket PMC is proud to announce Apache Wicket 8.6.0!
> > > >
> > > > Apache Wicket is an open source Java component oriented web
> > > > application framework that powers thousands of web applications and
> > > > web sites for governments, stores, universities, cities, banks, email
> > > > providers, and more. You can find more about Apache Wicket at
> > > > https://wicket.apache.org
> > > >
> > > > This release marks another minor release of Wicket 8. We use semantic
> > > > versioning for the development of Wicket, and as such no API breaks
> > > > are present breaks are present in this release compared to 8.0.0.
> > > >
> > > > Using this release
> > > > --
> > > >
> > > > With Apache Maven update your dependency to (and don't forget to
> > > > update any other dependencies on Wicket projects to the same
> version):
> > > >
> > > > 
> > > >  org.apache.wicket
> > > >  wicket-core
> > > >  8.6.0
> > > > 
> > > >
> > > > Or download and build the distribution yourself, or use our
> > > > convenience binary package you can find here:
> > > >
> > > >   * Download:
> http://wicket.apache.org/start/wicket-8.x.html#manually
> > > >
> > > > Upgrading from earlier versions
> > > > ---
> > > >
> > > > If you upgrade from 8.y.z this release is a drop in replacement. If
> > > > you come from a version prior to 8.0.0, please read our Wicket 8
> > > > migration guide found at
> > > >
> > > >   * http://s.apache.org/wicket8migrate
> > > >
> > > > Have fun!
> > > >
> > > > — The Wicket team
> > > >
> > >

Re: [ANNOUNCE] Apache Wicket 8.6.0 released

2019-09-09 Thread Martin Grigorov
Hi Olivier,

The backport of the commit from 9.x (master) is
https://github.com/apache/wicket/commit/efcffbb7be97847bec40aec77cfb9414fc55fa8c
And I see the lines at:
https://github.com/apache/wicket/blob/wicket-8.x/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java#L106

And also in the sources of the release tag:
https://github.com/apache/wicket/releases/tag/rel%2Fwicket-8.6.0

On Mon, Sep 9, 2019 at 11:39 AM Olivier DUTRIEUX <
olivier.dutri...@pasteur.fr> wrote:

> I check the Improvement [WICKET-6684] on version 8.6.0 but I didn't find
> any trace of it. Maybe I messed something.
>
> Duto
>
> -Message d'origine-
> De : Andrea Del Bene [mailto:adelb...@apache.org]
> Envoyé : samedi 7 septembre 2019 19:22
> À : d...@wicket.apache.org; users@wicket.apache.org; annou...@apache.org;
> annou...@wicket.apache.org
> Objet : [ANNOUNCE] Apache Wicket 8.6.0 released
>
> The Apache Wicket PMC is proud to announce Apache Wicket 8.6.0!
>
> Apache Wicket is an open source Java component oriented web application
> framework that powers thousands of web applications and web sites for
> governments, stores, universities, cities, banks, email providers, and
> more. You can find more about Apache Wicket at https://wicket.apache.org
>
> This release marks another minor release of Wicket 8. We use semantic
> versioning for the development of Wicket, and as such no API breaks are
> present breaks are present in this release compared to 8.0.0.
>
> Using this release
> --
>
> With Apache Maven update your dependency to (and don't forget to update
> any other dependencies on Wicket projects to the same version):
>
> 
>  org.apache.wicket
>  wicket-core
>  8.6.0
> 
>
> Or download and build the distribution yourself, or use our convenience
> binary package you can find here:
>
>   * Download: http://wicket.apache.org/start/wicket-8.x.html#manually
>
> Upgrading from earlier versions
> ---
>
> If you upgrade from 8.y.z this release is a drop in replacement. If you
> come from a version prior to 8.0.0, please read our Wicket 8 migration
> guide found at
>
>   * http://s.apache.org/wicket8migrate
>
> Have fun!
>
> — The Wicket team
>
>
> 
>
>  The signatures for the source release artefacts:
>
>
> Signature for apache-wicket-8.6.0.zip:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl1u0ggACgkQh48B+qjT
> VuHBVRAAgX8nPfftIKv6z0Rimyg4M9hefpkwcVCkj8mQ2q9cnRQCNN8lWPrVsqOz
> jfkWOM1I3rmjR60o5eREFuNK+t7RNxdwfdZqlB+zsgu2BCNscpQMaTruf2uI14ip
> B83PYCMkTSDA+BCJD1MTwRf3Ih3M+0rq4l3vedzStfC4GvmmwHRvMWTOml5i9Whg
> pSStZvX9h61n6ofRNq/feLQi7342GOgv+/r0cvTVDRdIsEeYGalu1b+ZJKsjfTX3
> l0oMiRILzFltg+CQP0fhWibfLkvyRLM+R4598rgvwM+QcKo7aCn0LcIEIhp0dYDS
> KI6IhsPd/NS0qKoKgIPmQ6tMsvMWGOxTOpQMxnAj97wVzYVf1QoXArPuc+JaSrFE
> D/a78zUMc78UFjdt38NBA22jf7HbcjVkAUUjD9fPtNStFnnrisniyw16dL0Wa6MA
> kuiPuyl7gsPAkmOXH68KtVaR7ncTORPCt4ZC/6GxoRbhDc71+dLPz5XKpeDdqy8O
> /pBGtsucjI9xIGZqGHWFvfAaBqqv2t4QARxOdkDA9d09PL4o/N+gljho+a30GrDv
> A35wG2y2Idkoe1t4EJeHpMHGPmqMAj/m1wYagJjMeiXRDgtfFoJIlRfAboxq8Dwd
> uT+mRsdS0hq8q78yPZPW3N24cC3gwohFJMWfb4IukQbFGI2gznE=
> =mzMF
> -END PGP SIGNATURE-
>
> Signature for apache-wicket-8.6.0.tar.gz:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl1u0ggACgkQh48B+qjT
> VuHSZw//WF61doVJ8fDK8hPvk8Td6Yf4hMzP7kff7tAkm+w72LqnXlUM7IDci5nz
> Dcx627fBAYIXdRtfOkq53vRrFV+1e87x8iM/bnp7Tzj5lwF6BOvRkQ+gr6U6+6An
> 5CblTMT5kSq9xKGm8/Gj6I1OrQiVdSqFPWt7N/4D7FG9uekRVJoc+0ubekqdGR1M
> lkoT8Wfteo7sstoD8qvQEgyKKZLqbxTKDGiVBywmSKVuxkv+4JnETI2k1R1TsCr0
> /JdGx6fNxd/sBUKLoAUo8cxBpv9weuzvPCMw89eVGsKacBDedZMK7iMfR3M43Iz/
> HuEN26JnHM3kqSBCMMYE197djXOroUhXmhr9WfNRxiaTqJsKbS1oG3jO9EkHQt8Y
> ldhwiTaH8PmGE72xhn+w+FElZvazwlFXSECHZK92wGFEzq5VO7atv88AOmtQHM1o
> LbgHOjhUYLQHj15JXn4g4XYFJ5WnZR3gbldAV9JEhXqnx30M6wMDrWCCw6K0+uh2
> k8Il3y6TMY7KSrnUYwTeljyrLYReoAtYfQxi6EdGBlKamuyKXtSBqO0a2J5wsxnv
> Z2fk3efWKDzdxbc9GmYbXMlTKtjYx5UYZ+PcgAuGvS81ejwzmiy5dH8rJYedx235
> j3D8JG/YyG2Ja0r6nmwX7BDm8QS4W5eU+UQIyIq0KLCFND/qzSU=
> =VBOu
> -END PGP SIGNATURE-
>
> 
>
>  CHANGELOG for 8.6.0:
>
> ** Bug
>
>  * [WICKET-6613] - Wicket 8.1 ModalWindow autosizing problem
>  * [WICKET-6671] - IAjaxLink should be serializable
>  * [WICKET-6676] - Quickstart application won't deploy to GlassFish
>  * [WICKET-6680] - JavaScriptStripper chokes on template literals that
> contain two forward slashes
>  * [WICKET-6689] - ClientProperties.getTimeZone() has some issue when
> DST and UTC offsets are different
>  * [WICKET-6690] - NullPointerException in
> KeyInSessionSunJceCryptFactory.
>  * [WICKET-6692] - Page deserialization on websocket close - possible
> performance issue
>
> ** Improvement
>
>  * [WICKET-6675] - log4j-slf4j-impl requires 

Re: Import Javascript through webjars as maven dependency.

2019-09-09 Thread Martin Grigorov
Hi,

I think the problem is in the packaging of this webjar.
The folder name in the .jar file
is: /META-INF/resources/webjars/jquery.scroll*T*o/ . Note the capiral T in
scrollTo. It does not match with the Maven artifact id - it uses lower case
't'.
Because of this WebjarsJavaScriptResourceReference cannot find it.

On Sun, Sep 8, 2019 at 3:27 PM Sibgha Nazir  wrote:

> Hi,
>
> I am not able to import the following through webjar as maven dependency in
> my project.
>
> https://github.com/flesler/jquery.scrollTo
>
> I deployed it to the webjar using *bower install jquery.scrollTo* and it is
> also visible on the webjars.org
>
> 
> org.webjars.bowergithub.flesler
> jquery.scrollto
> 2.1.1
> 
>
> Add it to the project like
>
> aResponse.render(JavaScriptHeaderItem.forReference(new
>
> WebjarsJavaScriptResourceReference("jquery.scrollto/current/jquery.scrollto.js")));
>
>
>
> The wicket shows the error
>
>
> GET
>
> http://localhost:8080/wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/jquery.scrollto/null/jquery.scrollto.js
> net::ERR_ABORTED 404
>
> What could be the problem?
>
> Best Regards,
> SIbgha
>


Re: Wrapping a FormComponent with a Border

2019-09-03 Thread Martin Grigorov
On Tue, Sep 3, 2019 at 10:30 AM "Tom Götz"  wrote:

> Thanks Martin, I will look into that. But won't it be a problem that I
> will add the  / TextField to the Border without having any markup
> inside the Border? Won't I need my  markup inside the border
> s?
>

right! it is a Border, not a Panel (
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/wicket-8.x/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/form/FormGroup.html#L9
)
I think it would be easier if you roll MyFormGroupPanel instead of using a
Border.
If you decide to stick with FormGroup then you will need to override
onComponentTagBody() too


>
> Tom
>
>
> > Gesendet: Dienstag, 03. September 2019 um 09:22 Uhr
> > Von: "Martin Grigorov" 
> > An: "users@wicket.apache.org" 
> > Betreff: Re: Re: Wrapping a FormComponent with a Border
> >
> > Hi Tom,
> >
> > Since your "user" is going to add a TextField in the Java code then I
> > assume (s)he is going to add  in the markup.
> > Your IComponentInitializationListener will replace all components of type
> > TextField which do not have FormGroup as a parent with a MyFormGroup.
> >
> > public class MyFormGroup extends FormGroup {
> >// constructor(s)
> >
> >   @Override
> >   public void onComponentTag(ComponentTag tag) {
> > super(tag);
> > tag.setName("div");  // this modifies  to 
> >   }
> > }
> >
> > I am not sure, but you may also need to expand the tag from OpenClose
> (i.e.
> > ) to open+close (i.e. ). See
> ComponentTag#isOpenClose()
> > and Component#afterRender();
> >
> > On Tue, Sep 3, 2019 at 10:09 AM "Tom Götz"  wrote:
> >
> > > Martin,
> > >
> > > maybe you could point me into the right direction concerning the markup
> > > manipulation part?
> > >
> > > This is what I got in my HTML:
> > >
> > > 
> > >   
> > > 
> > >
> > > I guess this is what I need for effectively replacing the input with a
> > > FormGroup border:
> > >
> > > 
> > >   
> > > 
> > >   
> > > 
> > >
> > > Where would be the best place in the code to start looking?
> > >
> > > Thanks in advance
> > > Tom
> > >
> > >
> > >
> > >
> > > > Gesendet: Montag, 02. September 2019 um 13:57 Uhr
> > > > Von: "Tom Götz" 
> > > > An: users@wicket.apache.org
> > > > Betreff: Re: Wrapping a FormComponent with a Border
> > > >
> > > > Thanks Martin, this is exactly what I had in mind. I already
> implemented
> > > 1), replacing the TextField with said Border but now am stuck with the
> > > "HTML manipulation" part ...
> > > >
> > > > Tom
> > > >
> > > >
> > > > > Gesendet: Montag, 02. September 2019 um 13:47 Uhr
> > > > > Von: "Martin Grigorov" 
> > > > > An: "users@wicket.apache.org" 
> > > > > Betreff: Re: Wrapping a FormComponent with a Border
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > I imagine two ways:
> > > > > 1) use
> org.apache.wicket.application.IComponentInitializationListener
> > > that
> > > > > manipulates the component tree whenever the passed component is an
> > > instance
> > > > > of TextField and has no (direct?!) parent of type FormGroup
> > > > > 2) use AOP
> > > > >
> > > > > In both cases you will need to also the markup because FormGroup
> > > expects to
> > > > > be attached on a , while you will have an . For this
> you
> > > will
> > > > > probably need to extend Wicket Bootstrap's FormGroup and in your
> > > custom one
> > > > > override onComponentTag() (and onComponentTagBody() - most probably
> > > not).
> > > > >
> > > > > On Mon, Sep 2, 2019 at 2:05 PM "Tom Götz" 
> wrote:
> > > > >
> > > > > > Let me try to explain what I want to achieve more precisely:
> > > > > >
> > > > > > - user adds a TextField to a page
> > > > > > - I want to replace that TextField with a Border (Wicket Border
> > > component,
> > > > > > e.g. FormGroup from wicket-bootstrap) and put the TextField
> inside
> > > that

Re: Re: Wrapping a FormComponent with a Border

2019-09-03 Thread Martin Grigorov
Hi Tom,

Since your "user" is going to add a TextField in the Java code then I
assume (s)he is going to add  in the markup.
Your IComponentInitializationListener will replace all components of type
TextField which do not have FormGroup as a parent with a MyFormGroup.

public class MyFormGroup extends FormGroup {
   // constructor(s)

  @Override
  public void onComponentTag(ComponentTag tag) {
super(tag);
tag.setName("div");  // this modifies  to 
  }
}

I am not sure, but you may also need to expand the tag from OpenClose (i.e.
) to open+close (i.e. ). See ComponentTag#isOpenClose()
and Component#afterRender();

On Tue, Sep 3, 2019 at 10:09 AM "Tom Götz"  wrote:

> Martin,
>
> maybe you could point me into the right direction concerning the markup
> manipulation part?
>
> This is what I got in my HTML:
>
> 
>   
> 
>
> I guess this is what I need for effectively replacing the input with a
> FormGroup border:
>
> 
>   
> 
>   
> 
>
> Where would be the best place in the code to start looking?
>
> Thanks in advance
> Tom
>
>
>
>
> > Gesendet: Montag, 02. September 2019 um 13:57 Uhr
> > Von: "Tom Götz" 
> > An: users@wicket.apache.org
> > Betreff: Re: Wrapping a FormComponent with a Border
> >
> > Thanks Martin, this is exactly what I had in mind. I already implemented
> 1), replacing the TextField with said Border but now am stuck with the
> "HTML manipulation" part ...
> >
> > Tom
> >
> >
> > > Gesendet: Montag, 02. September 2019 um 13:47 Uhr
> > > Von: "Martin Grigorov" 
> > > An: "users@wicket.apache.org" 
> > > Betreff: Re: Wrapping a FormComponent with a Border
> > >
> > > Hi Tom,
> > >
> > > I imagine two ways:
> > > 1) use org.apache.wicket.application.IComponentInitializationListener
> that
> > > manipulates the component tree whenever the passed component is an
> instance
> > > of TextField and has no (direct?!) parent of type FormGroup
> > > 2) use AOP
> > >
> > > In both cases you will need to also the markup because FormGroup
> expects to
> > > be attached on a , while you will have an . For this you
> will
> > > probably need to extend Wicket Bootstrap's FormGroup and in your
> custom one
> > > override onComponentTag() (and onComponentTagBody() - most probably
> not).
> > >
> > > On Mon, Sep 2, 2019 at 2:05 PM "Tom Götz"  wrote:
> > >
> > > > Let me try to explain what I want to achieve more precisely:
> > > >
> > > > - user adds a TextField to a page
> > > > - I want to replace that TextField with a Border (Wicket Border
> component,
> > > > e.g. FormGroup from wicket-bootstrap) and put the TextField inside
> that
> > > > border
> > > >
> > > > The problem ist not: "how do I wrap a component with some HTML
> markup?"
> > > > (either generated by Java code or clientside), but: how can I
> manipulate
> > > > the component tree (server side) in such a way, that I can remove the
> > > > TextField from it's parent and replace it with a Border that
> contains that
> > > > TextField!?
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Gesendet: Montag, 02. September 2019 um 12:49 Uhr
> > > > > Von: "Tobias Soloschenko"  >
> > > > > An: users@wicket.apache.org
> > > > > Betreff: Re: Wrapping a FormComponent with a Border
> > > > >
> > > > > Hi,
> > > > >
> > > > > why not add a css class and style it?
> > > > >
> > > > > kind regards
> > > > >
> > > > > Tobias
> > > > >
> > > > > > Am 02.09.2019 um 12:20 schrieb Ernesto Reinaldo Barreiro <
> > > > reier...@gmail.com>:
> > > > > >
> > > > > > Another possibility is to do this client side...
> > > > > >
> > > > > >> On Mon, Sep 2, 2019, 11:43 AM "Tom Götz" 
> wrote:
> > > > > >>
> > > > > >> That would be great, thanks in advance!
> > > > > >>
> > > > > >> Tom
> > > > > >>
> > > > > >>
> > > > > >>> Gesendet: Montag, 02. September 2019 um 10:39 Uhr
> > > > > >>> Von: "Ernesto Reinaldo Barreiro" 
> > > > > >>> An: users@wicket.apache.org
> > > > > >>> Betreff: Re: Wrapping a FormComponent with a Border
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>>> On Mon, Sep 2, 2019 at 11:13 AM Tom Götz  >
> > > > wrote:
> > > > > >>>>
> > > > > >>>> Thanks Ernesto! This example is from 2007 though and uses
> > > > > >>>> compent.setComponentBorder 
> > > > > >>>> Is there something more close to current Wicket versions
> available
> > > > > >> maybe?
> > > > > >>>> :)
> > > > > >>>>
> > > > > >>>
> > > > > >>> I think I have somewhere on a private project something similar
> > > > > >> implemented
> > > > > >>> for Wicket 7.x... I can try to dig it up and send classes to
> you.
> > > > > >>>
> > > > > >>> --
> > > > > >>> Regards - Ernesto Reinaldo Barreiro
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Wrapping a FormComponent with a Border

2019-09-02 Thread Martin Grigorov
Hi Tom,

I imagine two ways:
1) use org.apache.wicket.application.IComponentInitializationListener that
manipulates the component tree whenever the passed component is an instance
of TextField and has no (direct?!) parent of type FormGroup
2) use AOP

In both cases you will need to also the markup because FormGroup expects to
be attached on a , while you will have an . For this you will
probably need to extend Wicket Bootstrap's FormGroup and in your custom one
override onComponentTag() (and onComponentTagBody() - most probably not).

On Mon, Sep 2, 2019 at 2:05 PM "Tom Götz"  wrote:

> Let me try to explain what I want to achieve more precisely:
>
> - user adds a TextField to a page
> - I want to replace that TextField with a Border (Wicket Border component,
> e.g. FormGroup from wicket-bootstrap) and put the TextField inside that
> border
>
> The problem ist not: "how do I wrap a component with some HTML markup?"
> (either generated by Java code or clientside), but: how can I manipulate
> the component tree (server side) in such a way, that I can remove the
> TextField from it's parent and replace it with a Border that contains that
> TextField!?
>
> Tom
>
>
>
>
>
>
> > Gesendet: Montag, 02. September 2019 um 12:49 Uhr
> > Von: "Tobias Soloschenko" 
> > An: users@wicket.apache.org
> > Betreff: Re: Wrapping a FormComponent with a Border
> >
> > Hi,
> >
> > why not add a css class and style it?
> >
> > kind regards
> >
> > Tobias
> >
> > > Am 02.09.2019 um 12:20 schrieb Ernesto Reinaldo Barreiro <
> reier...@gmail.com>:
> > >
> > > Another possibility is to do this client side...
> > >
> > >> On Mon, Sep 2, 2019, 11:43 AM "Tom Götz"  wrote:
> > >>
> > >> That would be great, thanks in advance!
> > >>
> > >> Tom
> > >>
> > >>
> > >>> Gesendet: Montag, 02. September 2019 um 10:39 Uhr
> > >>> Von: "Ernesto Reinaldo Barreiro" 
> > >>> An: users@wicket.apache.org
> > >>> Betreff: Re: Wrapping a FormComponent with a Border
> > >>>
> > >>> Hi,
> > >>>
> >  On Mon, Sep 2, 2019 at 11:13 AM Tom Götz 
> wrote:
> > 
> >  Thanks Ernesto! This example is from 2007 though and uses
> >  compent.setComponentBorder 
> >  Is there something more close to current Wicket versions available
> > >> maybe?
> >  :)
> > 
> > >>>
> > >>> I think I have somewhere on a private project something similar
> > >> implemented
> > >>> for Wicket 7.x... I can try to dig it up and send classes to you.
> > >>>
> > >>> --
> > >>> Regards - Ernesto Reinaldo Barreiro
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Streaming a PDF into an iFrame

2019-08-29 Thread Martin Grigorov
Hi,

Check the response headers of PDF.
If chunked transfer encoding is used then maybe you can fix it by providing
explicitly the Content-Lenght in your Wicket code.

On Thu, Aug 29, 2019 at 12:05 AM Benjamin Chew 
wrote:

> Yes, they are the full PDFs that I'm expecting.
>
> Ben
>
>
> On Wed, Aug 28, 2019 at 12:34 PM Lon Varscsak 
> wrote:
>
> > If it's closing the connection on the PDF pre-maturely, are you getting
> the
> > FULL PDF downloaded?
> >
> > -Lon
> >
> > On Wed, Aug 28, 2019 at 10:14 AM Benjamin Chew 
> > wrote:
> >
> > > Hi Sven,
> > >
> > > Hmm... so this seems to be a problem only on specific browsers.
> > >
> > > I'm seeing this on:
> > > - Google Chrome Version 76.0.3809.100 (OS X Mojave & Win 7)
> > > - Safari Version 12.1.2 (OS X Mojave)
> > > - IE 11 Version 11.0.135 (Win 7)
> > >
> > > And not seeing this on:
> > > - Firefox Quantum 68.0.2 (OS X Mojave)
> > > - Firefox Quantum 68.0.1 (Win 7)
> > >
> > > Knowing this, I'm going to move on from this issue (for now), but
> thanks
> > > for all your help!
> > >
> > > Ben
> > >
> > >
> > > On Wed, Aug 28, 2019 at 9:32 AM Sven Meier  wrote:
> > >
> > > > Hi Ben,
> > > >
> > > > which browser?
> > > >
> > > > We had long time problems with IE stopping requests an re-requesting
> > > > resources without reason.
> > > >
> > > > Sven
> > > >
> > > > Am 28. August 2019 16:18:23 MESZ schrieb Benjamin Chew <
> > > > bc...@smarthealth.com>:
> > > > >Thanks, Sven.
> > > > >
> > > > >The weird thing is that this is happening during my testing, and I’m
> > > > >not navigating away from the page at all...
> > > > >
> > > > >Ben
> > > > >
> > > > >> On Aug 27, 2019, at 11:34 AM, Sven Meier  wrote:
> > > > >>
> > > > >> Hi Benjamin,
> > > > >>
> > > > >> this just means that the browser closed the connection before the
> > pdf
> > > > >was fully loaded from the server, e.g. if the user switches to a
> > > > >different page before the iframe has finished loading.
> > > > >>
> > > > >> Nothing you need/can do about it.
> > > > >>
> > > > >> Have fun
> > > > >> Sven
> > > > >>
> > > > >>
> > > > >>> On 27.08.19 02:13, Benjamin Chew wrote:
> > > > >>> I said thanks too soon. ;)
> > > > >>>
> > > > >>> Now I'm seeing this warning intermittently:
> > > > >>> org.apache.wicket.protocol.http.servlet.ResponseIOException:
> > > > >>> org.eclipse.jetty.io.EofException
> > > > >>> Caused by: org.eclipse.jetty.io.EofException
> > > > >>> Caused by: java.io.IOException: Broken pipe
> > > > >>>
> > > > >>> Is there anything in the DocumentInlineFrame class or the way I'm
> > > > >using it
> > > > >>> that would cause this problem?
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Ben
> > > > >>>
> > > > >>> /*** Calling Class ***/
> > > > >>> queue(new DocumentInlineFrame("ticketsIFrame", new
> > > > >ResourceStreamResource()
> > > > >>> {
> > > > >>>@Override
> > > > >>>protected IResourceStream getResourceStream(Attributes
> > > > >attributes) {
> > > > >>>return
> > > > >>> pdfStream(getReports().get(SHTicketUtils.TICKET_REPORT_STRING));
> > > > >>>}
> > > > >>>
> > > >
> > > >
> > >
> >
> >}.setCacheDuration(Duration.NONE).setContentDisposition(ContentDisposition.INLINE).setFileName("Tickets.pdf")));
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> /*** DocumentInlineFrame Class ***/
> > > > >>> public class DocumentInlineFrame extends WebMarkupContainer
> > > > >implements
> > > > >>> IRequestListener {
> > > > >>> private static final long serialVersionUID = 1 L;
> > > > >>> private IResource documentResource;
> > > > >>>
> > > > >>> /**
> > > > >>>  * Constructor receiving an IResourceStream..
> > > > >>>  *
> > > > >>>  * @param id
> > > > >>>  * @param stream
> > > > >>>  */
> > > > >>> public DocumentInlineFrame(String id, IResourceStream
> stream) {
> > > > >>> this(id, new ResourceStreamResource(stream));
> > > > >>> }
> > > > >>>
> > > > >>> /**
> > > > >>>  * Constructor receiving an IResource..
> > > > >>>  *
> > > > >>>  * @param id
> > > > >>>  * @param resourceListener
> > > > >>>  */
> > > > >>> public DocumentInlineFrame(final String id, IResource
> > > > >documentResource)
> > > > >>> {
> > > > >>> super(id);
> > > > >>> this.documentResource = documentResource;
> > > > >>> }
> > > > >>>
> > > > >>> /**
> > > > >>>  * Gets the url to use for this link.
> > > > >>>  *
> > > > >>>  * @return The URL that this link links to
> > > > >>>  */
> > > > >>> protected CharSequence getURL() {
> > > > >>> return urlForListener(null);
> > > > >>> }
> > > > >>>
> > > > >>> /**
> > > > >>>  * Handles this frame's tag.
> > > > >>>  *
> > > > >>>  * @param tag the component tag
> > > > >>>  * @see
> > org.apache.wicket.Component#onComponentTag(ComponentTag)
> > > > >>>  */
> > > > >>> @Override
> > > > >>> protected void onComponentTag(final ComponentTag tag) {
> > > > >>> 

Re: non-serializable objects to feed a DropDownChoice

2019-08-28 Thread Martin Grigorov
Hi,

Is there a problem in using LoadableDetachableModel> for
the DropDownChoice ?

Use this constuctor:
public DropDownChoice(String id, IModel model, IModel> choices, IChoiceRenderer renderer)


On Wed, Aug 28, 2019 at 10:56 PM René Stolle  wrote:

> Hello there,
>
> my domain classes are mostly not serializable. Making use of
> LoadableDetachableModels I have no problems execpt of one situtation: I
> couldn't find an easy solution to place a list of domain objects in a
> DropDownChoice without getting serialization issues. The examples I
> found ignore this problem and I have only a pretty complicated work
> around. My domain classes have an id of type long (serializeable), which
> I use in my solution. This works, but the code confuses me everytime I
> have to touch it.
>
> My question now, how is this done the "wicket way" ? Is there an elegant
> solution out there?
>
> René
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Re: Wicket Spring boot - use spring devtools

2019-08-28 Thread Martin Grigorov
On Wed, Aug 28, 2019 at 12:04 PM Per Newgro  wrote:

> Hello Martin,
>
> the problem is that i assign a model in request cycle metadata by using
> the key
>
> public class IdentityInstance extends MetaDataKey> {
>
> public static IdentityInstance KEY = new IdentityInstance();
>
> private IdentityInstance() {
> super();
> }
> }
>
> Page:
> getRequestCycle().setMetaData(IdentityInstance.KEY, identityModel);
>
> Widget:
> IModel identity =
> getRequestCycle().getMetaData(IdentityInstance.KEY);
>
> But the model in Widget is always null. While debugging i found that
> object identity is used in Class#equals(Object o), what is ok for me.
> But with different classloaders class is loaded multiple times.
>
> I could provide a quickstart for this & create an issue, if you like. (?)
>

No, I don't.
I don't see why Wicket should be responsible for the way other libraries
work.
If you create a quickstart that does not use any third party libraries then
we will take a look!


>
> I would like to adapt my configuration so that devtools are still
> available.
>
> (DCEVM i need to inspect :-).)
>
> Thanks for your support.
> Regards
> Per
>
> > Gesendet: Mittwoch, 28. August 2019 um 10:37 Uhr
> > Von: "Martin Grigorov" 
> > An: "users@wicket.apache.org" 
> > Betreff: Re: Wicket Spring boot - use spring devtools
> >
> > Hi,
> >
> > This is how Spring Dev Tools work. When it detects a change it removes
> the
> > old application class loader and creates a new one.
> > Why this is a problem for you ?
> >
> > I personally prefer to use DCEVM (https://dcevm.github.io/). It is able
> to
> > redefine a specific class in the current class loader.
> > When I change a Spring @Configuration or Hibernate mapping I just restart
> > the application manually.
> >
> > On Wed, Aug 28, 2019 at 11:25 AM Per Newgro  wrote:
> >
> > > Hello *,
> > >
> > > I migrate my current wicket app to spring boot version (
> > > https://github.com/MarcGiffing/wicket-spring-boot).
> > >
> > > So far it was straightforward. But now i experience a problem with
> > > inclusion of
> > > 
> > >
> > > org.springframework.boot
> > >
> > > spring-boot-devtools
> > > 
> > >
> > > It seems that the "restart / reload feature" of devtools loads my
> classes
> > > multiple times, so that they are not equal anymore (x.class <>
> x.class).
> > > I understand that this is happening. But i would like to know if there
> is
> > > another option for me beside - removing spring-boot-devtools.
> > >
> > > Would be nice to here from you
> > > Thanks
> > > Per
> > >
> > > -
> > > 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: Wicket Spring boot - use spring devtools

2019-08-28 Thread Martin Grigorov
Hi,

This is how Spring Dev Tools work. When it detects a change it removes the
old application class loader and creates a new one.
Why this is a problem for you ?

I personally prefer to use DCEVM (https://dcevm.github.io/). It is able to
redefine a specific class in the current class loader.
When I change a Spring @Configuration or Hibernate mapping I just restart
the application manually.

On Wed, Aug 28, 2019 at 11:25 AM Per Newgro  wrote:

> Hello *,
>
> I migrate my current wicket app to spring boot version (
> https://github.com/MarcGiffing/wicket-spring-boot).
>
> So far it was straightforward. But now i experience a problem with
> inclusion of
> 
>
> org.springframework.boot
>
> spring-boot-devtools
> 
>
> It seems that the "restart / reload feature" of devtools loads my classes
> multiple times, so that they are not equal anymore (x.class <> x.class).
> I understand that this is happening. But i would like to know if there is
> another option for me beside - removing spring-boot-devtools.
>
> Would be nice to here from you
> Thanks
> Per
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Migrating to 8.5

2019-08-19 Thread Martin Grigorov
On Mon, Aug 19, 2019 at 1:48 PM Bas Gooren  wrote:

> Hi!
>
> It sounds like you are not referencing the correct wicket-request
> dependency.
>
> Did you check your maven dependency tree to ensure there are no old (or
> duplicate/multiple) versions of wicket dependencies being resolved?
>

Indeed, this looks like you have an older version of wicket-request.jar in
your classpath.
https://github.com/apache/wicket/blob/wicket-8.x/wicket-request/src/main/java/org/apache/wicket/request/mapper/ParentPathReferenceRewriter.java#L46
is
the "missing" constructor.
Remove wicket-request dependency form your pom.xml file. Maven will resolve
and download the correct one (v. 8.5.0) as a transitive dependency of
wicket-core dependency.


>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 19 augustus 2019 bij 12:44:24, sb_apa...@bursch.com (
> sb_apa...@bursch.com)
> schreef:
>
> Hi
>
> I'm trying to migrate my project from 7.x to 8.5. I created a new
> pom.xml using your Quick Start Wizard, checked the old dependencies for
> new versions, inserted the dependencies to the new pom.xml and fixed the
> compile errors.
>
> But deploying the war-file to tomcat 8, I'm receiving the following error:
>
> java.lang.NoSuchMethodError:
>
> org.apache.wicket.request.mapper.ParentPathReferenceRewriter.(Lorg/apache/wicket/request/IRequestMapper;Ljava/util/function/Supplier;)V
>
>
>
> I would be grateful for any tip on where the mistake might be or to
> debug this problem.
>
> Kind Regards,
> Sven
>
> (full Errormessage attached)
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>


Re: multiple AjaxFileDropBehaviour on single page

2019-08-14 Thread Martin Grigorov
On Wed, Aug 14, 2019 at 10:19 AM Sven Meier  wrote:

> Hi Korbinian,
>
> Wicket Ajax is primarily used for UI updates, thus all requests *have*
> to be sent sequentially: Otherwise user input
> (click...tab...type...click...click) would not be processed in a
> deterministic way!
> Furthermore all requests are queued on the server too (each page is
> locked separately), so developers don't need to tackle multi-threading
> in their UI code.
>
> I'm not aware of any UI toolkit that is multi-threaded. Because of our
> use of Ajax, users can still continue to use the UI while a request is
> running - that's better than other solutions (e.g. Swing or Android)
> where everything is halted (layout, repaint) until the processing has
> finished.
>
> Regarding parallel file uploads:
> This is clearly something that could be done asynchronously since it
> doesn't interfere with user input.
> For the JS side you just have to use a separate Ajax channel. But the
> request has to be targeted at a resource instead of a component, since
> the former is processed in parallel.
>
> Take a look at AjaxDownloadBehavior, it is able to target a resource
> (locks the page) or a resourceReference (doesn't lock the page).
> Maybe we can improve AjaxFileDropBehaviour to do something similar.
>

+1
After reading the last paragraph I think AjaxUploadBehavior would have been
a better name for this class, since it is the opposite of
AjaxDownloadBehavior. But naming has always have been hard! :-)


>
> Have fun
> Sven
>
>
> On 13.08.19 21:17, Korbinian Bachl wrote:
> > Hi Sven,
> >
> > so to get this right: all wicket ajax is basically a queue where only 1
> instance is worked on at a time and nothing is possible in parallel?
> > (but browsers and ajax in parallel is working since at least 2011? e.g.:
> jQuery.when() )
> >
> > You mention the upload to a resource - how would this change it in that
> in could be parallel and could you point me an example?
> >
> > Best & Thanks for the answer so far,
> >
> > KB
> >
> > - Ursprüngliche Mail -
> >> Von: "Sven Meier" 
> >> An: "users" 
> >> Gesendet: Dienstag, 13. August 2019 09:03:49
> >> Betreff: Re: multiple AjaxFileDropBehaviour on single page
> >> Hi,
> >>
> >> all Ajax behaviors' requests are queued in the browser. Even if you
> >> disable this (see AjaxRequestAttributes#channel), all access to the page
> >> is synchronized on the server anyway.
> >>
> >> You could to upload to a resource instead, AjaxFileDropBehaviour doesn't
> >> support this though.
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >> On 13.08.19 08:19, Korbinian Bachl wrote:
> >>> Hi,
> >>>
> >>> wicket 8 has this neat AjaxFileDropBehaviour and it works like charm.
> However,
> >>> if I have multiple components on one page with a AjaxFileDropBehaviour
> each and
> >>> the upload of 1 drop is running, i cant upload a 2nd one at the same
> time; Any
> >>> idea how to solve this?
> >>>
> >>> E.g.: File 1 with 100MB gets dropped onto component A, File B wiht
> 50MB gets
> >>> dropped onto Component B about 10 secs later - upload of a is not
> working and
> >>> page somehow goes stale. It might be noteworthy that during the upload
> an
> >>> IAjaxIndicatorAware spinner is shown on Component A (and expected on
> B);
> >>>
> >>> Best,
> >>>
> >>> KB
> >>>
> >>> -
> >>> 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: getPageClass locks the page

2019-08-12 Thread Martin Grigorov
Hi,

If the page is not unlocked then it is a bug.
But it is strange that no one faced it before. This code is in use since
Wicket 1.5.0.

On Tue, Aug 13, 2019 at 7:38 AM Andrew Kondratev 
wrote:

> Hi!
>
> My colleague noticed some dodgy behavior, which I think could be a bug.
> Just asking here if it's known, befor I try to create a quickstart or PR.
>
> * page is rendered
> * user interacts with a page causing ajax request (clicking checkbox)
> * the wicket PageAccessSynchronizer locks, renders and unlocks the page
> with that id
> * after that, custom request logger asks for the className of the current
> page
> * the PageProvider doesn't have it on hand, so has to ask for the page from
> DefaultMapperContext#getPageInstance
> * that in turn locks the page again -- without unlocking it
> * so subsequent interaction with the same component blows up after a minute
> of not being able to get the lock for the page
>
> Wicket 8.5.0
>
> The stack trace
> org.apache.wicket.page.CouldNotLockPageException: Could not lock page 86.
> Attempt lasted 1 minute
> at
> org.apache.wicket.page
> .PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:168)
> at
> org.apache.wicket.page
> .PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:246)
> at
>
> org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:101)
> at
>
> org.apache.wicket.core.request.handler.PageProvider$Provision.resolve(PageProvider.java:412)
> at
>
> org.apache.wicket.core.request.handler.PageProvider.getProvision(PageProvider.java:163)
> at
>
> org.apache.wicket.core.request.handler.PageProvider.getPageInstance(PageProvider.java:171)
> at
>
> org.apache.wicket.core.request.handler.PageProvider.getPageClass(PageProvider.java:257)
> at
>
> org.apache.wicket.core.request.handler.ListenerRequestHandler.getPageClass(ListenerRequestHandler.java:108)
> at
>
> org.apache.wicket.protocol.https.HttpsMapper.getDesiredSchemeFor(HttpsMapper.java:199)
> at
>
> org.apache.wicket.protocol.https.HttpsMapper.mapRequest(HttpsMapper.java:103)
> 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
>
> com.mycompany.core.web.framework.MyRequestCycle.processRequest(MyRequestCycle.java:129)
> at
>
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
> at
>
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:275)
> at
>
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206)
> at
>
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
>
> com.mycompany.core.web.filter.ResponseHeadersFilter.doFilter(ResponseHeadersFilter.java:31)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
>
> com.mycompany.core.web.filter.MDCEnhancingFilter.lambda$doFilterInternal$0(MDCEnhancingFilter.java:29)
> at
>
> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:168)
> at
>
> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:163)
> at
>
> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:65)
> at
>
> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:34)
> at
>
> com.mycompany.core.web.filter.MDCEnhancingFilter.doFilterInternal(MDCEnhancingFilter.java:29)
> at
>
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
>
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
> at
>
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
> at
>
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
> at
>
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> at
>
> org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
> at
>
> 

Re: Java 8 access to effectively final variables/method parameters from anonymous classes

2019-08-05 Thread Martin Grigorov
Hi,

You can file a feature request to Java developers.
A compiler flag can forbid this behavior.

On Sun, Aug 4, 2019, 14:05 mscoon  wrote:

> Thomas,
>
> Thanks for the info.
>
> The domain objects not being serializable is certainly a valid option.
>
> To return to my original point, even this does not completely solve the
> issue with unintended serialization. Sure, you are going to get a
> serialization exception but this is a runtime error (hidden in the logs if
> I recall correctly) - much more cumbersome from the programmer's point of
> view compared to getting immediate visual feedback in the IDE or a compiler
> error.
>
> Also with view models you may end up again serializing a view model
> unintentionally. Granted this is usually not as bad, but still...
>
> The IntelliJ option seems to do what I want. Unfortunately we use eclipse
> and I wasn't able to find an equivalent option.
>
> Cheers
> Marios
>
>
>
> On Sun, Aug 4, 2019 at 1:07 PM Thomas Heigl  wrote:
>
> > >
> > > Would you mind to elaborate on this a bit? What do you do in your
> forms?
> > > How do you handle state there? Do you use view models that are
> > > serializable? Do you keep state in local variables and propagate it to
> > the
> > > domain object in every request after it is reloaded?
> >
> >
> > Sure.
> >
> > We use DTOs/View Models for most of our forms. We started out with
> > manipulating domain objects directly, but it caused too many headaches
> with
> > serialization and detaching/re-attaching entities etc.
> > Domain objects are only used as Wicket (loadable detachable) models when
> > the manipulation is just a single step that can be persisted to the DB
> > right away. Your ajax link is a good example. Also single-page forms
> where
> > the final "Save/Next" button persists the changes to the DB. Whenever we
> > have a multi-step process (like a wizard) for creating or editing domain
> > objects, we use custom view models.
> >
> > Thomas
> >
> > On Sun, Aug 4, 2019 at 11:53 AM mscoon  wrote:
> >
> > > Hi,
> > >
> > > If you don't mind me following up on your comment...
> > >
> > >
> > > > Personally, I rarely encounter serialization issues. None of our
> domain
> > > > objects implement Serializable. They can only be used with
> > > > LoadableDetachableModels that only store the identifier.
> > > >
> > > >>
> > > >>
> > > Would you mind to elaborate on this a bit? What do you do in your
> forms?
> > > How do you handle state there? Do you use view models that are
> > > serializable? Do you keep state in local variables and propagate it to
> > the
> > > domain object in every request after it is reloaded?
> > >
> > > We often use serializable domain objects so that keeping state on the
> > > object is simple. For example if you have an ajax link that increments
> a
> > > property of the domain object, you simply increment the property and
> rely
> > > on the object being serialized for keeping state.
> > >
> > > Cheers
> > > Marios
> > >
> >
>


Re: Best practice for session handling - high availability

2019-07-04 Thread Martin Grigorov
Hi,

On Wed, Jul 3, 2019 at 8:32 PM Manfred Bergmann 
wrote:

> I mean, don't get me wrong.
> I'm in favour of session stickiness and I can't understand why this is not
> preferred.
>
> But anyway. If we have aTCP load-balancer that switches on a timely basis
> every 200ms then session replication doesn't really work, or?
>
>
A mix of session stickiness and session replication is the recommended
approach.
Session stickiness works fine as long as the node is alive. If for some
reason the node goes down then the load balancer moves the client to
another node.
Session replication is for the fallback case when the client is redirected
to another node for any reason. As you pointed out there is no guarantee
that the replication would have finished before the next request. This is
something normal in distributed systems. The first request to the second
node may use stale session data but the next request most probably will see
the correct/replicated one.
There is a chance for bigger problems too - if the 1st request on the new
node saves the stale session then the web container will override the
replicated one and some data might get lost.
The general recommendation is to keep your sessions as light as possible,
so that they can be (de)serialized as fast as possible and avoid such
problems.


> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: WebSockets and Page serialization, oddity.

2019-07-02 Thread Martin Grigorov
Hi,

Here are the logs:

[qtp1722023916-27] INFO com.mycompany.StartWebSocketPage - onClose
[Wicket-AsyncPageStore-PageSavingThread] INFO
com.mycompany.WicketApplication - ===serialize class
com.mycompany.StartWebSocketPage 0
[qtp1722023916-16] INFO com.mycompany.WicketApplication - ---deserialize
class com.mycompany.BackgroundWorkPage 1
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onEvent other
org.apache.wicket.protocol.ws.api.event.WebSocketConnectedPayload@232150f0
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onConnect
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - Broadcasting
com.mycompany.pushmessages.WebSocketConnected@d0ec7a9
[qtp1722023916-16] INFO com.mycompany.WicketApplication - ---deserialize
class com.mycompany.BackgroundWorkPage 1
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onEvent
websocketpushpayload
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage -
onWebSocketMessage: class com.mycompany.BackgroundWorkPage,
com.mycompany.pushmessages.WebSocketConnected@d0ec7a9
[qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - received
WebSocketConnected

The problem is in WebSocketPage#onInitialize():

 add(new WebSocketBehavior() {

  @Override
  protected void onConnect(ConnectedMessage message) {
super.onConnect(message);
log.info("onConnect");

connectedMessage = message;
broadcast(new WebSocketConnected());
  }

broadcast() uses new
WebSocketPushBroadcaster(webSocketSettings.getConnectionRegistry()) to
broadcast the event.
But since the caller is #onInitialize() the current page instance is not
yet saved into the page store and the registry loads the previous version
of BackgroundWorkPage id=1 (the one stored by AjaxLink#onClick() call to
setResponsePage()).
So the looked up page instance by WebSocket's connection registry does not
see the new state (connectedMessage)


Below is a diff with the changes I've made locally to debug it:

diff --git pom.xml pom.xml
index b49937f..202d6f2 100644
--- pom.xml
+++ pom.xml
@@ -41,7 +41,7 @@
   
   
   
-   8.5.0
+   8.6.0-SNAPSHOT
   9.4.18.v20190429
   1.7.26
   4.12
@@ -63,13 +63,6 @@
   ${wicket.version}
   
-   
-   org.apache.wicket
-   wicket-native-websocket-core
-   ${wicket.version}
-   
-
-
   
   
   
   
diff --git src/main/java/com/mycompany/BackgroundWorkPage.java
src/main/java/com/mycompany/BackgroundWorkPage.java
index 76d84be..4bd7b84 100644
--- src/main/java/com/mycompany/BackgroundWorkPage.java
+++ src/main/java/com/mycompany/BackgroundWorkPage.java
@@ -23,7 +23,6 @@ public class BackgroundWorkPage extends WebSocketPage {
super(parameters);
}
-
@Override
protected void onInitialize() {
super.onInitialize();
@@ -61,7 +60,7 @@ public class BackgroundWorkPage extends WebSocketPage {
});
future.exceptionally(ex->{
- log.error("big caclulation failed", ex);
+ log.error("big calculation failed", ex);
return null;
});
diff --git src/main/java/com/mycompany/StartWebSocketPage.java
src/main/java/com/mycompany/StartWebSocketPage.java
index 56d1a99..5d1d9f6 100644
--- src/main/java/com/mycompany/StartWebSocketPage.java
+++ src/main/java/com/mycompany/StartWebSocketPage.java
@@ -1,12 +1,10 @@
package com.mycompany;
import com.mycompany.pushmessages.WebSocketConnected;
-import org.apache.wicket.Component;
-import org.apache.wicket.Page;
+
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.markup.html.link.BookmarkablePageLink;
-import org.apache.wicket.model.Model;
import org.apache.wicket.protocol.ws.api.WebSocketRequestHandler;
import org.apache.wicket.protocol.ws.api.message.IWebSocketPushMessage;
import org.apache.wicket.request.mapper.parameter.PageParameters;
@@ -39,7 +37,7 @@ public class StartWebSocketPage extends WebSocketPage {
setEnabled(isWebSocketConnected());
}
};
- btn.setOutputMarkupId(true);
+ btn.setOutputMarkupPlaceholderTag(true);
add(btn);
@@ -50,7 +48,7 @@ public class StartWebSocketPage extends WebSocketPage {
setEnabled(isWebSocketConnected());
}
};
- worksBtn.setOutputMarkupId(true);
+ worksBtn.setOutputMarkupPlaceholderTag(true);
add(worksBtn);
}
diff --git src/main/java/com/mycompany/WebSocketPage.java
src/main/java/com/mycompany/WebSocketPage.java
index bdcb47b..f6118fe 100644
--- src/main/java/com/mycompany/WebSocketPage.java
+++ src/main/java/com/mycompany/WebSocketPage.java
@@ -16,7 +16,7 @@ import org.slf4j.LoggerFactory;
public class WebSocketPage extends WebPage {
- static Logger log = LoggerFactory.getLogger(WebSocketPage.class);
+ Logger log = LoggerFactory.getLogger(getClass());
private ConnectedMessage connectedMessage = null;
@@ -70,7 +70,7 @@ public class WebSocketPage extends WebPage {
}
protected void onWebSocketMessage(WebSocketRequestHandler handler,
IWebSocketPushMessage message) {
-
+ log.info("onWebSocketMessage: {}, {}", getClass(), message);
}
diff --git 

Re: receiving email from from p.davids@hea.jetzt when posting on users@wicket.apache.org

2019-07-01 Thread Martin Grigorov
I've just unsubscribed p.davids@hea.jetzt from both dev@ and users@

On Fri, Jun 21, 2019 at 4:37 PM Sven Meier  wrote:

> Hi,
>
> that's just an automatic reply from Patrick's mailbox.
>
> @Patrick check your subscription please
>
> Have fun
> Sven
>
>
> On 21.06.19 15:01, Francois Meillet wrote:
> > When I send an email to users@wicket.apache.org  users@wicket.apache.org> I receive this automatic email from
> p.davids@hea.jetzt 
> >
> > Guten Tag,
> > die E-Mailadresse des Empfängers hat sich geändert.
> > Gern leiten wir Ihre E-Mail weiter.
> > Bitte ändern Sie für zukünftige Mails die Empfängeradresse von
> @hea.jetzt in @teemer.de.
> >
> > Freundliche Grüße
> > ARZ.dent GmbH
> >
> >
> > In english with Google Translate :
> > the recipient's e-mail address has changed.
> > We are happy to forward your e-mail.
> > Please change the recipient address of @ hea.now to @ teemer.de for
> future mails.
> >
> > Wny do I get this ?
> > Thanks
> >
> >
> > François
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Enclosure around a RefreshingView

2019-06-29 Thread Martin Grigorov
Hi,


On Fri, Jun 28, 2019 at 6:25 PM Boris Goldowsky  wrote:

> What’s the best practice for a list (built in this case with a
> RefreshingView) that has a header, which should be hidden if the list is
> empty?
>
> The most obvious would be to wrap  around the whole
> thing, but the RefreshingView is still considered visible even when empty,
> so that doesn’t work by itself.
>
> I tried adding an onConfigure method to set visibility based on the
> repeater’s size(), but the children don’t actually get added to the
> repeater until after onConfigure runs, so size() always returns 0.
>

Actually the children are added
in org.apache.wicket.markup.repeater.AbstractRepeater#onBeforeRender(), so
you need to override this one, call super.onBeforeRender() and then check
the size.

I'd recommend you to use EnclosureContainer instead of 
because the latter has many known bugs.


>
> There are ways I can brute force this of course.  But is there a clean,
> general solution?
>
> Boris
>
>


Re: caching javascript and other secondary resource files

2019-06-27 Thread Martin Grigorov
Hi,

If you don't use Wicket ResourceReference for the resource
(js/css/image/...) then Wicket will not do anything for it.
Still you have the following options:
- use a custom Servler Filter that adds the caching response headers for
any resource that does not have them. This filter should be configured
before WicketFilter in web.xml or annotations so that it wraps around it
- configure Jetty (or the frontend proxy if you use one (e.g. Apache HTTPD
or Nginx)) to set the missing headers

On Wed, Jun 26, 2019 at 10:24 PM Alan Stange  wrote:

> All,
>
> We've been using Wicket for some time now and are looking to improve the
> caching of javascript resources in our web app.   Explicit headers are
> being cached by the usual mechanism of calling
>  JavascriptHeaderItem.forReference().   The cases I'm having trouble with
> is when a javascript file is referencing another script, or a css file has
> a .png file in a url().
>
> Is there a way that I can say "All the static content in directory X (in
> the war file) and below is to be cached using the typical Wicket
> mechanisms"?
>
> As an example, pdf.js will require() pdf.worker.js, which is a 1.5MB file.
>   But I don't have control over the url being required.   How can I tell
> wicket to enable the caching headers for requests to file "pdf.worker.js"
> or "images/leftButton.png" with a 3600 second life.
>
> I've read through the docs and tried several options suggested and nothing
> seems to work.   I'm using Wicket 8.x under Jetty 9.4.19.
>
> Thank you,
>
> Alan
>


Re: improvement for wicket:for

2019-06-26 Thread Martin Grigorov
Hi Ernesto,

Please create a Pull Request and we will discuss it! Thanks!

On Wed, Jun 26, 2019 at 9:34 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> I could try to provide a PR implementing this.
>
> On Wed, Jun 26, 2019 at 9:30 AM Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Hi,
> >
> > In application I'm developing right now we have following situation.
> >
> >
> >1. A repeater consisting of a label with wicket:id "label" + some
> >complex panel with wicket:id="value"
> >2. I still would like to use wicket:for but panel value structure may
> >change a lot depending on "type" of current repeater "row". Thus, I
> can't
> >alway write wicket:for="value/xxx".
> >
> > Thus, I would like to introduce some interface to be implemented by
> > "ValuePanel" which returns a reference to that for component to which
> label
> > should point, so that I could write wicket:for="value"
> >
> > WDYT?
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>


Re: estimate time for 9.x release?

2019-06-25 Thread Martin Grigorov
In that case I vote to release 9.0.0 with the next releases of 7.x and 8.x,
no need to wait until Q3.

On Sun, Jun 23, 2019 at 11:43 AM Sven Meier  wrote:

> Hi all,
>
> I haven't had time to work an wicket-ajax-no-jquery.js, and I agree that
> we as well might try that in Wicket 10.
>
> Meanwhile I'm preparing a pull request for another modal-dialog
> proposal, but this doesn't have to delay a Wicket 9 release either.
>
> Have fun
> Sven
>
>
> On 20.06.19 11:50, Martin Grigorov wrote:
> > Hi,
> >
> > The only bigger task I am aware of is the vanilla wicket-ajax.js rewrite
> > that has been suggested by Korbinian Bachl (some time ago) and Andrew
> > Kondratev (more recently). Sven said that he wants to work on it.
> > But in my opinion this task should not stop us to release 9.0.0. The
> > vanilla impl can be introduced in a minor release too, even in 8.x, if
> the
> > APIs are preserved.
> >
> > On Thu, Jun 20, 2019 at 12:03 AM Andrea Del Bene 
> > wrote:
> >
> >> Hi,
> >>
> >> I'm happy you started to appreciate Wicket 9.x in its earliest versions!
> >> The short answer is no, there is no estimated time for 9.x to become EA.
> >> But at the moment I'm not aware of any huge feature or refactoring being
> >> in progress or even proposed. Let's hear what other developers have to
> >> say about this.
> >> Personally speaking I'm also willing to release Wicket 9.x in a short
> >> time, let's say in the Q4 of this year, after one or two more milestone
> >> releases. I also believe that the time is now ripe to provide a version
> >> of Wicket for the "post Java 8 era", which fully supports the last LTS
> JDK.
> >>
> >> Andrea.
> >>
> >> On 6/19/19 12:29 PM, rstolle wrote:
> >>> Same here! I would love to go with wicket 9 ASAP. I'm using 9.0.0-M2
> >>> on a new
> >>> project and very much appreciate the switch to java.time.Duration,
> >>> which saves
> >>> me a lot of conversions. Junit5 is also a huge plus in my opinion. So
> >>> far I did not
> >>> encounter any problems.
> >>>
> >>> Good moment to THANK THE WICKET TEAM (again) - you doing a wicked job!
> >>>
> >>> René
> >>>
> >>> Am 2019-06-19 11:30 schrieb Ernesto Reinaldo Barreiro:
> >>>> Hi,
> >>>>
> >>>> Is there an estimated time for 9.x official release? My question is
> not
> >>>> just moot: I'm keeping a parallel version of our project based on
> wicket
> >>>> 9.x. branch, and some problems I encountered on wicket 8.x. are
> >>>> easier to
> >>>> solve on 9.x. So, if release is not too far in the future I might try
> to
> >>>> convince other team members to go 9.x. for development.
> >>> -
> >>> 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: estimate time for 9.x release?

2019-06-20 Thread Martin Grigorov
On Thu, Jun 20, 2019, 23:17 Andrea Del Bene  wrote:

>
> On 6/20/19 12:46 PM, Martin Grigorov wrote:
> > On Thu, Jun 20, 2019 at 1:37 PM Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> >> Hi Martin and Andrea,
> >>
> >> Many thanks for answers. So, I will try to convince my teammates to
> switch
> >> development to 9.x branch and that way provide "life feedback"  on new
> >> developments.
> >>
> >> The only bigger task I am aware of is the vanilla wicket-ajax.js rewrite
> >>> that has been suggested by Korbinian Bachl (some time ago) and Andrew
> >>> Kondratev (more recently). Sven said that he wants to work on it.
> >>> But in my opinion this task should not stop us to release 9.0.0. The
> >>> vanilla impl can be introduced in a minor release too, even in 8.x, if
> >> the
> >>> APIs are preserved.
> >>>
> >> I also remember to have seeing some commits to get rid of wicket AJAX
> >> console. Would this also be part of 9.x?
> >>
> > Yes, this is already in M2.
> >
> >
> >> Also some proposal of new implementation of modal window? For us this is
> >> not relevant as we use bootstrap modal.
> >>
> > I am not sure about this one.
> >
> I think you are talking about this
> https://github.com/apache/wicket/pull/361


I know about the PR.
What I don't know is it's future - whether it will be merged or not.


> >> --
> >> Regards - Ernesto Reinaldo Barreiro
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Wicket 9 migration guide : No such URL

2019-06-20 Thread Martin Grigorov
Added it!
Thanks, François!

On Thu, Jun 20, 2019 at 2:02 PM Francois Meillet 
wrote:

> There is no html data for Wicket 9 migration guide
>
> https://s.apache.org/wicket9migration <
> https://s.apache.org/wicket9migration> : No such URL
>
>
> François
>
>
>
>


Re: estimate time for 9.x release?

2019-06-20 Thread Martin Grigorov
On Thu, Jun 20, 2019 at 1:37 PM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi Martin and Andrea,
>
> Many thanks for answers. So, I will try to convince my teammates to switch
> development to 9.x branch and that way provide "life feedback"  on new
> developments.
>
> The only bigger task I am aware of is the vanilla wicket-ajax.js rewrite
> > that has been suggested by Korbinian Bachl (some time ago) and Andrew
> > Kondratev (more recently). Sven said that he wants to work on it.
> > But in my opinion this task should not stop us to release 9.0.0. The
> > vanilla impl can be introduced in a minor release too, even in 8.x, if
> the
> > APIs are preserved.
> >
>
> I also remember to have seeing some commits to get rid of wicket AJAX
> console. Would this also be part of 9.x?
>

Yes, this is already in M2.


> Also some proposal of new implementation of modal window? For us this is
> not relevant as we use bootstrap modal.
>

I am not sure about this one.


>
> --
> Regards - Ernesto Reinaldo Barreiro
>


Re: estimate time for 9.x release?

2019-06-20 Thread Martin Grigorov
Hi,

The only bigger task I am aware of is the vanilla wicket-ajax.js rewrite
that has been suggested by Korbinian Bachl (some time ago) and Andrew
Kondratev (more recently). Sven said that he wants to work on it.
But in my opinion this task should not stop us to release 9.0.0. The
vanilla impl can be introduced in a minor release too, even in 8.x, if the
APIs are preserved.

On Thu, Jun 20, 2019 at 12:03 AM Andrea Del Bene 
wrote:

> Hi,
>
> I'm happy you started to appreciate Wicket 9.x in its earliest versions!
> The short answer is no, there is no estimated time for 9.x to become EA.
> But at the moment I'm not aware of any huge feature or refactoring being
> in progress or even proposed. Let's hear what other developers have to
> say about this.
> Personally speaking I'm also willing to release Wicket 9.x in a short
> time, let's say in the Q4 of this year, after one or two more milestone
> releases. I also believe that the time is now ripe to provide a version
> of Wicket for the "post Java 8 era", which fully supports the last LTS JDK.
>
> Andrea.
>
> On 6/19/19 12:29 PM, rstolle wrote:
> > Same here! I would love to go with wicket 9 ASAP. I'm using 9.0.0-M2
> > on a new
> > project and very much appreciate the switch to java.time.Duration,
> > which saves
> > me a lot of conversions. Junit5 is also a huge plus in my opinion. So
> > far I did not
> > encounter any problems.
> >
> > Good moment to THANK THE WICKET TEAM (again) - you doing a wicked job!
> >
> > René
> >
> > Am 2019-06-19 11:30 schrieb Ernesto Reinaldo Barreiro:
> >> Hi,
> >>
> >> Is there an estimated time for 9.x official release? My question is not
> >> just moot: I'm keeping a parallel version of our project based on wicket
> >> 9.x. branch, and some problems I encountered on wicket 8.x. are
> >> easier to
> >> solve on 9.x. So, if release is not too far in the future I might try to
> >> convince other team members to go 9.x. for development.
> >
> > -
> > 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: Getting access to AjaxRequestTarget

2019-06-07 Thread Martin Grigorov
Hi,

You can't do this the way you described it because Ajax is initiated by the
browser.

I can propose you three options:

1) use Ajax polling
Store the messages in some data structure in the page/panel and with the
help of AbstractAjaxTimerBehavior render the collected messages

2) WebSocket
Add WebSocketBehavior (wicket-native-websocket-javax module) and publish
IWebSocketPushMessage when you receive one from Redis.
This way it will be real time instead of batching

3) Use Server Side Events - it is similar to web sockets but
unidirectional.
You can use wicketstuff-html5 library. It has SSE support.

I would recommend you 2)

Cheers,
Martin


On Sat, Jun 8, 2019, 03:22 Roman Sery  wrote:

> Hi, I have a question about getting access to the AjaxRequestTarget outside
> the context of an ajax request.
>
> What I'm trying to do is send some javascript from the server to the
> browser from a different thread where RequestCycle.get() is not available.
> From within a WebPage,  Im using Redis pub/sub channels, to subscribe to a
> channel on page load, and when there are publications to the channel, I
> need to send some JS to the browser.
>
> psudeo code:
>
> WebPage() {
> start listening to channel a123, callback Function = onMsgPublished
> }
>
> onMsgPublished(){
>  //do something like this
>  target.appendjavascript("alert('test')");
> }
>
> Any ideas or perhaps some other way to accomplish this?
> I'm using wicket 8.4.  Thanks for any help!
>


Re: Close browser on button click

2019-06-03 Thread Martin Grigorov
Hi,

What exactly did you try ?

Try with the following:

AjaxLink closeWindowLink = new AjaxLink("closeWindow") {
  @Override public void onClick(AjaxRequestTarget target) {
 target.appendJavaScript("self.open(location, '_self').close();");
   }
}

On Mon, Jun 3, 2019 at 2:16 PM zahir.kali  wrote:

> I hade already tried this JavaScript wolution but it does not wotk. That is
> why i thinked that there is a full wicket solution like that exists on
> ModalWindow.close();
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Close browser on button click

2019-06-03 Thread Martin Grigorov
Hi,

On Mon, Jun 3, 2019 at 1:44 PM zahir.kali  wrote:

> Hi,
>
> I have a WebPage with an "Close" button. I would like to close the current
> page on pressing the close button.
>
>
>
> I tried with JavaScript function (see link
> http://blog.e-svet.si/2013/05/closing-the-browser-window-from-wicket/) but
> as the page is opened by Wicket, the browser forbids close the window by
> using "window.close();".
>
> Are there any way to do this using wicket ?
>

Wicket doesn't do anything here. It is plain JavaScript. So better search
for javascript solutions in the web.

Try with this trick: open(location, '_self').close();
This triggers re-opening of the current page with a script and then
immediately closes it.


>
> Thanks
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: 7.14.0 release

2019-05-24 Thread Martin Grigorov
The vote already started at dev@

On Fri, May 24, 2019, 18:54 Wayne W  wrote:

> Ok thanks. So soon then hopefully!!
>
> On Wed, May 22, 2019 at 3:37 PM Andrea Del Bene 
> wrote:
>
> > yes. 8.5.0 and 7.14.0 go hand in hand together :-)
> >
> > see
> >
> >
> http://apache-wicket.1842946.n4.nabble.com/Wicket-8-5-0-ready-td4682248.html
> >
> > On Wed, May 22, 2019 at 4:27 PM Wayne W 
> > wrote:
> >
> > > Hi,
> > >
> > > Is there timeframe for this release?
> > >
> > > Thanks!
> > > Wayne
> > >
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>


Re: Possible memory leak with Tomcat?

2019-05-21 Thread Martin Grigorov
Hi Wayne,

I think you are facing https://issues.apache.org/jira/browse/WICKET-6639
It is fixed in 7.14.0 and 8.4.0.

On Mon, May 20, 2019 at 6:48 PM Wayne W  wrote:

> Hi Sven,
>
> I'm having trouble replicating locally. We just saw it in production and
> then had to roll back as it was effecting customers.  The log is full of
> these:
>
> May 16, 2019 6:39:39 AM org.apache.catalina.session.StandardSession
> setAttribute
> SEVERE: Session binding event listener threw exception
> java.lang.NullPointerException
> at
>
> org.apache.wicket.page.PageStoreManager$SessionEntry.clear(PageStoreManager.java:351)
> at
>
> org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:340)
> at
>
> org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1496)
> at
>
> org.redisson.tomcat.RedissonSession.superSetAttribute(RedissonSession.java:257)
> at
>
> org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:284)
> at
>
> org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:251)
> at
> org.redisson.PubSubMessageListener.onMessage(PubSubMessageListener.java:79)
> at
>
> org.redisson.client.RedisPubSubConnection.onMessage(RedisPubSubConnection.java:78)
> at
>
> org.redisson.client.handler.CommandPubSubDecoder.lambda$enqueueMessage$0(CommandPubSubDecoder.java:184)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:745)
>
>
> Then about 2 hours later a huge number of these started to appear in the
> logs:
>
> 2019-05-16 08:52:47,851 ERROR - Wicket-PageSavingThread
>
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:434)
> 434 DiskDataStore  -
>
> /ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
> (No such file or directory)
> java.io.FileNotFoundException:
>
> /ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
> (No such file or directory)
> at java.io.RandomAccessFile.open0(Native Method)
> at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
> at java.io.RandomAccessFile.(RandomAccessFile.java:243)
> at
>
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:428)
> at
>
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:346)
> at
> org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
> at
>
> org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:355)
> at java.lang.Thread.run(Thread.java:745)
>
>
> Whats odd is that it effected some user but not others at all. When we
> rollback to 7.8.0 these go away. I'm not sure how I'm going to get the the
> bottom of this
>
>
>
>
> On Fri, May 17, 2019 at 11:03 PM Sven Meier  wrote:
>
> > Hi,
> >
> > WICKET-6564 was about applications explicitly calling #clear() on the
> > PageStoreManager.
> > This doesn't has anything to do with session expiration.
> >
> > Could you please explain what issues you're facing? A quickstart would
> > be perfect, or at least some explanations how we're able to reproduce
> > the problem.
> >
> > Regards
> > Sven
> >
> >
> > Am 17.05.19 um 13:23 schrieb Wayne W:
> > > Hello Sven,
> > >
> > > the fix you did for WICKET-6564 (
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=7665dc5;hp=3a1602d308a366e00948dbf91dbd96bc40cae167
> > )
> > > doesn't work for us. Its causing lots of issues. We use redisson for
> > > managing our sessions in tomcat, so that we can failover without
> loosing
> > > user session.
> > >
> > > When a session attribute is updated redisson calls setAttribute on the
> > > session. Looking at the code for
> > > org.apache.catalina.session.StandardSession.setAttribute I see:
> > >
> > > // Replace or add this attribute
> > >
> > >  Object unbound = attributes.put(name, value);
> > >
> > >
> > >  // Call the valueUnbound() method if necessary
> > >
> > >  *if* (notify && (unbound != *null*) && (unbound != value) &&
> > >
> > >  (unbound *instanceof* HttpSessionBindingListener)) {
> > >
> > >  *try* {
> > >
> > >  ((HttpSessionBindingListener) unbound).valueUnbound
> > >
> > >  (*new* HttpSessionBindingEvent(getSession(),
> name));
> > >
> > >  } *catch* (Throwable t) {
> > >
> > >  ExceptionUtils.*handleThrowable*(t);
> > >
> > >  manager.getContext().getLogger().error
> > >
> > >  (*sm*.getString("standardSession.bindingEvent"),
> t);
> > >
> > >  }
> > >
> > >  }
> > >
> > > The 

  1   2   3   4   5   6   7   8   9   10   >