Re: What else do we want to do before 8.0.0 final ?

2016-11-17 Thread Sebastien 
Hi Martin,

Thanks for your useful & detailed answer!

That's was actually my understanding, but the reality may be a little bit
different on some use cases leading to the LDM being loaded several times
by request cycles...
As it seems to be an issue (if demonstrated :p) rather than a known
behavior, I will try to make a quickstart and open a new thread to discuss
this...

Thanks again & best regards,
Sebastien


On Thu, Nov 17, 2016 at 12:36 AM, Martin Grigorov 
wrote:

> Hi Sebastien,
>
> What exactly is the problem ?
> LoadableDetachableModel loads its model object at first call to
> #getObject() in the request cycle and null-ifies it at #onDetach(), i.e. at
> the end of the request cycle.
>
> If a LDM is reused by several components then it will be null-ified when
> the first component detaches its model, so it will be detached when the
> other components call their #detachModel() method but this should be fine
> because at that time the model could not be used for anything because the
> rendering has finished.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>

Re: buildbot failure in on wicket-master

2016-11-17 Thread Sven Meier 

-0 for #chained(), this isn't even a verb (I know, 'of' isn't a verb either)

Regards
Sven


On 17.11.2016 12:22, Martin Grigorov wrote:

On Thu, Nov 17, 2016 at 12:13 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:


We could also opt to rename map(...) to to(...)

Model.of(account).to(Account::getPerson).to(Person::
getLastName).to(String::toUppercase)


#map() is more widely used in JVM langs



Martijn


On Thu, Nov 17, 2016 at 11:09 AM, Emond Papegaaij
 wrote:

I also think 'chained' better covers the intent. 'map' normally isn't
a read/write transformation.

Emond

On Thu, Nov 17, 2016 at 12:38 AM, Martin Grigorov 

wrote:

+1 for #chained() .

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Nov 15, 2016 at 10:07 PM, Sven Meier  wrote:


Hi,


We could rename the methods taking an IModel as first parameter to
"chained" or "from".

or "map":

 LambdaModel.map(IModel, SerializableFunction,

SerializableBiConsumer)

 LambdaModel.map(IModel, SerializableFunction)

Sven



Am 15.11.2016 um 20:52 schrieb Emond Papegaaij:


IModel.map(Function) indeed is functionally equivalent to
LambdaModel.of(IModel, Function), but its memory footprint is
significantly larger (120 vs 80 bytes). Also, there's no equivalent
method for of(IModel, Function, BiConsumer). Naturally, we can add the
corresponding method, but it will remain much less efficient. These
chained models require an additional object.

We've ran into similar problems many times at Topicus. Javac still is
very buggy when it comes to lambda type inference. IMHO the best
solution is to simply rename the methods to prevent the collisions.

We could rename the methods taking an IModel as first parameter to
"chained" or "from". Another solution would be a builder API, but I
doubt that would make the code more readable.

Best regards,
Emond

On Tue, Nov 15, 2016 at 8:06 PM, Martin Grigorov <

mgrigo...@apache.org>

wrote:


On Tue, Nov 15, 2016 at 2:51 PM, Emond Papegaaij <
emond.papega...@topicus.nl


wrote:
It seems I've hit a bug in javac:
LambdaModelTest[46,61] reference to of is ambiguous:
   of(SerializableSupplier, SerializableConsumer)
 of(IModel,   SerializableFunction)

This clearly is wrong:
IModel personNameModel = LambdaModel.of(
  () -> person.getName(),
  (name) -> person.setName(name));

The first parameter could match both SerializableSupplier and
IModel,
but the second parameter only matches SerializableConsumer.

Eclipse

has
no
problem with this and compiles the code just fine.

I guess it confuses it with SerializableFunction.

Although, I
agree it should return null to actually match.

IMO we don't
need org.apache.wicket.model.LambdaModel#of(org.apache.wicket.
model.IModel,
org.danekja.java.util.function.serializable.

SerializableFunction)

It gives the same
as org.apache.wicket.model.IModel#map(SerializableFunction
T, R>

mapper).


This now surfaces due to the change in the constructor. This testcase

used
to
call new LambdaModel(...), which had the same signature as the first
'of'.
I
had to change it to use the overloaded factory method.

I see two possible solutions:
   - Change the name of the factory methodes, so they are no longer
overloaded
(suggestions for the names are welcome)
   - Add a cast to the calling code to circumvent the bug.

IMHO both are ugly.

Best regards,
Emond

On dinsdag 15 november 2016 13:36:56 CET build...@apache.org wrote:


The Buildbot has detected a new failure on builder wicket-master

while

building wicket. Full details are available at:
https://ci.apache.org/builders/wicket-master/builds/550

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The SingleBranchScheduler scheduler named
'on-wicket-master-commit' triggered this build Build Source Stamp:


[branch


master] b40e9e1cd9ad7a9ffc63ab6c329c8d9c8b78b924 Blamelist: Emond


Papegaaij




BUILD FAILED: failed compile

Sincerely,
   -The Buildbot







--
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: buildbot failure in on wicket-master

2016-11-17 Thread Martin Grigorov 
On Thu, Nov 17, 2016 at 12:13 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> We could also opt to rename map(...) to to(...)
>
> Model.of(account).to(Account::getPerson).to(Person::
> getLastName).to(String::toUppercase)
>

#map() is more widely used in JVM langs


>
> Martijn
>
>
> On Thu, Nov 17, 2016 at 11:09 AM, Emond Papegaaij
>  wrote:
> > I also think 'chained' better covers the intent. 'map' normally isn't
> > a read/write transformation.
> >
> > Emond
> >
> > On Thu, Nov 17, 2016 at 12:38 AM, Martin Grigorov 
> wrote:
> >> +1 for #chained() .
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Tue, Nov 15, 2016 at 10:07 PM, Sven Meier  wrote:
> >>
> >>> Hi,
> >>>
> >>> >We could rename the methods taking an IModel as first parameter to
> >>> >"chained" or "from".
> >>>
> >>> or "map":
> >>>
> >>> LambdaModel.map(IModel, SerializableFunction,
> SerializableBiConsumer)
> >>>
> >>> LambdaModel.map(IModel, SerializableFunction)
> >>>
> >>> Sven
> >>>
> >>>
> >>>
> >>> Am 15.11.2016 um 20:52 schrieb Emond Papegaaij:
> >>>
>  IModel.map(Function) indeed is functionally equivalent to
>  LambdaModel.of(IModel, Function), but its memory footprint is
>  significantly larger (120 vs 80 bytes). Also, there's no equivalent
>  method for of(IModel, Function, BiConsumer). Naturally, we can add the
>  corresponding method, but it will remain much less efficient. These
>  chained models require an additional object.
> 
>  We've ran into similar problems many times at Topicus. Javac still is
>  very buggy when it comes to lambda type inference. IMHO the best
>  solution is to simply rename the methods to prevent the collisions.
> 
>  We could rename the methods taking an IModel as first parameter to
>  "chained" or "from". Another solution would be a builder API, but I
>  doubt that would make the code more readable.
> 
>  Best regards,
>  Emond
> 
>  On Tue, Nov 15, 2016 at 8:06 PM, Martin Grigorov <
> mgrigo...@apache.org>
>  wrote:
> 
> > On Tue, Nov 15, 2016 at 2:51 PM, Emond Papegaaij <
> > emond.papega...@topicus.nl
> >
> >> wrote:
> >> It seems I've hit a bug in javac:
> >> LambdaModelTest[46,61] reference to of is ambiguous:
> >>of(SerializableSupplier, SerializableConsumer)
> >>  of(IModel,   SerializableFunction)
> >>
> >> This clearly is wrong:
> >> IModel personNameModel = LambdaModel.of(
> >>  () -> person.getName(),
> >>  (name) -> person.setName(name));
> >>
> >> The first parameter could match both SerializableSupplier and
> >> IModel,
> >> but the second parameter only matches SerializableConsumer.
> Eclipse
> >> has
> >> no
> >> problem with this and compiles the code just fine.
> >>
> >> I guess it confuses it with SerializableFunction.
> > Although, I
> > agree it should return null to actually match.
> >
> > IMO we don't
> > need org.apache.wicket.model.LambdaModel#of(org.apache.wicket.
> > model.IModel,
> > org.danekja.java.util.function.serializable.
> SerializableFunction)
> > It gives the same
> > as org.apache.wicket.model.IModel#map(SerializableFunction T, R>
> > mapper).
> >
> >
> > This now surfaces due to the change in the constructor. This testcase
> >> used
> >> to
> >> call new LambdaModel(...), which had the same signature as the first
> >> 'of'.
> >> I
> >> had to change it to use the overloaded factory method.
> >>
> >> I see two possible solutions:
> >>   - Change the name of the factory methodes, so they are no longer
> >> overloaded
> >> (suggestions for the names are welcome)
> >>   - Add a cast to the calling code to circumvent the bug.
> >>
> >> IMHO both are ugly.
> >>
> >> Best regards,
> >> Emond
> >>
> >> On dinsdag 15 november 2016 13:36:56 CET build...@apache.org wrote:
> >>
> >>> The Buildbot has detected a new failure on builder wicket-master
> while
> >>> building wicket. Full details are available at:
> >>> https://ci.apache.org/builders/wicket-master/builds/550
> >>>
> >>> Buildbot URL: https://ci.apache.org/
> >>>
> >>> Buildslave for this Build: bb_slave1_ubuntu
> >>>
> >>> Build Reason: The SingleBranchScheduler scheduler named
> >>> 'on-wicket-master-commit' triggered this build Build Source Stamp:
> >>>
> >> [branch
> >>
> >>> master] b40e9e1cd9ad7a9ffc63ab6c329c8d9c8b78b924 Blamelist: Emond
> >>>
> >> Papegaaij
> >>
> >>> 
> >>>
> >>> BUILD FAILED: failed compile
> >>>
> >>> Sincerely,
> >>>   -The Buildbot
> >>>
> >>
> >>
> >>
> >>>

Re: buildbot failure in on wicket-master

2016-11-17 Thread Martijn Dashorst 
We could also opt to rename map(...) to to(...)

Model.of(account).to(Account::getPerson).to(Person::getLastName).to(String::toUppercase)

Martijn


On Thu, Nov 17, 2016 at 11:09 AM, Emond Papegaaij
 wrote:
> I also think 'chained' better covers the intent. 'map' normally isn't
> a read/write transformation.
>
> Emond
>
> On Thu, Nov 17, 2016 at 12:38 AM, Martin Grigorov  
> wrote:
>> +1 for #chained() .
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Nov 15, 2016 at 10:07 PM, Sven Meier  wrote:
>>
>>> Hi,
>>>
>>> >We could rename the methods taking an IModel as first parameter to
>>> >"chained" or "from".
>>>
>>> or "map":
>>>
>>> LambdaModel.map(IModel, SerializableFunction, SerializableBiConsumer)
>>>
>>> LambdaModel.map(IModel, SerializableFunction)
>>>
>>> Sven
>>>
>>>
>>>
>>> Am 15.11.2016 um 20:52 schrieb Emond Papegaaij:
>>>
 IModel.map(Function) indeed is functionally equivalent to
 LambdaModel.of(IModel, Function), but its memory footprint is
 significantly larger (120 vs 80 bytes). Also, there's no equivalent
 method for of(IModel, Function, BiConsumer). Naturally, we can add the
 corresponding method, but it will remain much less efficient. These
 chained models require an additional object.

 We've ran into similar problems many times at Topicus. Javac still is
 very buggy when it comes to lambda type inference. IMHO the best
 solution is to simply rename the methods to prevent the collisions.

 We could rename the methods taking an IModel as first parameter to
 "chained" or "from". Another solution would be a builder API, but I
 doubt that would make the code more readable.

 Best regards,
 Emond

 On Tue, Nov 15, 2016 at 8:06 PM, Martin Grigorov 
 wrote:

> On Tue, Nov 15, 2016 at 2:51 PM, Emond Papegaaij <
> emond.papega...@topicus.nl
>
>> wrote:
>> It seems I've hit a bug in javac:
>> LambdaModelTest[46,61] reference to of is ambiguous:
>>of(SerializableSupplier, SerializableConsumer)
>>  of(IModel,   SerializableFunction)
>>
>> This clearly is wrong:
>> IModel personNameModel = LambdaModel.of(
>>  () -> person.getName(),
>>  (name) -> person.setName(name));
>>
>> The first parameter could match both SerializableSupplier and
>> IModel,
>> but the second parameter only matches SerializableConsumer. Eclipse
>> has
>> no
>> problem with this and compiles the code just fine.
>>
>> I guess it confuses it with SerializableFunction.
> Although, I
> agree it should return null to actually match.
>
> IMO we don't
> need org.apache.wicket.model.LambdaModel#of(org.apache.wicket.
> model.IModel,
> org.danekja.java.util.function.serializable.SerializableFunction)
> It gives the same
> as org.apache.wicket.model.IModel#map(SerializableFunction
> mapper).
>
>
> This now surfaces due to the change in the constructor. This testcase
>> used
>> to
>> call new LambdaModel(...), which had the same signature as the first
>> 'of'.
>> I
>> had to change it to use the overloaded factory method.
>>
>> I see two possible solutions:
>>   - Change the name of the factory methodes, so they are no longer
>> overloaded
>> (suggestions for the names are welcome)
>>   - Add a cast to the calling code to circumvent the bug.
>>
>> IMHO both are ugly.
>>
>> Best regards,
>> Emond
>>
>> On dinsdag 15 november 2016 13:36:56 CET build...@apache.org wrote:
>>
>>> The Buildbot has detected a new failure on builder wicket-master while
>>> building wicket. Full details are available at:
>>> https://ci.apache.org/builders/wicket-master/builds/550
>>>
>>> Buildbot URL: https://ci.apache.org/
>>>
>>> Buildslave for this Build: bb_slave1_ubuntu
>>>
>>> Build Reason: The SingleBranchScheduler scheduler named
>>> 'on-wicket-master-commit' triggered this build Build Source Stamp:
>>>
>> [branch
>>
>>> master] b40e9e1cd9ad7a9ffc63ab6c329c8d9c8b78b924 Blamelist: Emond
>>>
>> Papegaaij
>>
>>> 
>>>
>>> BUILD FAILED: failed compile
>>>
>>> Sincerely,
>>>   -The Buildbot
>>>
>>
>>
>>
>>>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Make IXyzListener's methods default with empty body

2016-11-17 Thread Tobias Soloschenko 
+1

kind regards

Tobias

> Am 17.11.2016 um 11:07 schrieb Emond Papegaaij :
> 
> +1
> 
>> On Thu, Nov 17, 2016 at 12:37 AM, Martin Grigorov  
>> wrote:
>> Yes. This discussion is about exactly what I propose.
>> I like the idea.
>> 
>> Other opinions ?
>> 
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>> 
>>> On Wed, Nov 16, 2016 at 11:00 AM, Sven Meier  wrote:
>>> 
>>> Here's a discussion about on this topic:
>>> 
>>> http://stackoverflow.com/questions/32440873/is-it-ok-to-add-
>>> default-implementations-to-methods-of-an-interface-which-represe
>>> 
>>> It's something new to get used to, but +1 for getting rid of all adapter
>>> classes.
>>> 
>>> Have fun
>>> Sven
>>> 
>>> 
>>> 
 Am 15.11.2016 um 21:53 schrieb Martin Grigorov:
 
 What do you think about making methods like
 IApplicationListener#onAfterInitialized() a 'default' method with empty
 body ? Same for #onBeforeDestroyed() and all other similar methods in
 other
 classes
 
 This way there won't be a need to create adapters like
 AjaxRequestTarger.AbstractListener and there won't be a need to implement
 methods in which the application is not interested in like I do below with
 #onAfterInitialized().
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Tue, Nov 15, 2016 at 9:43 PM,  wrote:
 
 Repository: wicket
> Updated Branches:
>   refs/heads/master 498f185ed -> 21837bccc
> 
> 
> WICKET-6277 Broadcasting ClosedMessage about the JSR 356 WebSocket
> connection after the container was turned off
> 
> Do not notify the websocket behaviors/resources when the application is
> already destroyed.
> Add non-null checks for IPageStore in PageStoreManager.
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/21837bcc
> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/21837bcc
> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/21837bcc
> 
> Branch: refs/heads/master
> Commit: 21837bcccd78bb529c2f33fbcd947ff5b9732739
> Parents: 498f185
> Author: Martin Tzvetanov Grigorov 
> Authored: Tue Nov 15 21:41:26 2016 +0100
> Committer: Martin Tzvetanov Grigorov 
> Committed: Tue Nov 15 21:41:26 2016 +0100
> 
> --
>  .../apache/wicket/page/PageStoreManager.java| 20 +++---
>  .../protocol/ws/javax/WicketEndpoint.java   | 40
> +++-
>  2 files changed, 53 insertions(+), 7 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/wicket/blob/
> 21837bcc/wicket-core/src/main/java/org/apache/wicket/page/
> PageStoreManager.java
> --
> diff --git a/wicket-core/src/main/java/org/apache/wicket/page/PageStore
> Manager.java
> b/wicket-core/src/main/java/org/apache/wicket/page/PageStoreManager.java
> index 9585669..88bffa4 100644
> --- a/wicket-core/src/main/java/org/apache/wicket/page/
> PageStoreManager.java
> +++ b/wicket-core/src/main/java/org/apache/wicket/page/
> PageStoreManager.java
> @@ -167,10 +167,14 @@ public class PageStoreManager extends
> AbstractPageManager
> sessionCache = new ArrayList<>();
> }
> 
> -   for (Object o : afterReadObject)
> +   final IPageStore pageStore = getPageStore();
> +   if (pageStore != null)
> {
> -   IManageablePage page =
> getPageStore().convertToPage(o);
> -   addPage(page);
> +   for (Object o : afterReadObject)
> +   {
> +   IManageablePage page =
> pageStore.convertToPage(o);
> +   addPage(page);
> +   }
> }
> 
> afterReadObject = null;
> @@ -189,10 +193,11 @@ public class PageStoreManager extends
> AbstractPageManager
> convertAfterReadObjects();
> }
> 
> +   IManageablePage page = null;
> // try to find page with same id
> if (sessionCache != null)
> {
> -

Re: buildbot failure in on wicket-master

2016-11-17 Thread Emond Papegaaij 
I also think 'chained' better covers the intent. 'map' normally isn't
a read/write transformation.

Emond

On Thu, Nov 17, 2016 at 12:38 AM, Martin Grigorov  wrote:
> +1 for #chained() .
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Nov 15, 2016 at 10:07 PM, Sven Meier  wrote:
>
>> Hi,
>>
>> >We could rename the methods taking an IModel as first parameter to
>> >"chained" or "from".
>>
>> or "map":
>>
>> LambdaModel.map(IModel, SerializableFunction, SerializableBiConsumer)
>>
>> LambdaModel.map(IModel, SerializableFunction)
>>
>> Sven
>>
>>
>>
>> Am 15.11.2016 um 20:52 schrieb Emond Papegaaij:
>>
>>> IModel.map(Function) indeed is functionally equivalent to
>>> LambdaModel.of(IModel, Function), but its memory footprint is
>>> significantly larger (120 vs 80 bytes). Also, there's no equivalent
>>> method for of(IModel, Function, BiConsumer). Naturally, we can add the
>>> corresponding method, but it will remain much less efficient. These
>>> chained models require an additional object.
>>>
>>> We've ran into similar problems many times at Topicus. Javac still is
>>> very buggy when it comes to lambda type inference. IMHO the best
>>> solution is to simply rename the methods to prevent the collisions.
>>>
>>> We could rename the methods taking an IModel as first parameter to
>>> "chained" or "from". Another solution would be a builder API, but I
>>> doubt that would make the code more readable.
>>>
>>> Best regards,
>>> Emond
>>>
>>> On Tue, Nov 15, 2016 at 8:06 PM, Martin Grigorov 
>>> wrote:
>>>
 On Tue, Nov 15, 2016 at 2:51 PM, Emond Papegaaij <
 emond.papega...@topicus.nl

> wrote:
> It seems I've hit a bug in javac:
> LambdaModelTest[46,61] reference to of is ambiguous:
>of(SerializableSupplier, SerializableConsumer)
>  of(IModel,   SerializableFunction)
>
> This clearly is wrong:
> IModel personNameModel = LambdaModel.of(
>  () -> person.getName(),
>  (name) -> person.setName(name));
>
> The first parameter could match both SerializableSupplier and
> IModel,
> but the second parameter only matches SerializableConsumer. Eclipse
> has
> no
> problem with this and compiles the code just fine.
>
> I guess it confuses it with SerializableFunction.
 Although, I
 agree it should return null to actually match.

 IMO we don't
 need org.apache.wicket.model.LambdaModel#of(org.apache.wicket.
 model.IModel,
 org.danekja.java.util.function.serializable.SerializableFunction)
 It gives the same
 as org.apache.wicket.model.IModel#map(SerializableFunction
 mapper).


 This now surfaces due to the change in the constructor. This testcase
> used
> to
> call new LambdaModel(...), which had the same signature as the first
> 'of'.
> I
> had to change it to use the overloaded factory method.
>
> I see two possible solutions:
>   - Change the name of the factory methodes, so they are no longer
> overloaded
> (suggestions for the names are welcome)
>   - Add a cast to the calling code to circumvent the bug.
>
> IMHO both are ugly.
>
> Best regards,
> Emond
>
> On dinsdag 15 november 2016 13:36:56 CET build...@apache.org wrote:
>
>> The Buildbot has detected a new failure on builder wicket-master while
>> building wicket. Full details are available at:
>> https://ci.apache.org/builders/wicket-master/builds/550
>>
>> Buildbot URL: https://ci.apache.org/
>>
>> Buildslave for this Build: bb_slave1_ubuntu
>>
>> Build Reason: The SingleBranchScheduler scheduler named
>> 'on-wicket-master-commit' triggered this build Build Source Stamp:
>>
> [branch
>
>> master] b40e9e1cd9ad7a9ffc63ab6c329c8d9c8b78b924 Blamelist: Emond
>>
> Papegaaij
>
>> 
>>
>> BUILD FAILED: failed compile
>>
>> Sincerely,
>>   -The Buildbot
>>
>
>
>
>>

Re: Make IXyzListener's methods default with empty body

2016-11-17 Thread Emond Papegaaij 
+1

On Thu, Nov 17, 2016 at 12:37 AM, Martin Grigorov  wrote:
> Yes. This discussion is about exactly what I propose.
> I like the idea.
>
> Other opinions ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Nov 16, 2016 at 11:00 AM, Sven Meier  wrote:
>
>> Here's a discussion about on this topic:
>>
>> http://stackoverflow.com/questions/32440873/is-it-ok-to-add-
>> default-implementations-to-methods-of-an-interface-which-represe
>>
>> It's something new to get used to, but +1 for getting rid of all adapter
>> classes.
>>
>> Have fun
>> Sven
>>
>>
>>
>> Am 15.11.2016 um 21:53 schrieb Martin Grigorov:
>>
>>> What do you think about making methods like
>>> IApplicationListener#onAfterInitialized() a 'default' method with empty
>>> body ? Same for #onBeforeDestroyed() and all other similar methods in
>>> other
>>> classes
>>>
>>> This way there won't be a need to create adapters like
>>> AjaxRequestTarger.AbstractListener and there won't be a need to implement
>>> methods in which the application is not interested in like I do below with
>>> #onAfterInitialized().
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Tue, Nov 15, 2016 at 9:43 PM,  wrote:
>>>
>>> Repository: wicket
 Updated Branches:
refs/heads/master 498f185ed -> 21837bccc


 WICKET-6277 Broadcasting ClosedMessage about the JSR 356 WebSocket
 connection after the container was turned off

 Do not notify the websocket behaviors/resources when the application is
 already destroyed.
 Add non-null checks for IPageStore in PageStoreManager.


 Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
 Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/21837bcc
 Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/21837bcc
 Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/21837bcc

 Branch: refs/heads/master
 Commit: 21837bcccd78bb529c2f33fbcd947ff5b9732739
 Parents: 498f185
 Author: Martin Tzvetanov Grigorov 
 Authored: Tue Nov 15 21:41:26 2016 +0100
 Committer: Martin Tzvetanov Grigorov 
 Committed: Tue Nov 15 21:41:26 2016 +0100

 --
   .../apache/wicket/page/PageStoreManager.java| 20 +++---
   .../protocol/ws/javax/WicketEndpoint.java   | 40
 +++-
   2 files changed, 53 insertions(+), 7 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/wicket/blob/
 21837bcc/wicket-core/src/main/java/org/apache/wicket/page/
 PageStoreManager.java
 --
 diff --git a/wicket-core/src/main/java/org/apache/wicket/page/PageStore
 Manager.java
 b/wicket-core/src/main/java/org/apache/wicket/page/PageStoreManager.java
 index 9585669..88bffa4 100644
 --- a/wicket-core/src/main/java/org/apache/wicket/page/
 PageStoreManager.java
 +++ b/wicket-core/src/main/java/org/apache/wicket/page/
 PageStoreManager.java
 @@ -167,10 +167,14 @@ public class PageStoreManager extends
 AbstractPageManager
  sessionCache = new ArrayList<>();
  }

 -   for (Object o : afterReadObject)
 +   final IPageStore pageStore = getPageStore();
 +   if (pageStore != null)
  {
 -   IManageablePage page =
 getPageStore().convertToPage(o);
 -   addPage(page);
 +   for (Object o : afterReadObject)
 +   {
 +   IManageablePage page =
 pageStore.convertToPage(o);
 +   addPage(page);
 +   }
  }

  afterReadObject = null;
 @@ -189,10 +193,11 @@ public class PageStoreManager extends
 AbstractPageManager
  convertAfterReadObjects();
  }

 +   IManageablePage page = null;
  // try to find page with same id
  if (sessionCache != null)
  {
 -   IManageablePage page = findPage(id);
 +   page = findPage(id);
  if (page != null)
  {
  return page;