Re: Proposal to remove IDetachable from IModel hierarchy

[Pedro Santos]

Hi Emond,

> It is an integral part of the lifecycle of IModel

Most of the models in Wicket and Wicketstuff have no detach logic, hardly
an integral part.

> One could say that the sole purpose of the detach traversal is to detach
all models.

Wicket detaches all components in the page in pre-order and each component
is responsible to detach any detachable object used during the request, not
only models. Just to be clear, no changes being proposed here.

> Changing this part of the API will break the world. All
> implementations of IModel need to either implement IDetachable or
> remove detach().

This change is not being proposed to Wicket 7, to break the world is an
exaggeration.

> All calls to detach() need to be guarded with an
> instanceof check and a cast. You can be sure many users will be very
> upset with such a change.

They didn't get upset by adding a bunch of empty detach methods in their
models that weren't detachable. It will be trick to say how sad or upset
users will be. Also I explained in my reply to Sven how this instanceof can
be abstracted from the user.

> What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
> detach and have it do nothing when nothing needs to be done?

If a logic inside the component depends on the model being detachable or
not, it wouldn't be able to determine it testing the current interface. No
specific usecase in mind.

Pedro Santos

On Wed, Mar 29, 2017 at 2:53 PM, Emond Papegaaij 
wrote:

> Hi Pedro,
>
> I fail to see why it is a problem for IModel to be IDetachable. It is
> an integral part of the lifecycle of IModel. One could say that the
> sole purpose of the detach traversal is to detach all models. A model
> knows how to retrieve data, update data and to detach its internal
> representation from the backend for future request handling. A model
> that does not require special processing to detach, simply omits this
> method: it has a default, empty implementation. Calling this empty
> method is cheap and likely to cause problems.
>
> Changing this part of the API will break the world. All
> implementations of IModel need to either implement IDetachable or
> remove detach(). All calls to detach() need to be guarded with an
> instanceof check and a cast. You can be sure many users will be very
> upset with such a change.
>
> What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
> detach and have it do nothing when nothing needs to be done?
>
> Best regards,
> Emond
>
> On Wed, Mar 29, 2017 at 6:12 PM, Pedro Santos  wrote:
> > From user's perspective this is a symmetrical problem. This sadness is
> > carried over to an user in the other side, in need to avoid any detach
> > logic or processing in his component or model if the target model isn't
> > detachable. Right know he would have to come up with his own marker e.g.:
> > IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose
> the
> > side that is not semantically wrong.
> >
> > Also this instanceof test is more common for us, Wicket's core
> developers.
> > For the final user the AbstractWrapModel class and a helper function (I
> can
> > propose one) should hide this complexity. We can't judge how sad it's for
> > the final user base on how common it's for *us* to have this instanceof
> > check, and without even try to abstract this complexity.
> >
> > Yes, I think this fix should be carried over to FeedbackMessage,
> > ICellPopulator and IDataProvider.
> >
> >>The current solution - even if semantically wrong - is simpler.
> >
> > It's simpler only because of the instanceof test that should be
> abstracted
> > from the user?
> >
> >
> > Pedro Santos
> >
> > On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier  wrote:
> >
> >> Hi Pedro,
> >>
> >> for Wicket your changes look fine.
> >>
> >> But I have an objection from a user's perspective:
> >> If I hold a reference to a model (in a component or another wrapping
> >> model), I'll always have to check the instance and do a cast before
> >> detaching it:
> >>
> >> class MyComponent {
> >>   private IModel foo;
> >>
> >>   @Override
> >>   public void detachModels() {
> >> if (foo instanceof IDetachable) {
> >>   ((IDetachable)foo).detach();
> >> }
> >>   }
> >> }
> >>
> >> Sad :/.
> >>
> >> Furthermore what about FeedbackMessage, ICellPopulator and
> IDataProvider?
> >> Will their implementations no longer be forced to implement IDetachable
> too?
> >>
> >> IMHO your missing an important aspect of IDetachable: yes, many
> >> implementations really don't need to detach anything. But many places
> >> *have* to detach these objects, *iff* they are detachable.
> >> The current solution - even if semantically wrong - is simpler.
> >>
> >> Best regards
> >> Sven
> >>
> >>
> >>
> >> On 29.03.2017 15:52, Pedro Santos wrote:
> >>
> >>> Hi team,
> >>>
> >>> Not every model is detachable, but right now all 

[ANNOUNCE] WicketStuff 8.0.0-M5 Released

[Martin Grigorov]

WicketStuff core 8.0.0-M5 based on Apache Wicket 8.0.0-M5 is released and
soon will be available at Maven Central!

The changelog since 8.0.0-M4 is:

Maxim Solodovnik (8):
  org.json import is replaced with com.github.openjson, build is
partially fixed
  org.json import is replaced with com.github.openjson, build is
partially fixed
  org.json import is replaced with com.github.openjson, build is
partially fixed
  org.json import is replaced with com.github.openjson, build is
partially fixed
  org.json import is replaced with com.github.openjson, build is fixed
  Code clean-up, deque overflow is fixed
  Fixes Issue #583: Browserid module is removed from the build due to
service is discontinued
  More work on Issue #583: module is removed

Andrea Del Bene (6):
  [async-tasks] Merge pull request #564 from andrel/fix-stop-behavior
  [wicket-rest] Removed reference to GsonRestResource
  Merge pull request #581 from heapifyman/issue-574-tinymce4-
localization
  Issue #582
  [wicketstuff-lambda-components] Added module
wicketstuff-lambda-components.
  [wicketstuff-lambda-components] Added README.md

heapifyman (5):
  [tinymce4] proposed fix for  574
  [tinymce4] update for #574
  [tinymce4] Merge branch 'master' into issue-574-tinymce4-localization
  [tinymce4] fix indentation
  [tinymce4] apply wicket-style formatting

Martin Tzvetanov Grigorov (4):
  Update Scala to 2.12.1, SLF4j to 1.7.22, Logback to 1.1.10 and
Objenesis to 2.5
  [clipboard.js] Update to 1.6.0
  Dependency updates: Wicket -> 8.0.0-M5, SLF4J -> 1.7.25, Logback ->
1.2.2, Jackson -> 2.8.7, Javassist -> 3.21.0
  Release 8.0.0-M5

andlin (3):
  Revert "Code better formatted and variable name correction"
  Revert "improve solution to check for unbinded behavior"
  Fix randomly failing tests.

Sven Meier (2):
  [lambda-model] replaced deprecated AbstractReadOnlyModel with IModel
  [lambda-model] Merge branch 'ageery-deprecate-pre-wicket-
8-lambda-functionality'

JoachimRohde (1):
  [GMap3] Fixed #584 - version clash of the Jackson library

ageery (1):
  [lambda-model] Added @deprecated and @see Javadocs for superceded
functionality.

chrisly42 (1):
  [inmethod-grid] Fix for Issue #570: InMethod-Grid:
AbstractPageableView does not allow resetting of total count (#576)


The WicketStuff team!

[ANNOUNCE] Apache Wicket 8.0.0-M5 Released

[Andrea Del Bene]

The Apache Wicket PMC is proud to announce Apache Wicket 8.0.0-M5!

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.0.0-M5


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/8.0.0-M5
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/8.0.0-M5/binaries

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.0.0-M5.zip:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVplUP/18Y2qXGdgnsMhn3j7T2yEuS
uzgxs8ZlMBG+OzMp+b/Sewocppfcc5uWEinMfLWcjU0Gplk9y9fqC+IhUreWbI/Y
VSnykzwkYWzbxL975bgXBimiindcOLBf5VAnaw5DaN5I8o2csa6Na8WQvhTjIV87
9/8unxIIoJvmPt/eqXms/xVZwC52ggbYNsRExRa+bfFqaHPH0udfvBUkYW5jdK5y
PiBFFF1H3P9SFDnVezp++7h7uZBNg2trfZUhxDUUNxu169hUqpCYEmWXE/Suby1c
1vBVWzaICJf+cStSVD8LRibLD8yp4UriyeQj5yD9puA4HpoONdOkb0+9EtBrr6U9
7JC0s3sUP8WPqYawPRW7FWa+Lkfm4YHyKp0N4uwP4Q5i4FQQOJcGKQCJGxp92cqC
b0Ww2xjgJi+z24mDq9r3lICiL3IAbYe9gbFKm6c2S9wvtaeyUTF4Zi+Cgk1zk/qR
34MMXqD1wY4HxEriBsHA94WROCMlKVRXIc41NZE/ZNxdiXqTHaNEctWo88V9EElx
t7ov/uwKVlMvFxMBOYFr9p/FAjH50zWTbx/asV/Fz0NdWDE79++Bd2OnUahFB9wh
wXFZDo6iB7s6zh08hK68TTRGdDrZ7BGIgBMHR40tAqiJML6821hcKaNfpdemqptv
SBxLZI3zI4Fc81w7jnrv
=gYYk
-END PGP SIGNATURE-

Signature for apache-wicket-8.0.0-M5.tar.gz:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVK2wP+gM11Ve4SKnavA+VH0w9u1HK
kKFHMx+nMX2uQ9lsSwbR9D0Ql0v03lctlMsr8LnzNTazZPiLrcilFKGrzlGZOAx8
XXu1+9oPKPAUTvrpvXUmKXSqsm5XLuC74OP2w3rwV82hnIfs/CKs32X1hBRe1c+u
S+EtBWZSJKI8qAOdZEq+ZvoVGEeUGFosPhfF98rOkleUXP9LfSppYwlHO1/8s9PE
3Fl1CR9smDRfNOhVwv2GvlfrH8D4bF31doQUZ2yxdWlnKRYOp1gVzUf91jZ2V2kv
oUFQb673qP3TptyH6AwFjuZ8WHXpsbo2BAXtCKCP+6cqGczKZ+ntv2IKiVQwr1lX
LTfUey+ZXfVWq/xkF3SCTzO7BFEp91mupqWljR/YPs3zhOT5dyGArX0XcbRiz+rZ
yETYFlw9mmpwrZkjudfyfgZic2pcesUZOgwnq0F/BW5vuVYgFCWRFOvKChAM2G8v
Rcsh2rV/T2/U+pIbqwCPcgOSN1OUZ4siUGSKC1ELSdIcCtfqgP3rft9tvZbmWIiv
sGFJwZBLDIOqWzeyLxE5QvWtR9aIybqE9mJ4Y9Y2PPNJfNJsn1s/pD5qnvO3d6Ym
+7LztPmkS4OQeVHqY9e9EnCdd9ndTe0aLHzU3kZ51oTRPwLLb6Wztxily0V15PII
kN/0C0NMZ6Sy0Q5QgynI
=ci2t
-END PGP SIGNATURE-



CHANGELOG for 8.0.0-M5:


** Bug

* [WICKET-6317] - AuthenticatedWebSession#signOut() calls twice 
after session invalidation
* [WICKET-6319] - AutoCompleteTextField: popup is hidden when 
clicking on scrollbar in IE

* [WICKET-6329] - org.json migration issue
* [WICKET-6337] - Wrong class type in PageAccessSynchronizer
* [WICKET-6340] - The Ajax reponse of an AjaxSubmitButton creates 
invalid XHTML markup for multipart forms

* [WICKET-6342] - Wrong baseUrl in BaseWebSocketBehavior

** Improvement

* [WICKET-6212] - CheckChoice / add a getAdditionalAttributes() 
also for -tag
* [WICKET-6265] - Make it possible to authorize component 
instantiations both with OR and AND rules

* [WICKET-6328] - Add 'pathInfo' to ForwardAttributes
* [WICKET-6333] - Use onConfigure() to set the visibility of 
ExportToolbar instead of overriding isVisible()
* [WICKET-6334] - WicketObjects#sizeof() and #cloneObject() should 
not use IObjectCheckers

* [WICKET-6335] - tree.Node calls virtual methods from constructor
* [WICKET-6336] - Add #removePage(IManageablePage) to IPageManager
* [WICKET-6343] - Add hook method for exception handling to 
StatelessChecker
* [WICKET-6345] - Check for non-null PushBuilder before trying to 
use it


** New Feature

* [WICKET-6286] - Would be good to have AjaxDownload available out 
of the box

Re: Proposal to remove IDetachable from IModel hierarchy

[Martin Grigorov]

Fully agree with Emond!
As a user I will hate such kind of change.
Several years ago this change might be OKish, but now with Java 8 default
methods it would be insane to break everyone's code when default methods
make it invisible.
Until 7.x I'd have to add empty impl for detach() when I don't need it.
With Wicket 8.x I won't bother at all!

Is your branch complete ? I see no changes in wicket-examples. Maybe it is
because several months ago I've cleaned all empty impls of #detach(). I did
it because I did it. It was compiling even without removing them. But with
your changes everyone will have to go all over his/her code and fix it!
If you remember the days when people migrated from 1.4.x to 1.5.x, or from
1.5.x to 6.x - many users sent a lot of negative feedback for such kind of
changes. Changes without deprecation cycle and changes without real benefit
from user point of view.

-1

On Wed, Mar 29, 2017 at 7:53 PM, Emond Papegaaij 
wrote:

> Hi Pedro,
>
> I fail to see why it is a problem for IModel to be IDetachable. It is
> an integral part of the lifecycle of IModel. One could say that the
> sole purpose of the detach traversal is to detach all models. A model
> knows how to retrieve data, update data and to detach its internal
> representation from the backend for future request handling. A model
> that does not require special processing to detach, simply omits this
> method: it has a default, empty implementation. Calling this empty
> method is cheap and likely to cause problems.
>
> Changing this part of the API will break the world. All
> implementations of IModel need to either implement IDetachable or
> remove detach(). All calls to detach() need to be guarded with an
> instanceof check and a cast. You can be sure many users will be very
> upset with such a change.
>
> What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
> detach and have it do nothing when nothing needs to be done?
>
> Best regards,
> Emond
>
> On Wed, Mar 29, 2017 at 6:12 PM, Pedro Santos  wrote:
> > From user's perspective this is a symmetrical problem. This sadness is
> > carried over to an user in the other side, in need to avoid any detach
> > logic or processing in his component or model if the target model isn't
> > detachable. Right know he would have to come up with his own marker e.g.:
> > IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose
> the
> > side that is not semantically wrong.
> >
> > Also this instanceof test is more common for us, Wicket's core
> developers.
> > For the final user the AbstractWrapModel class and a helper function (I
> can
> > propose one) should hide this complexity. We can't judge how sad it's for
> > the final user base on how common it's for *us* to have this instanceof
> > check, and without even try to abstract this complexity.
> >
> > Yes, I think this fix should be carried over to FeedbackMessage,
> > ICellPopulator and IDataProvider.
> >
> >>The current solution - even if semantically wrong - is simpler.
> >
> > It's simpler only because of the instanceof test that should be
> abstracted
> > from the user?
> >
> >
> > Pedro Santos
> >
> > On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier  wrote:
> >
> >> Hi Pedro,
> >>
> >> for Wicket your changes look fine.
> >>
> >> But I have an objection from a user's perspective:
> >> If I hold a reference to a model (in a component or another wrapping
> >> model), I'll always have to check the instance and do a cast before
> >> detaching it:
> >>
> >> class MyComponent {
> >>   private IModel foo;
> >>
> >>   @Override
> >>   public void detachModels() {
> >> if (foo instanceof IDetachable) {
> >>   ((IDetachable)foo).detach();
> >> }
> >>   }
> >> }
> >>
> >> Sad :/.
> >>
> >> Furthermore what about FeedbackMessage, ICellPopulator and
> IDataProvider?
> >> Will their implementations no longer be forced to implement IDetachable
> too?
> >>
> >> IMHO your missing an important aspect of IDetachable: yes, many
> >> implementations really don't need to detach anything. But many places
> >> *have* to detach these objects, *iff* they are detachable.
> >> The current solution - even if semantically wrong - is simpler.
> >>
> >> Best regards
> >> Sven
> >>
> >>
> >>
> >> On 29.03.2017 15:52, Pedro Santos wrote:
> >>
> >>> Hi team,
> >>>
> >>> Not every model is detachable, but right now all models extends from
> >>> IDetachable because this contract is forced to any implementation for
> >>> IModel.
> >>>
> >>> The only way users have to communicate their model isn't detachable,
> for
> >>> their own purpose, is by creating their own mechanism; but I think
> >>> IDetachable interface should serve its purpose and to mark / be
> extended
> >>> by
> >>> detachable models, like documented in its own javadoc.
> >>>
> >>> I did the changes necessary for this improvement in the branch
> >>> 'not-detachable' at 

Re: [VOTE] Release Apache Wicket 8.0.0-M5

[Andrea Del Bene]

This vote passes with 6 votes plus 1 non-binding

Thank you!

On 29/03/2017 12:03, Andrea Del Bene wrote:

+1 release 8.0.0-M5

Randomly tested example from war file.

On Tue, Mar 28, 2017 at 4:29 PM, Sven Meier > wrote:


+1 release 8.0.0-M5

Tested build artifact and our main application.

Thanks
Sven



On 25.03.2017 16 :32, Andrea Del Bene wrote:

This is a vote to release Apache Wicket 8.0.0-M5

Please download the source distributions found in our staging area
linked below.

I have included the signatures for both the source archives.
This vote
lasts for 72 hours minimum.

[ ] Yes, release Apache Wicket 8.0.0-M5
[ ] No, don't release Apache Wicket 8.0.0-M5, because ...

Distributions, changelog, keys and signatures can be found at:

https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M5


Staging repository:

https://repository.apache.org/content/repositories/orgapachewicket-1084



The binaries are available in the above link, as are a staging
repository for Maven. Typically the vote is on the source, but
should
you find a problem with one of the binaries, please let me
know, I can
re-roll them some way or the other.

Staging git repository data:

Repository:  g...@github.com:bitstorm/wicket.git
Branch:  build/wicket-8.0.0-M5
Release tag: rel/wicket-8.0.0-M5




The signatures for the source release artefacts:


Signature for apache-wicket-8.0.0-M5.zip:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVplUP/18Y2qXGdgnsMhn3j7T2yEuS
uzgxs8ZlMBG+OzMp+b/Sewocppfcc5uWEinMfLWcjU0Gplk9y9fqC+IhUreWbI/Y
VSnykzwkYWzbxL975bgXBimiindcOLBf5VAnaw5DaN5I8o2csa6Na8WQvhTjIV87
9/8unxIIoJvmPt/eqXms/xVZwC52ggbYNsRExRa+bfFqaHPH0udfvBUkYW5jdK5y
PiBFFF1H3P9SFDnVezp++7h7uZBNg2trfZUhxDUUNxu169hUqpCYEmWXE/Suby1c
1vBVWzaICJf+cStSVD8LRibLD8yp4UriyeQj5yD9puA4HpoONdOkb0+9EtBrr6U9
7JC0s3sUP8WPqYawPRW7FWa+Lkfm4YHyKp0N4uwP4Q5i4FQQOJcGKQCJGxp92cqC
b0Ww2xjgJi+z24mDq9r3lICiL3IAbYe9gbFKm6c2S9wvtaeyUTF4Zi+Cgk1zk/qR
34MMXqD1wY4HxEriBsHA94WROCMlKVRXIc41NZE/ZNxdiXqTHaNEctWo88V9EElx
t7ov/uwKVlMvFxMBOYFr9p/FAjH50zWTbx/asV/Fz0NdWDE79++Bd2OnUahFB9wh
wXFZDo6iB7s6zh08hK68TTRGdDrZ7BGIgBMHR40tAqiJML6821hcKaNfpdemqptv
SBxLZI3zI4Fc81w7jnrv
=gYYk
-END PGP SIGNATURE-

Signature for apache-wicket-8.0.0-M5.tar.gz:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVK2wP+gM11Ve4SKnavA+VH0w9u1HK
kKFHMx+nMX2uQ9lsSwbR9D0Ql0v03lctlMsr8LnzNTazZPiLrcilFKGrzlGZOAx8
XXu1+9oPKPAUTvrpvXUmKXSqsm5XLuC74OP2w3rwV82hnIfs/CKs32X1hBRe1c+u
S+EtBWZSJKI8qAOdZEq+ZvoVGEeUGFosPhfF98rOkleUXP9LfSppYwlHO1/8s9PE
3Fl1CR9smDRfNOhVwv2GvlfrH8D4bF31doQUZ2yxdWlnKRYOp1gVzUf91jZ2V2kv
oUFQb673qP3TptyH6AwFjuZ8WHXpsbo2BAXtCKCP+6cqGczKZ+ntv2IKiVQwr1lX
LTfUey+ZXfVWq/xkF3SCTzO7BFEp91mupqWljR/YPs3zhOT5dyGArX0XcbRiz+rZ
yETYFlw9mmpwrZkjudfyfgZic2pcesUZOgwnq0F/BW5vuVYgFCWRFOvKChAM2G8v
Rcsh2rV/T2/U+pIbqwCPcgOSN1OUZ4siUGSKC1ELSdIcCtfqgP3rft9tvZbmWIiv
sGFJwZBLDIOqWzeyLxE5QvWtR9aIybqE9mJ4Y9Y2PPNJfNJsn1s/pD5qnvO3d6Ym
+7LztPmkS4OQeVHqY9e9EnCdd9ndTe0aLHzU3kZ51oTRPwLLb6Wztxily0V15PII
kN/0C0NMZ6Sy0Q5QgynI
=ci2t
-END PGP SIGNATURE-



CHANGELOG for 8.0.0-M5:


** Bug

* [WICKET-6317] - AuthenticatedWebSession#signOut() calls
twice after session invalidation
* [WICKET-6319] - AutoCompleteTextField: popup is hidden
when clicking on scrollbar in IE
* [WICKET-6329] - org.json migration issue
* [WICKET-6337] - Wrong class type in PageAccessSynchronizer
* [WICKET-6340] - The Ajax reponse of an AjaxSubmitButton
creates invalid XHTML markup for multipart forms
* [WICKET-6342] - Wrong baseUrl in BaseWebSocketBehavior

** Improvement

* [WICKET-6212] - CheckChoice / add a
getAdditionalAttributes() also for -tag
* [WICKET-6265] - Make it possible to authorize component
instantiations both with OR and AND rules
* [WICKET-6328] - Add 'pathInfo' to ForwardAttributes
* [WICKET-6333] - Use onConfigure() to set the visibility
of ExportToolbar instead of overriding isVisible()
* 

[GitHub] wicket pull request #217: [Fix] setRequired checked for primitive type only ...

[JoachimRohde]

GitHub user JoachimRohde opened a pull request:

https://github.com/apache/wicket/pull/217

[Fix] setRequired checked for primitive type only when the FormCompon…

…ent was NOT required
See https://issues.apache.org/jira/browse/WICKET-6350

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/JoachimRohde/wicket master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/217.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #217


commit e0805a6e4c413875409e0301811e5097714be5ad
Author: JoachimRohde 
Date:   2017-03-29T16:17:52Z

[Fix] setRequired checked for primitive type only when the FormComponent 
was NOT required




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Proposal to remove IDetachable from IModel hierarchy

[Emond Papegaaij]

Hi Pedro,

I fail to see why it is a problem for IModel to be IDetachable. It is
an integral part of the lifecycle of IModel. One could say that the
sole purpose of the detach traversal is to detach all models. A model
knows how to retrieve data, update data and to detach its internal
representation from the backend for future request handling. A model
that does not require special processing to detach, simply omits this
method: it has a default, empty implementation. Calling this empty
method is cheap and likely to cause problems.

Changing this part of the API will break the world. All
implementations of IModel need to either implement IDetachable or
remove detach(). All calls to detach() need to be guarded with an
instanceof check and a cast. You can be sure many users will be very
upset with such a change.

What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
detach and have it do nothing when nothing needs to be done?

Best regards,
Emond

On Wed, Mar 29, 2017 at 6:12 PM, Pedro Santos  wrote:
> From user's perspective this is a symmetrical problem. This sadness is
> carried over to an user in the other side, in need to avoid any detach
> logic or processing in his component or model if the target model isn't
> detachable. Right know he would have to come up with his own marker e.g.:
> IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose the
> side that is not semantically wrong.
>
> Also this instanceof test is more common for us, Wicket's core developers.
> For the final user the AbstractWrapModel class and a helper function (I can
> propose one) should hide this complexity. We can't judge how sad it's for
> the final user base on how common it's for *us* to have this instanceof
> check, and without even try to abstract this complexity.
>
> Yes, I think this fix should be carried over to FeedbackMessage,
> ICellPopulator and IDataProvider.
>
>>The current solution - even if semantically wrong - is simpler.
>
> It's simpler only because of the instanceof test that should be abstracted
> from the user?
>
>
> Pedro Santos
>
> On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier  wrote:
>
>> Hi Pedro,
>>
>> for Wicket your changes look fine.
>>
>> But I have an objection from a user's perspective:
>> If I hold a reference to a model (in a component or another wrapping
>> model), I'll always have to check the instance and do a cast before
>> detaching it:
>>
>> class MyComponent {
>>   private IModel foo;
>>
>>   @Override
>>   public void detachModels() {
>> if (foo instanceof IDetachable) {
>>   ((IDetachable)foo).detach();
>> }
>>   }
>> }
>>
>> Sad :/.
>>
>> Furthermore what about FeedbackMessage, ICellPopulator and IDataProvider?
>> Will their implementations no longer be forced to implement IDetachable too?
>>
>> IMHO your missing an important aspect of IDetachable: yes, many
>> implementations really don't need to detach anything. But many places
>> *have* to detach these objects, *iff* they are detachable.
>> The current solution - even if semantically wrong - is simpler.
>>
>> Best regards
>> Sven
>>
>>
>>
>> On 29.03.2017 15:52, Pedro Santos wrote:
>>
>>> Hi team,
>>>
>>> Not every model is detachable, but right now all models extends from
>>> IDetachable because this contract is forced to any implementation for
>>> IModel.
>>>
>>> The only way users have to communicate their model isn't detachable, for
>>> their own purpose, is by creating their own mechanism; but I think
>>> IDetachable interface should serve its purpose and to mark / be extended
>>> by
>>> detachable models, like documented in its own javadoc.
>>>
>>> I did the changes necessary for this improvement in the branch
>>> 'not-detachable' at [1], and hope you can give your input. While working
>>> on
>>> the branch I noticed a few problems in Wicket's code and already added a
>>> fix:
>>>
>>> - LabeledWebMarkupContainer called wrapped model detach twice (fixed)
>>>
>>> - SessionSizeModel has no detach logic but was being detached at
>>> SessionSizeDebugPanel (fixed)
>>>
>>> - The following classes had anonymous model wrappers that weren't
>>> extending
>>> from IWrapModel, that would better communicates their purpose(fixed):
>>> LambdaColumn, IModel, LambdaModel, AjaxEditableLabel, LambdaColumn
>>>
>>> 1 - https://github.com/pedrosans/wicket/tree/not-detachable
>>>
>>> Pedro Santos
>>>
>>>
>>

Re: Proposal to remove IDetachable from IModel hierarchy

[Pedro Santos]

>From user's perspective this is a symmetrical problem. This sadness is
carried over to an user in the other side, in need to avoid any detach
logic or processing in his component or model if the target model isn't
detachable. Right know he would have to come up with his own marker e.g.:
IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose the
side that is not semantically wrong.

Also this instanceof test is more common for us, Wicket's core developers.
For the final user the AbstractWrapModel class and a helper function (I can
propose one) should hide this complexity. We can't judge how sad it's for
the final user base on how common it's for *us* to have this instanceof
check, and without even try to abstract this complexity.

Yes, I think this fix should be carried over to FeedbackMessage,
ICellPopulator and IDataProvider.

>The current solution - even if semantically wrong - is simpler.

It's simpler only because of the instanceof test that should be abstracted
from the user?


Pedro Santos

On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier  wrote:

> Hi Pedro,
>
> for Wicket your changes look fine.
>
> But I have an objection from a user's perspective:
> If I hold a reference to a model (in a component or another wrapping
> model), I'll always have to check the instance and do a cast before
> detaching it:
>
> class MyComponent {
>   private IModel foo;
>
>   @Override
>   public void detachModels() {
> if (foo instanceof IDetachable) {
>   ((IDetachable)foo).detach();
> }
>   }
> }
>
> Sad :/.
>
> Furthermore what about FeedbackMessage, ICellPopulator and IDataProvider?
> Will their implementations no longer be forced to implement IDetachable too?
>
> IMHO your missing an important aspect of IDetachable: yes, many
> implementations really don't need to detach anything. But many places
> *have* to detach these objects, *iff* they are detachable.
> The current solution - even if semantically wrong - is simpler.
>
> Best regards
> Sven
>
>
>
> On 29.03.2017 15:52, Pedro Santos wrote:
>
>> Hi team,
>>
>> Not every model is detachable, but right now all models extends from
>> IDetachable because this contract is forced to any implementation for
>> IModel.
>>
>> The only way users have to communicate their model isn't detachable, for
>> their own purpose, is by creating their own mechanism; but I think
>> IDetachable interface should serve its purpose and to mark / be extended
>> by
>> detachable models, like documented in its own javadoc.
>>
>> I did the changes necessary for this improvement in the branch
>> 'not-detachable' at [1], and hope you can give your input. While working
>> on
>> the branch I noticed a few problems in Wicket's code and already added a
>> fix:
>>
>> - LabeledWebMarkupContainer called wrapped model detach twice (fixed)
>>
>> - SessionSizeModel has no detach logic but was being detached at
>> SessionSizeDebugPanel (fixed)
>>
>> - The following classes had anonymous model wrappers that weren't
>> extending
>> from IWrapModel, that would better communicates their purpose(fixed):
>> LambdaColumn, IModel, LambdaModel, AjaxEditableLabel, LambdaColumn
>>
>> 1 - https://github.com/pedrosans/wicket/tree/not-detachable
>>
>> Pedro Santos
>>
>>
>

Re: Question regarding new AjaxDownload (WICKET-6286)

[Maxim Solodovnik]

Will try to migrate all my use cases on a SNAPSHOT first
Then will do
Thanks Martin!

On Wed, Mar 29, 2017 at 9:28 PM, Martin Grigorov  wrote:
> Maxim, you can use Location.IFrame or Location.SameWindow too in -M5 (to be
> released!).
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Mar 29, 2017 at 4:26 PM, Sven Meier  wrote:
>
>> In a minute :P
>>
>> Sven
>>
>>
>>
>> On 29.03.2017 16:15, Andrea Del Bene wrote:
>>
>>> Right when we will return to "success" :-)
>>>
>>> https://ci.apache.org/builders/wicket-master
>>>
>>> On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
>>> wrote:
>>>
>>> Wow, Thanks a lot!
 Could you please let me know when SNAPSHOT with the fix will be
 available?

 On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:

> Hi,
>
> so we have to change the Location.Blob to use XMLHttpRequest directly,
> because jQuery does not support blob downloads :/.
>
> I've change the JavaScript and now downloading of the zip works fine.
>
> FileSystemResource might not be the best candidate (because it's not
> serializable), but you can use an indirection to prevent it being
>
 serialized

> along with AjaxDownload:
>
>  final AjaxDownload download = new AjaxDownload(
>  new IResource()
>  {
>  @Override
>  public void respond(Attributes attributes)
>  {
>  new
> FileSystemResource(zipFile.toPath()).respond(attributes);
>  }
>  }
>  );
>
> Have fun
> Sven
>
>
>
> On 29.03.2017 15:12, Maxim Solodovnik wrote:
>
>> Filename is minor issue 
>> Main problem is invalid file :(
>>
>> How can I serve the file from file system? I thought
>> filesystemreference
>> if
>> the best candidate .
>>
>> WBR, Maxim
>> (from mobile, sorry for the typos)
>>
>> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
>>
>> Hi Maxim,
>>>
>>> three things:
>>>
>>> - filename ... no one sets the file name :P
>>>
>>> - serializable error ... FileSystemResource holds a reference to the
>>> path,
>>> which is not serializable
>>>
>>> - corruct zip ... my bad, it seems that Location.Blob mangles the file
>>>
>> on

> the client side
>>>
>>> I'll see what I can do about Location.Blob - it might be an encoding
>>> issue.
>>>
>>> Have fun
>>> Sven
>>>
>>>
>>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
>>>
>>> here you are: https://github.com/solomax/ajax-download
 Absolutely don't understand what is going on :(

 On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <

>>> solomax...@gmail.com>

> wrote:

 Yep, zip file is valid
> Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit
>
 :(

> Will try to create quickstart
>
> something extremely weird
>
> On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <
>
 mgrigo...@apache.org>

> wrote:
>
> Hi Maxim,
>>
>> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> wrote:
>>
>> Thanks a lot Martin for detailed explanation
>>
>>> I do have this functionality working with old version of
>>>
>> AjaxDownload

> And here is my first try to migrate to the new internal wicket
>>> AjaxDownload:
>>> https://github.com/apache/openmeetings/commit/
>>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>>>
>>> I would appreciate if you can take a look at this tiny commit.
>>>
>>> Something really doesn't work as expected 
>>>
>>> Commited version behaves wrong:
>>> 1) file downloaded has wrong name
>>>
>>> You do not set file name anywhere!
>>>
>> Keep a reference to the constructed ResourceResponse and call its
>> #setFileName(...)
>>
>>
>> 2) is not valid zip file (cannot be opened)
>>
>>> Is the backupPath representing a ZIP file ?
>>>
>>
>> 3) for some reason I'm not able to get to breakpoint at line 115
>> [1]
>>
>>> Put a breakpoint at
>>> AjaxDownload.ResourceBehavior#onResourceRequested()
>>>
>> and
>> see what happens
>>
>>
>> Additionally I got NotSerializable exception in case I made
>>
> "download"

> class final variable
>>>
>>> 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Martin Grigorov]

Maxim, you can use Location.IFrame or Location.SameWindow too in -M5 (to be
released!).

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

On Wed, Mar 29, 2017 at 4:26 PM, Sven Meier  wrote:

> In a minute :P
>
> Sven
>
>
>
> On 29.03.2017 16:15, Andrea Del Bene wrote:
>
>> Right when we will return to "success" :-)
>>
>> https://ci.apache.org/builders/wicket-master
>>
>> On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
>> wrote:
>>
>> Wow, Thanks a lot!
>>> Could you please let me know when SNAPSHOT with the fix will be
>>> available?
>>>
>>> On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:
>>>
 Hi,

 so we have to change the Location.Blob to use XMLHttpRequest directly,
 because jQuery does not support blob downloads :/.

 I've change the JavaScript and now downloading of the zip works fine.

 FileSystemResource might not be the best candidate (because it's not
 serializable), but you can use an indirection to prevent it being

>>> serialized
>>>
 along with AjaxDownload:

  final AjaxDownload download = new AjaxDownload(
  new IResource()
  {
  @Override
  public void respond(Attributes attributes)
  {
  new
 FileSystemResource(zipFile.toPath()).respond(attributes);
  }
  }
  );

 Have fun
 Sven



 On 29.03.2017 15:12, Maxim Solodovnik wrote:

> Filename is minor issue 
> Main problem is invalid file :(
>
> How can I serve the file from file system? I thought
> filesystemreference
> if
> the best candidate .
>
> WBR, Maxim
> (from mobile, sorry for the typos)
>
> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
>
> Hi Maxim,
>>
>> three things:
>>
>> - filename ... no one sets the file name :P
>>
>> - serializable error ... FileSystemResource holds a reference to the
>> path,
>> which is not serializable
>>
>> - corruct zip ... my bad, it seems that Location.Blob mangles the file
>>
> on
>>>
 the client side
>>
>> I'll see what I can do about Location.Blob - it might be an encoding
>> issue.
>>
>> Have fun
>> Sven
>>
>>
>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
>>
>> here you are: https://github.com/solomax/ajax-download
>>> Absolutely don't understand what is going on :(
>>>
>>> On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <
>>>
>> solomax...@gmail.com>
>>>
 wrote:
>>>
>>> Yep, zip file is valid
 Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit

>>> :(
>>>
 Will try to create quickstart

 something extremely weird

 On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <

>>> mgrigo...@apache.org>
>>>
 wrote:

 Hi Maxim,
>
> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> wrote:
>
> Thanks a lot Martin for detailed explanation
>
>> I do have this functionality working with old version of
>>
> AjaxDownload
>>>
 And here is my first try to migrate to the new internal wicket
>> AjaxDownload:
>> https://github.com/apache/openmeetings/commit/
>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>>
>> I would appreciate if you can take a look at this tiny commit.
>>
>> Something really doesn't work as expected 
>>
>> Commited version behaves wrong:
>> 1) file downloaded has wrong name
>>
>> You do not set file name anywhere!
>>
> Keep a reference to the constructed ResourceResponse and call its
> #setFileName(...)
>
>
> 2) is not valid zip file (cannot be opened)
>
>> Is the backupPath representing a ZIP file ?
>>
>
> 3) for some reason I'm not able to get to breakpoint at line 115
> [1]
>
>> Put a breakpoint at
>> AjaxDownload.ResourceBehavior#onResourceRequested()
>>
> and
> see what happens
>
>
> Additionally I got NotSerializable exception in case I made
>
 "download"
>>>
 class final variable
>>
>> java.nio.file.Path is not Serializable!
>>
>
> What am I doing wrong?
>
>> [1] https://github.com/apache/openmeetings/commit/
>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
>> 0a499c88998a93ceb51c347836aa6195R115
>>
>> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov

Re: Question regarding new AjaxDownload (WICKET-6286)

[Sven Meier]

In a minute :P

Sven


On 29.03.2017 16:15, Andrea Del Bene wrote:

Right when we will return to "success" :-)

https://ci.apache.org/builders/wicket-master

On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
wrote:


Wow, Thanks a lot!
Could you please let me know when SNAPSHOT with the fix will be available?

On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:

Hi,

so we have to change the Location.Blob to use XMLHttpRequest directly,
because jQuery does not support blob downloads :/.

I've change the JavaScript and now downloading of the zip works fine.

FileSystemResource might not be the best candidate (because it's not
serializable), but you can use an indirection to prevent it being

serialized

along with AjaxDownload:

 final AjaxDownload download = new AjaxDownload(
 new IResource()
 {
 @Override
 public void respond(Attributes attributes)
 {
 new
FileSystemResource(zipFile.toPath()).respond(attributes);
 }
 }
 );

Have fun
Sven



On 29.03.2017 15:12, Maxim Solodovnik wrote:

Filename is minor issue 
Main problem is invalid file :(

How can I serve the file from file system? I thought filesystemreference
if
the best candidate .

WBR, Maxim
(from mobile, sorry for the typos)

On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:


Hi Maxim,

three things:

- filename ... no one sets the file name :P

- serializable error ... FileSystemResource holds a reference to the
path,
which is not serializable

- corruct zip ... my bad, it seems that Location.Blob mangles the file

on

the client side

I'll see what I can do about Location.Blob - it might be an encoding
issue.

Have fun
Sven


On 29.03.2017 14:15, Maxim Solodovnik wrote:


here you are: https://github.com/solomax/ajax-download
Absolutely don't understand what is going on :(

On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <

solomax...@gmail.com>

wrote:


Yep, zip file is valid
Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit

:(

Will try to create quickstart

something extremely weird

On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <

mgrigo...@apache.org>

wrote:


Hi Maxim,

On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
solomax...@gmail.com>
wrote:

Thanks a lot Martin for detailed explanation

I do have this functionality working with old version of

AjaxDownload

And here is my first try to migrate to the new internal wicket
AjaxDownload:
https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f

I would appreciate if you can take a look at this tiny commit.

Something really doesn't work as expected 

Commited version behaves wrong:
1) file downloaded has wrong name

You do not set file name anywhere!

Keep a reference to the constructed ResourceResponse and call its
#setFileName(...)


2) is not valid zip file (cannot be opened)

Is the backupPath representing a ZIP file ?


3) for some reason I'm not able to get to breakpoint at line 115 [1]

Put a breakpoint at
AjaxDownload.ResourceBehavior#onResourceRequested()

and
see what happens


Additionally I got NotSerializable exception in case I made

"download"

class final variable

java.nio.file.Path is not Serializable!


What am I doing wrong?

[1] https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
0a499c88998a93ceb51c347836aa6195R115

On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov

wrote:

Hi Maxim,

I use the new AjaxDownload with a ResourceReference, i.e.

Re: Question regarding new AjaxDownload (WICKET-6286)

[Andrea Del Bene]

you're wellcome

On Wed, Mar 29, 2017 at 4:20 PM, Maxim Solodovnik 
wrote:

> Now I know where to check :)
> Thanks!
>
> On Wed, Mar 29, 2017 at 9:15 PM, Andrea Del Bene 
> wrote:
> > Right when we will return to "success" :-)
> >
> > https://ci.apache.org/builders/wicket-master
> >
> > On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
> > wrote:
> >
> >> Wow, Thanks a lot!
> >> Could you please let me know when SNAPSHOT with the fix will be
> available?
> >>
> >> On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:
> >> > Hi,
> >> >
> >> > so we have to change the Location.Blob to use XMLHttpRequest directly,
> >> > because jQuery does not support blob downloads :/.
> >> >
> >> > I've change the JavaScript and now downloading of the zip works fine.
> >> >
> >> > FileSystemResource might not be the best candidate (because it's not
> >> > serializable), but you can use an indirection to prevent it being
> >> serialized
> >> > along with AjaxDownload:
> >> >
> >> > final AjaxDownload download = new AjaxDownload(
> >> > new IResource()
> >> > {
> >> > @Override
> >> > public void respond(Attributes attributes)
> >> > {
> >> > new
> >> > FileSystemResource(zipFile.toPath()).respond(attributes);
> >> > }
> >> > }
> >> > );
> >> >
> >> > Have fun
> >> > Sven
> >> >
> >> >
> >> >
> >> > On 29.03.2017 15:12, Maxim Solodovnik wrote:
> >> >>
> >> >> Filename is minor issue 
> >> >> Main problem is invalid file :(
> >> >>
> >> >> How can I serve the file from file system? I thought
> filesystemreference
> >> >> if
> >> >> the best candidate .
> >> >>
> >> >> WBR, Maxim
> >> >> (from mobile, sorry for the typos)
> >> >>
> >> >> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
> >> >>
> >> >>> Hi Maxim,
> >> >>>
> >> >>> three things:
> >> >>>
> >> >>> - filename ... no one sets the file name :P
> >> >>>
> >> >>> - serializable error ... FileSystemResource holds a reference to the
> >> >>> path,
> >> >>> which is not serializable
> >> >>>
> >> >>> - corruct zip ... my bad, it seems that Location.Blob mangles the
> file
> >> on
> >> >>> the client side
> >> >>>
> >> >>> I'll see what I can do about Location.Blob - it might be an encoding
> >> >>> issue.
> >> >>>
> >> >>> Have fun
> >> >>> Sven
> >> >>>
> >> >>>
> >> >>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
> >> >>>
> >>  here you are: https://github.com/solomax/ajax-download
> >>  Absolutely don't understand what is going on :(
> >> 
> >>  On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <
> >> solomax...@gmail.com>
> >>  wrote:
> >> 
> >> > Yep, zip file is valid
> >> > Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not
> hit
> >> :(
> >> > Will try to create quickstart
> >> >
> >> > something extremely weird
> >> >
> >> > On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <
> >> mgrigo...@apache.org>
> >> > wrote:
> >> >
> >> >> Hi Maxim,
> >> >>
> >> >> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
> >> >> solomax...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> Thanks a lot Martin for detailed explanation
> >> >>>
> >> >>> I do have this functionality working with old version of
> >> AjaxDownload
> >> >>>
> >> >>> And here is my first try to migrate to the new internal wicket
> >> >>> AjaxDownload:
> >> >>> https://github.com/apache/openmeetings/commit/
> >> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
> >> >>>
> >> >>> I would appreciate if you can take a look at this tiny commit.
> >> >>>
> >> >>> Something really doesn't work as expected 
> >> >>>
> >> >>> Commited version behaves wrong:
> >> >>> 1) file downloaded has wrong name
> >> >>>
> >> >>> You do not set file name anywhere!
> >> >>
> >> >> Keep a reference to the constructed ResourceResponse and call its
> >> >> #setFileName(...)
> >> >>
> >> >>
> >> >> 2) is not valid zip file (cannot be opened)
> >> >>>
> >> >>> Is the backupPath representing a ZIP file ?
> >> >>
> >> >>
> >> >> 3) for some reason I'm not able to get to breakpoint at line 115
> [1]
> >> >>>
> >> >>> Put a breakpoint at
> >> >>> AjaxDownload.ResourceBehavior#onResourceRequested()
> >> >>
> >> >> and
> >> >> see what happens
> >> >>
> >> >>
> >> >> Additionally I got NotSerializable exception in case I made
> >> "download"
> >> >>>
> >> >>> class final variable
> >> >>>
> >> >>> java.nio.file.Path is not Serializable!
> >> >>
> >> >>
> >> >> What am I doing wrong?
> >> >>>
> >> >>> [1] https://github.com/apache/openmeetings/commit/
> >> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
> >> >>> 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Maxim Solodovnik]

Now I know where to check :)
Thanks!

On Wed, Mar 29, 2017 at 9:15 PM, Andrea Del Bene  wrote:
> Right when we will return to "success" :-)
>
> https://ci.apache.org/builders/wicket-master
>
> On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
> wrote:
>
>> Wow, Thanks a lot!
>> Could you please let me know when SNAPSHOT with the fix will be available?
>>
>> On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:
>> > Hi,
>> >
>> > so we have to change the Location.Blob to use XMLHttpRequest directly,
>> > because jQuery does not support blob downloads :/.
>> >
>> > I've change the JavaScript and now downloading of the zip works fine.
>> >
>> > FileSystemResource might not be the best candidate (because it's not
>> > serializable), but you can use an indirection to prevent it being
>> serialized
>> > along with AjaxDownload:
>> >
>> > final AjaxDownload download = new AjaxDownload(
>> > new IResource()
>> > {
>> > @Override
>> > public void respond(Attributes attributes)
>> > {
>> > new
>> > FileSystemResource(zipFile.toPath()).respond(attributes);
>> > }
>> > }
>> > );
>> >
>> > Have fun
>> > Sven
>> >
>> >
>> >
>> > On 29.03.2017 15:12, Maxim Solodovnik wrote:
>> >>
>> >> Filename is minor issue 
>> >> Main problem is invalid file :(
>> >>
>> >> How can I serve the file from file system? I thought filesystemreference
>> >> if
>> >> the best candidate .
>> >>
>> >> WBR, Maxim
>> >> (from mobile, sorry for the typos)
>> >>
>> >> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
>> >>
>> >>> Hi Maxim,
>> >>>
>> >>> three things:
>> >>>
>> >>> - filename ... no one sets the file name :P
>> >>>
>> >>> - serializable error ... FileSystemResource holds a reference to the
>> >>> path,
>> >>> which is not serializable
>> >>>
>> >>> - corruct zip ... my bad, it seems that Location.Blob mangles the file
>> on
>> >>> the client side
>> >>>
>> >>> I'll see what I can do about Location.Blob - it might be an encoding
>> >>> issue.
>> >>>
>> >>> Have fun
>> >>> Sven
>> >>>
>> >>>
>> >>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
>> >>>
>>  here you are: https://github.com/solomax/ajax-download
>>  Absolutely don't understand what is going on :(
>> 
>>  On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <
>> solomax...@gmail.com>
>>  wrote:
>> 
>> > Yep, zip file is valid
>> > Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit
>> :(
>> > Will try to create quickstart
>> >
>> > something extremely weird
>> >
>> > On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <
>> mgrigo...@apache.org>
>> > wrote:
>> >
>> >> Hi Maxim,
>> >>
>> >> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
>> >> solomax...@gmail.com>
>> >> wrote:
>> >>
>> >> Thanks a lot Martin for detailed explanation
>> >>>
>> >>> I do have this functionality working with old version of
>> AjaxDownload
>> >>>
>> >>> And here is my first try to migrate to the new internal wicket
>> >>> AjaxDownload:
>> >>> https://github.com/apache/openmeetings/commit/
>> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>> >>>
>> >>> I would appreciate if you can take a look at this tiny commit.
>> >>>
>> >>> Something really doesn't work as expected 
>> >>>
>> >>> Commited version behaves wrong:
>> >>> 1) file downloaded has wrong name
>> >>>
>> >>> You do not set file name anywhere!
>> >>
>> >> Keep a reference to the constructed ResourceResponse and call its
>> >> #setFileName(...)
>> >>
>> >>
>> >> 2) is not valid zip file (cannot be opened)
>> >>>
>> >>> Is the backupPath representing a ZIP file ?
>> >>
>> >>
>> >> 3) for some reason I'm not able to get to breakpoint at line 115 [1]
>> >>>
>> >>> Put a breakpoint at
>> >>> AjaxDownload.ResourceBehavior#onResourceRequested()
>> >>
>> >> and
>> >> see what happens
>> >>
>> >>
>> >> Additionally I got NotSerializable exception in case I made
>> "download"
>> >>>
>> >>> class final variable
>> >>>
>> >>> java.nio.file.Path is not Serializable!
>> >>
>> >>
>> >> What am I doing wrong?
>> >>>
>> >>> [1] https://github.com/apache/openmeetings/commit/
>> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
>> >>> 0a499c88998a93ceb51c347836aa6195R115
>> >>>
>> >>> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov
>> >>> > >>> wrote:
>> >>>
>>  On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik <
>>  solomax...@gmail.com
>> 
>>  wrote:
>> 
>>  Actually I have 2 example use cases:
>> >
>> > 1) user selects files on file tree
>> 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Andrea Del Bene]

Right when we will return to "success" :-)

https://ci.apache.org/builders/wicket-master

On Wed, Mar 29, 2017 at 4:07 PM, Maxim Solodovnik 
wrote:

> Wow, Thanks a lot!
> Could you please let me know when SNAPSHOT with the fix will be available?
>
> On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:
> > Hi,
> >
> > so we have to change the Location.Blob to use XMLHttpRequest directly,
> > because jQuery does not support blob downloads :/.
> >
> > I've change the JavaScript and now downloading of the zip works fine.
> >
> > FileSystemResource might not be the best candidate (because it's not
> > serializable), but you can use an indirection to prevent it being
> serialized
> > along with AjaxDownload:
> >
> > final AjaxDownload download = new AjaxDownload(
> > new IResource()
> > {
> > @Override
> > public void respond(Attributes attributes)
> > {
> > new
> > FileSystemResource(zipFile.toPath()).respond(attributes);
> > }
> > }
> > );
> >
> > Have fun
> > Sven
> >
> >
> >
> > On 29.03.2017 15:12, Maxim Solodovnik wrote:
> >>
> >> Filename is minor issue 
> >> Main problem is invalid file :(
> >>
> >> How can I serve the file from file system? I thought filesystemreference
> >> if
> >> the best candidate .
> >>
> >> WBR, Maxim
> >> (from mobile, sorry for the typos)
> >>
> >> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
> >>
> >>> Hi Maxim,
> >>>
> >>> three things:
> >>>
> >>> - filename ... no one sets the file name :P
> >>>
> >>> - serializable error ... FileSystemResource holds a reference to the
> >>> path,
> >>> which is not serializable
> >>>
> >>> - corruct zip ... my bad, it seems that Location.Blob mangles the file
> on
> >>> the client side
> >>>
> >>> I'll see what I can do about Location.Blob - it might be an encoding
> >>> issue.
> >>>
> >>> Have fun
> >>> Sven
> >>>
> >>>
> >>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
> >>>
>  here you are: https://github.com/solomax/ajax-download
>  Absolutely don't understand what is going on :(
> 
>  On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik <
> solomax...@gmail.com>
>  wrote:
> 
> > Yep, zip file is valid
> > Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit
> :(
> > Will try to create quickstart
> >
> > something extremely weird
> >
> > On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov <
> mgrigo...@apache.org>
> > wrote:
> >
> >> Hi Maxim,
> >>
> >> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
> >> solomax...@gmail.com>
> >> wrote:
> >>
> >> Thanks a lot Martin for detailed explanation
> >>>
> >>> I do have this functionality working with old version of
> AjaxDownload
> >>>
> >>> And here is my first try to migrate to the new internal wicket
> >>> AjaxDownload:
> >>> https://github.com/apache/openmeetings/commit/
> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
> >>>
> >>> I would appreciate if you can take a look at this tiny commit.
> >>>
> >>> Something really doesn't work as expected 
> >>>
> >>> Commited version behaves wrong:
> >>> 1) file downloaded has wrong name
> >>>
> >>> You do not set file name anywhere!
> >>
> >> Keep a reference to the constructed ResourceResponse and call its
> >> #setFileName(...)
> >>
> >>
> >> 2) is not valid zip file (cannot be opened)
> >>>
> >>> Is the backupPath representing a ZIP file ?
> >>
> >>
> >> 3) for some reason I'm not able to get to breakpoint at line 115 [1]
> >>>
> >>> Put a breakpoint at
> >>> AjaxDownload.ResourceBehavior#onResourceRequested()
> >>
> >> and
> >> see what happens
> >>
> >>
> >> Additionally I got NotSerializable exception in case I made
> "download"
> >>>
> >>> class final variable
> >>>
> >>> java.nio.file.Path is not Serializable!
> >>
> >>
> >> What am I doing wrong?
> >>>
> >>> [1] https://github.com/apache/openmeetings/commit/
> >>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
> >>> 0a499c88998a93ceb51c347836aa6195R115
> >>>
> >>> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov
> >>>  >>> wrote:
> >>>
>  On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik <
>  solomax...@gmail.com
> 
>  wrote:
> 
>  Actually I have 2 example use cases:
> >
> > 1) user selects files on file tree
> > 2) as soon as file is selected and download is enabled for it,
> used
> > can
> > press ajax download button and get the file
> >
> > Another case:
> > User requests system backup
> > As soon as backup is created (Progress complete)

Re: Question regarding new AjaxDownload (WICKET-6286)

[Maxim Solodovnik]

Wow, Thanks a lot!
Could you please let me know when SNAPSHOT with the fix will be available?

On Wed, Mar 29, 2017 at 8:50 PM, Sven Meier  wrote:
> Hi,
>
> so we have to change the Location.Blob to use XMLHttpRequest directly,
> because jQuery does not support blob downloads :/.
>
> I've change the JavaScript and now downloading of the zip works fine.
>
> FileSystemResource might not be the best candidate (because it's not
> serializable), but you can use an indirection to prevent it being serialized
> along with AjaxDownload:
>
> final AjaxDownload download = new AjaxDownload(
> new IResource()
> {
> @Override
> public void respond(Attributes attributes)
> {
> new
> FileSystemResource(zipFile.toPath()).respond(attributes);
> }
> }
> );
>
> Have fun
> Sven
>
>
>
> On 29.03.2017 15:12, Maxim Solodovnik wrote:
>>
>> Filename is minor issue 
>> Main problem is invalid file :(
>>
>> How can I serve the file from file system? I thought filesystemreference
>> if
>> the best candidate .
>>
>> WBR, Maxim
>> (from mobile, sorry for the typos)
>>
>> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
>>
>>> Hi Maxim,
>>>
>>> three things:
>>>
>>> - filename ... no one sets the file name :P
>>>
>>> - serializable error ... FileSystemResource holds a reference to the
>>> path,
>>> which is not serializable
>>>
>>> - corruct zip ... my bad, it seems that Location.Blob mangles the file on
>>> the client side
>>>
>>> I'll see what I can do about Location.Blob - it might be an encoding
>>> issue.
>>>
>>> Have fun
>>> Sven
>>>
>>>
>>> On 29.03.2017 14:15, Maxim Solodovnik wrote:
>>>
 here you are: https://github.com/solomax/ajax-download
 Absolutely don't understand what is going on :(

 On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik 
 wrote:

> Yep, zip file is valid
> Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
> Will try to create quickstart
>
> something extremely weird
>
> On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov 
> wrote:
>
>> Hi Maxim,
>>
>> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> wrote:
>>
>> Thanks a lot Martin for detailed explanation
>>>
>>> I do have this functionality working with old version of AjaxDownload
>>>
>>> And here is my first try to migrate to the new internal wicket
>>> AjaxDownload:
>>> https://github.com/apache/openmeetings/commit/
>>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>>>
>>> I would appreciate if you can take a look at this tiny commit.
>>>
>>> Something really doesn't work as expected 
>>>
>>> Commited version behaves wrong:
>>> 1) file downloaded has wrong name
>>>
>>> You do not set file name anywhere!
>>
>> Keep a reference to the constructed ResourceResponse and call its
>> #setFileName(...)
>>
>>
>> 2) is not valid zip file (cannot be opened)
>>>
>>> Is the backupPath representing a ZIP file ?
>>
>>
>> 3) for some reason I'm not able to get to breakpoint at line 115 [1]
>>>
>>> Put a breakpoint at
>>> AjaxDownload.ResourceBehavior#onResourceRequested()
>>
>> and
>> see what happens
>>
>>
>> Additionally I got NotSerializable exception in case I made "download"
>>>
>>> class final variable
>>>
>>> java.nio.file.Path is not Serializable!
>>
>>
>> What am I doing wrong?
>>>
>>> [1] https://github.com/apache/openmeetings/commit/
>>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
>>> 0a499c88998a93ceb51c347836aa6195R115
>>>
>>> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov
>>> >> wrote:
>>>
 On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik <
 solomax...@gmail.com

 wrote:

 Actually I have 2 example use cases:
>
> 1) user selects files on file tree
> 2) as soon as file is selected and download is enabled for it, used
> can
> press ajax download button and get the file
>
> Another case:
> User requests system backup
> As soon as backup is created (Progress complete)
> Download of newly created file should be initiated
>
> I can't create ResourceReference and override getResourceStream of
> it
>
 since
 I only have resource just before download
>
> Wicket IResource is an abstraction over the real resource.

 In my case i also create the response on the fly. It is either a
 single
 File or a Zip file with several entries.
 The ResourceReference is 

Proposal to remove IDetachable from IModel hierarchy

[Pedro Santos]

Hi team,

Not every model is detachable, but right now all models extends from
IDetachable because this contract is forced to any implementation for
IModel.

The only way users have to communicate their model isn't detachable, for
their own purpose, is by creating their own mechanism; but I think
IDetachable interface should serve its purpose and to mark / be extended by
detachable models, like documented in its own javadoc.

I did the changes necessary for this improvement in the branch
'not-detachable' at [1], and hope you can give your input. While working on
the branch I noticed a few problems in Wicket's code and already added a
fix:

- LabeledWebMarkupContainer called wrapped model detach twice (fixed)

- SessionSizeModel has no detach logic but was being detached at
SessionSizeDebugPanel (fixed)

- The following classes had anonymous model wrappers that weren't extending
from IWrapModel, that would better communicates their purpose(fixed):
LambdaColumn, IModel, LambdaModel, AjaxEditableLabel, LambdaColumn

1 - https://github.com/pedrosans/wicket/tree/not-detachable

Pedro Santos

Re: Question regarding new AjaxDownload (WICKET-6286)

[Sven Meier]

Hi,

so we have to change the Location.Blob to use XMLHttpRequest directly, 
because jQuery does not support blob downloads :/.


I've change the JavaScript and now downloading of the zip works fine.

FileSystemResource might not be the best candidate (because it's not 
serializable), but you can use an indirection to prevent it being 
serialized along with AjaxDownload:


final AjaxDownload download = new AjaxDownload(
new IResource()
{
@Override
public void respond(Attributes attributes)
{
new 
FileSystemResource(zipFile.toPath()).respond(attributes);

}
}
);

Have fun
Sven


On 29.03.2017 15:12, Maxim Solodovnik wrote:

Filename is minor issue 
Main problem is invalid file :(

How can I serve the file from file system? I thought filesystemreference if
the best candidate .

WBR, Maxim
(from mobile, sorry for the typos)

On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:


Hi Maxim,

three things:

- filename ... no one sets the file name :P

- serializable error ... FileSystemResource holds a reference to the path,
which is not serializable

- corruct zip ... my bad, it seems that Location.Blob mangles the file on
the client side

I'll see what I can do about Location.Blob - it might be an encoding issue.

Have fun
Sven


On 29.03.2017 14:15, Maxim Solodovnik wrote:


here you are: https://github.com/solomax/ajax-download
Absolutely don't understand what is going on :(

On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik 
wrote:


Yep, zip file is valid
Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
Will try to create quickstart

something extremely weird

On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov 
wrote:


Hi Maxim,

On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
solomax...@gmail.com>
wrote:

Thanks a lot Martin for detailed explanation

I do have this functionality working with old version of AjaxDownload

And here is my first try to migrate to the new internal wicket
AjaxDownload:
https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f

I would appreciate if you can take a look at this tiny commit.

Something really doesn't work as expected 

Commited version behaves wrong:
1) file downloaded has wrong name

You do not set file name anywhere!

Keep a reference to the constructed ResourceResponse and call its
#setFileName(...)


2) is not valid zip file (cannot be opened)

Is the backupPath representing a ZIP file ?


3) for some reason I'm not able to get to breakpoint at line 115 [1]

Put a breakpoint at AjaxDownload.ResourceBehavior#onResourceRequested()

and
see what happens


Additionally I got NotSerializable exception in case I made "download"

class final variable

java.nio.file.Path is not Serializable!


What am I doing wrong?

[1] https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
0a499c88998a93ceb51c347836aa6195R115

On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov 
wrote:

Hi Maxim,

I use the new AjaxDownload with a ResourceReference, i.e.
AjaxDownload#AjaxDownload(org.apache.wicket.request.
resource.ResourceReference,
org.apache.wicket.request.mapper.parameter.PageParameters)
The ResourceReference has

public IResource getResource() {
  return new StatementDownloadResource();
}

StatementDownloadResource extends ResourceStreamResource and
provides
implementation of #getResourceStream(). There I have a logic that


returns

either FileResourceStream or 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Martin Grigorov]

On Wed, Mar 29, 2017 at 3:12 PM, Maxim Solodovnik 
wrote:

> Filename is minor issue 
> Main problem is invalid file :(
>
> How can I serve the file from file system? I thought filesystemreference if
> the best candidate .
>

If ResourceBehavior#onRequest() is not called then there is no (proper)
Ajax call at all.
So FileSystemResource is not the problem. Something breaks earlier.
I don't have time now to debug it. Later!


>
> WBR, Maxim
> (from mobile, sorry for the typos)
>
> On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:
>
> > Hi Maxim,
> >
> > three things:
> >
> > - filename ... no one sets the file name :P
> >
> > - serializable error ... FileSystemResource holds a reference to the
> path,
> > which is not serializable
> >
> > - corruct zip ... my bad, it seems that Location.Blob mangles the file on
> > the client side
> >
> > I'll see what I can do about Location.Blob - it might be an encoding
> issue.
> >
> > Have fun
> > Sven
> >
> >
> > On 29.03.2017 14:15, Maxim Solodovnik wrote:
> >
> >> here you are: https://github.com/solomax/ajax-download
> >> Absolutely don't understand what is going on :(
> >>
> >> On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik  >
> >> wrote:
> >>
> >>> Yep, zip file is valid
> >>> Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
> >>> Will try to create quickstart
> >>>
> >>> something extremely weird
> >>>
> >>> On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov  >
> >>> wrote:
> >>>
>  Hi Maxim,
> 
>  On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
>  solomax...@gmail.com>
>  wrote:
> 
>  Thanks a lot Martin for detailed explanation
> > I do have this functionality working with old version of AjaxDownload
> >
> > And here is my first try to migrate to the new internal wicket
> > AjaxDownload:
> > https://github.com/apache/openmeetings/commit/
> > 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
> >
> > I would appreciate if you can take a look at this tiny commit.
> >
> > Something really doesn't work as expected 
> >
> > Commited version behaves wrong:
> > 1) file downloaded has wrong name
> >
> > You do not set file name anywhere!
>  Keep a reference to the constructed ResourceResponse and call its
>  #setFileName(...)
> 
> 
>  2) is not valid zip file (cannot be opened)
> >
> > Is the backupPath representing a ZIP file ?
> 
> 
>  3) for some reason I'm not able to get to breakpoint at line 115 [1]
> >
> > Put a breakpoint at AjaxDownload.ResourceBehavior#
> onResourceRequested()
>  and
>  see what happens
> 
> 
>  Additionally I got NotSerializable exception in case I made "download"
> > class final variable
> >
> > java.nio.file.Path is not Serializable!
> 
> 
>  What am I doing wrong?
> >
> > [1] https://github.com/apache/openmeetings/commit/
> > 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
> > 0a499c88998a93ceb51c347836aa6195R115
> >
> > On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov <
> mgrigo...@apache.org
> > >
> > wrote:
> >
> >> On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik <
> >> solomax...@gmail.com
> >>
> >> wrote:
> >>
> >> Actually I have 2 example use cases:
> >>>
> >>> 1) user selects files on file tree
> >>> 2) as soon as file is selected and download is enabled for it, used
> >>> can
> >>> press ajax download button and get the file
> >>>
> >>> Another case:
> >>> User requests system backup
> >>> As soon as backup is created (Progress complete)
> >>> Download of newly created file should be initiated
> >>>
> >>> I can't create ResourceReference and override getResourceStream of
> it
> >>>
> >> since
> >
> >> I only have resource just before download
> >>>
> >>> Wicket IResource is an abstraction over the real resource.
> >> In my case i also create the response on the fly. It is either a
> >> single
> >> File or a Zip file with several entries.
> >> The ResourceReference is more or less just an endpoint with almost
> no
> >>
> > logic
> >
> >> at all. It just creates the IResource.
> >> The IResource uses the information from the request parameters /
> >> session
> >>
> > /
> >
> >> somewhere else to create the actual response (the files).
> >>
> >> AjaxDownload is an Ajax behavior that you can use to trigger the
> >> creation
> >> of the files and by using its callback methods you can show feedback
> >> to
> >>
> > the
> >
> >> user. To show progress bar you will need to employ ProgressBar from
> >> wicket-extentions or use WebSockets.
> >>
> >>
> >> On Wed, Mar 22, 2017 at 6:53 PM, Martin Grigorov <
> >>> 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Maxim Solodovnik]

Filename is minor issue 
Main problem is invalid file :(

How can I serve the file from file system? I thought filesystemreference if
the best candidate .

WBR, Maxim
(from mobile, sorry for the typos)

On Mar 29, 2017 8:08 PM, "Sven Meier"  wrote:

> Hi Maxim,
>
> three things:
>
> - filename ... no one sets the file name :P
>
> - serializable error ... FileSystemResource holds a reference to the path,
> which is not serializable
>
> - corruct zip ... my bad, it seems that Location.Blob mangles the file on
> the client side
>
> I'll see what I can do about Location.Blob - it might be an encoding issue.
>
> Have fun
> Sven
>
>
> On 29.03.2017 14:15, Maxim Solodovnik wrote:
>
>> here you are: https://github.com/solomax/ajax-download
>> Absolutely don't understand what is going on :(
>>
>> On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik 
>> wrote:
>>
>>> Yep, zip file is valid
>>> Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
>>> Will try to create quickstart
>>>
>>> something extremely weird
>>>
>>> On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov 
>>> wrote:
>>>
 Hi Maxim,

 On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik <
 solomax...@gmail.com>
 wrote:

 Thanks a lot Martin for detailed explanation
> I do have this functionality working with old version of AjaxDownload
>
> And here is my first try to migrate to the new internal wicket
> AjaxDownload:
> https://github.com/apache/openmeetings/commit/
> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>
> I would appreciate if you can take a look at this tiny commit.
>
> Something really doesn't work as expected 
>
> Commited version behaves wrong:
> 1) file downloaded has wrong name
>
> You do not set file name anywhere!
 Keep a reference to the constructed ResourceResponse and call its
 #setFileName(...)


 2) is not valid zip file (cannot be opened)
>
> Is the backupPath representing a ZIP file ?


 3) for some reason I'm not able to get to breakpoint at line 115 [1]
>
> Put a breakpoint at AjaxDownload.ResourceBehavior#onResourceRequested()
 and
 see what happens


 Additionally I got NotSerializable exception in case I made "download"
> class final variable
>
> java.nio.file.Path is not Serializable!


 What am I doing wrong?
>
> [1] https://github.com/apache/openmeetings/commit/
> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
> 0a499c88998a93ceb51c347836aa6195R115
>
> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov  >
> wrote:
>
>> On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik <
>> solomax...@gmail.com
>>
>> wrote:
>>
>> Actually I have 2 example use cases:
>>>
>>> 1) user selects files on file tree
>>> 2) as soon as file is selected and download is enabled for it, used
>>> can
>>> press ajax download button and get the file
>>>
>>> Another case:
>>> User requests system backup
>>> As soon as backup is created (Progress complete)
>>> Download of newly created file should be initiated
>>>
>>> I can't create ResourceReference and override getResourceStream of it
>>>
>> since
>
>> I only have resource just before download
>>>
>>> Wicket IResource is an abstraction over the real resource.
>> In my case i also create the response on the fly. It is either a
>> single
>> File or a Zip file with several entries.
>> The ResourceReference is more or less just an endpoint with almost no
>>
> logic
>
>> at all. It just creates the IResource.
>> The IResource uses the information from the request parameters /
>> session
>>
> /
>
>> somewhere else to create the actual response (the files).
>>
>> AjaxDownload is an Ajax behavior that you can use to trigger the
>> creation
>> of the files and by using its callback methods you can show feedback
>> to
>>
> the
>
>> user. To show progress bar you will need to employ ProgressBar from
>> wicket-extentions or use WebSockets.
>>
>>
>> On Wed, Mar 22, 2017 at 6:53 PM, Martin Grigorov <
>>> mgrigo...@apache.org>
>>> wrote:
>>>
>>> Hi Maxim,

 I use the new AjaxDownload with a ResourceReference, i.e.
 AjaxDownload#AjaxDownload(org.apache.wicket.request.
 resource.ResourceReference,
 org.apache.wicket.request.mapper.parameter.PageParameters)
 The ResourceReference has

 public IResource getResource() {
  return new StatementDownloadResource();
 }

 StatementDownloadResource extends ResourceStreamResource and
 provides
 implementation of #getResourceStream(). There 

Re: Question regarding new AjaxDownload (WICKET-6286)

[Sven Meier]

Hi Maxim,

three things:

- filename ... no one sets the file name :P

- serializable error ... FileSystemResource holds a reference to the 
path, which is not serializable


- corruct zip ... my bad, it seems that Location.Blob mangles the file 
on the client side


I'll see what I can do about Location.Blob - it might be an encoding issue.

Have fun
Sven


On 29.03.2017 14:15, Maxim Solodovnik wrote:

here you are: https://github.com/solomax/ajax-download
Absolutely don't understand what is going on :(

On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik  wrote:

Yep, zip file is valid
Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
Will try to create quickstart

something extremely weird

On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov  wrote:

Hi Maxim,

On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik 
wrote:


Thanks a lot Martin for detailed explanation
I do have this functionality working with old version of AjaxDownload

And here is my first try to migrate to the new internal wicket
AjaxDownload:
https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f

I would appreciate if you can take a look at this tiny commit.

Something really doesn't work as expected 

Commited version behaves wrong:
1) file downloaded has wrong name


You do not set file name anywhere!
Keep a reference to the constructed ResourceResponse and call its
#setFileName(...)



2) is not valid zip file (cannot be opened)


Is the backupPath representing a ZIP file ?



3) for some reason I'm not able to get to breakpoint at line 115 [1]


Put a breakpoint at AjaxDownload.ResourceBehavior#onResourceRequested() and
see what happens



Additionally I got NotSerializable exception in case I made "download"
class final variable


java.nio.file.Path is not Serializable!



What am I doing wrong?

[1] https://github.com/apache/openmeetings/commit/
5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
0a499c88998a93ceb51c347836aa6195R115

On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov 
wrote:

On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik 
wrote:


Hi Maxim,

I use the new AjaxDownload with a ResourceReference, i.e.
AjaxDownload#AjaxDownload(org.apache.wicket.request.
resource.ResourceReference,
org.apache.wicket.request.mapper.parameter.PageParameters)
The ResourceReference has

public IResource getResource() {
 return new StatementDownloadResource();
}

StatementDownloadResource extends ResourceStreamResource and provides
implementation of #getResourceStream(). There I have a logic that

returns

either FileResourceStream or ZipResourceStream.

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

On Wed, Mar 22, 2017 at 12:30 PM, Maxim Solodovnik <

solomax...@gmail.com

wrote:


Just have tried to switch to this AjaxDownload component
And it seems I cannot find proper way to use it with dynamic file,

i.e.

previously
I created AjaxDownload,
added it to the page
then at the moment I know what file should be served, I set the

stream

and

initiate the download
(for example one of use cases: I need to create zip file

right now this seems to be impossible :(
Can you give me a hint how this dynamic nature can be implemented?


--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax

Re: Question regarding new AjaxDownload (WICKET-6286)

[Maxim Solodovnik]

here you are: https://github.com/solomax/ajax-download
Absolutely don't understand what is going on :(

On Wed, Mar 29, 2017 at 6:30 PM, Maxim Solodovnik  wrote:
> Yep, zip file is valid
> Breakpoint at AjaxDownload.ResourceBehavior#onRequest() is not hit :(
> Will try to create quickstart
>
> something extremely weird
>
> On Wed, Mar 29, 2017 at 2:22 AM, Martin Grigorov  wrote:
>> Hi Maxim,
>>
>> On Tue, Mar 28, 2017 at 11:06 AM, Maxim Solodovnik 
>> wrote:
>>
>>> Thanks a lot Martin for detailed explanation
>>> I do have this functionality working with old version of AjaxDownload
>>>
>>> And here is my first try to migrate to the new internal wicket
>>> AjaxDownload:
>>> https://github.com/apache/openmeetings/commit/
>>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f
>>>
>>> I would appreciate if you can take a look at this tiny commit.
>>>
>>> Something really doesn't work as expected 
>>>
>>> Commited version behaves wrong:
>>> 1) file downloaded has wrong name
>>>
>>
>> You do not set file name anywhere!
>> Keep a reference to the constructed ResourceResponse and call its
>> #setFileName(...)
>>
>>
>>> 2) is not valid zip file (cannot be opened)
>>>
>>
>> Is the backupPath representing a ZIP file ?
>>
>>
>>> 3) for some reason I'm not able to get to breakpoint at line 115 [1]
>>>
>>
>> Put a breakpoint at AjaxDownload.ResourceBehavior#onResourceRequested() and
>> see what happens
>>
>>
>>>
>>> Additionally I got NotSerializable exception in case I made "download"
>>> class final variable
>>>
>>
>> java.nio.file.Path is not Serializable!
>>
>>
>>>
>>> What am I doing wrong?
>>>
>>> [1] https://github.com/apache/openmeetings/commit/
>>> 5fa2c87f212e4eecdd1368f2ae7fa8762832838f#diff-
>>> 0a499c88998a93ceb51c347836aa6195R115
>>>
>>> On Thu, Mar 23, 2017 at 3:16 AM, Martin Grigorov 
>>> wrote:
>>> > On Wed, Mar 22, 2017 at 12:59 PM, Maxim Solodovnik >> >
>>> > wrote:
>>> >
>>> >> Actually I have 2 example use cases:
>>> >>
>>> >> 1) user selects files on file tree
>>> >> 2) as soon as file is selected and download is enabled for it, used can
>>> >> press ajax download button and get the file
>>> >>
>>> >> Another case:
>>> >> User requests system backup
>>> >> As soon as backup is created (Progress complete)
>>> >> Download of newly created file should be initiated
>>> >>
>>> >> I can't create ResourceReference and override getResourceStream of it
>>> since
>>> >> I only have resource just before download
>>> >>
>>> >
>>> > Wicket IResource is an abstraction over the real resource.
>>> > In my case i also create the response on the fly. It is either a single
>>> > File or a Zip file with several entries.
>>> > The ResourceReference is more or less just an endpoint with almost no
>>> logic
>>> > at all. It just creates the IResource.
>>> > The IResource uses the information from the request parameters / session
>>> /
>>> > somewhere else to create the actual response (the files).
>>> >
>>> > AjaxDownload is an Ajax behavior that you can use to trigger the creation
>>> > of the files and by using its callback methods you can show feedback to
>>> the
>>> > user. To show progress bar you will need to employ ProgressBar from
>>> > wicket-extentions or use WebSockets.
>>> >
>>> >
>>> >>
>>> >> On Wed, Mar 22, 2017 at 6:53 PM, Martin Grigorov 
>>> >> wrote:
>>> >>
>>> >> > Hi Maxim,
>>> >> >
>>> >> > I use the new AjaxDownload with a ResourceReference, i.e.
>>> >> > AjaxDownload#AjaxDownload(org.apache.wicket.request.
>>> >> > resource.ResourceReference,
>>> >> > org.apache.wicket.request.mapper.parameter.PageParameters)
>>> >> > The ResourceReference has
>>> >> >
>>> >> > public IResource getResource() {
>>> >> > return new StatementDownloadResource();
>>> >> > }
>>> >> >
>>> >> > StatementDownloadResource extends ResourceStreamResource and provides
>>> >> > implementation of #getResourceStream(). There I have a logic that
>>> returns
>>> >> > either FileResourceStream or ZipResourceStream.
>>> >> >
>>> >> > Martin Grigorov
>>> >> > Wicket Training and Consulting
>>> >> > https://twitter.com/mtgrigorov
>>> >> >
>>> >> > On Wed, Mar 22, 2017 at 12:30 PM, Maxim Solodovnik <
>>> solomax...@gmail.com
>>> >> >
>>> >> > wrote:
>>> >> >
>>> >> > > Just have tried to switch to this AjaxDownload component
>>> >> > > And it seems I cannot find proper way to use it with dynamic file,
>>> i.e.
>>> >> > >
>>> >> > > previously
>>> >> > > I created AjaxDownload,
>>> >> > > added it to the page
>>> >> > > then at the moment I know what file should be served, I set the
>>> stream
>>> >> > and
>>> >> > > initiate the download
>>> >> > > (for example one of use cases: I need to create zip file
>>> >> > >
>>> >> > > right now this seems to be impossible :(
>>> >> > > Can you give me a hint how this dynamic nature can be implemented?
>>> >> > >
>>> >> > >
>>> >> > > --
>>> >> > > WBR
>>> >> > >