Paths not serializable

Discussion:

sorinev

2018-06-13 19:48:16 UTC

I created a quickstart for this, but I imagine you're long since aware of it.
But, what am I supposed to do about sun.nio.fs.UnixPath throwing a
java.io.NotSerializableException (passed in to FileSystemResourceReference)?
The page still works, but the server log gets really nasty, really quick,
especially since I rely on FileSystemResourceReference extensively for a lot
of images being displayed on a central page of my site (I use the file
system for images, instead of my war file, because otherwise the war file
would be 300MB and harder to maintain).

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Sven Meier

2018-06-13 20:36:54 UTC

Permalink

Hi,

create your FileSystemResourceReference without the path argument and
override #getResource():

    @Override
    public IResource getResource()
    {
        return new FileSystemResource(/* --- create a path --- */);
    }

Have fun
Sven

Post by sorinev
I created a quickstart for this, but I imagine you're long since aware of it.
But, what am I supposed to do about sun.nio.fs.UnixPath throwing a
java.io.NotSerializableException (passed in to FileSystemResourceReference)?
The page still works, but the server log gets really nasty, really quick,
especially since I rely on FileSystemResourceReference extensively for a lot
of images being displayed on a central page of my site (I use the file
system for images, instead of my war file, because otherwise the war file
would be 300MB and harder to maintain).
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
---------------------------------------------------------------------

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

sorinev

2018-06-13 21:23:15 UTC

Permalink

Perfect, that worked. What's the side effect of this vs the other way, if
any?

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Maxim Solodovnik

2018-06-14 01:21:20 UTC

Permalink

You can have String path (instead of Path path)
And it will works as expected :)

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

Post by sorinev
Perfect, that worked. What's the side effect of this vs the other way, if
any?
--
http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
---------------------------------------------------------------------

Martin Grigorov

2018-06-14 05:50:30 UTC

Permalink

With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

Tobias Soloschenko

2018-06-14 16:25:18 UTC

Permalink

+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.

kind regards

Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

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

Sven Meier

2018-06-14 17:49:58 UTC

Permalink

Hi,

a model doesn't make too much sense here, because references don't get
detached.

I find the usage of a model here and in FileSystemResource a little
misleading:
Yes, the LDM will drop the reference once it is serialized (because of
its transient reference),
but it is 'detached' explicitly in #respond() only, which doesn't
actually happen until the resource is fetched in a different request.

Have fun
Sven

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

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

Tobias Soloschenko

2018-06-15 04:03:05 UTC

Permalink

Hi,

so you suggest that we may should use only serializable objects as arguments?

The TextTemplateResourceReference is also using a Model.

So maybe we should refactor all to not use models at all?

https://ci.apache.org/projects/wicket/apidocs/8.x/org/apache/wicket/request/resource/ResourceReference.html

In my opinion there should be a unified way for all RR.

kind regards

Tobias

Hi,
a model doesn't make too much sense here, because references don't get detached.
Yes, the LDM will drop the reference once it is serialized (because of its transient reference),
but it is 'detached' explicitly in #respond() only, which doesn't actually happen until the resource is fetched in a different request.
Have fun
Sven

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

Sven Meier

2018-06-18 19:13:06 UTC

Permalink

Hi Tobias,

thanks, I wasn't aware of TextTemplateResourceReference.

IMHO it doesn't uses a modus operandi we would want to endorse, i.e. it
doesn't detach its model and I don't see a good way to do that anyway.

But it shows the difficulty in posing any rules for RR: If the
resourceReference is registered in the application, it doesn't need to
be serializable. Only if it is kept in the component tree, it has to be
serializable.
The same holds for IResources.

Have fun
Sven

Post by Tobias Soloschenko
Hi,
so you suggest that we may should use only serializable objects as arguments?
The TextTemplateResourceReference is also using a Model.
So maybe we should refactor all to not use models at all?
https://ci.apache.org/projects/wicket/apidocs/8.x/org/apache/wicket/request/resource/ResourceReference.html
In my opinion there should be a unified way for all RR.
kind regards
Tobias

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

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

Tobias Soloschenko

2018-06-18 22:15:11 UTC

Permalink

Hi Sven,

I would suggest to deal with the worst scenario for RR and IResource and implement all accordingly.

So we may use a Model / LoadableDetachableModel in case of someone holds the RR / IResource within the component tree.

WDYT?

kind regards

Tobias

Post by Sven Meier
Hi Tobias,
thanks, I wasn't aware of TextTemplateResourceReference.
IMHO it doesn't uses a modus operandi we would want to endorse, i.e. it doesn't detach its model and I don't see a good way to do that anyway.
But it shows the difficulty in posing any rules for RR: If the resourceReference is registered in the application, it doesn't need to be serializable. Only if it is kept in the component tree, it has to be serializable.
The same holds for IResources.
Have fun
Sven

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

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

Sven Meier

2018-06-21 13:07:32 UTC

Permalink

Hi Tobias,

I'n not sure what's the best solution for this :/.

IMHO this isn't a crucial issue atm, since we won't be able to do API
changes in 8.x anyways.

For 9.x we'll have a lot of time to do it right.

Have fun
Sven

Post by Tobias Soloschenko
Hi Sven,
I would suggest to deal with the worst scenario for RR and IResource and implement all accordingly.
So we may use a Model / LoadableDetachableModel in case of someone holds the RR / IResource within the component tree.
WDYT?
kind regards
Tobias

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

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

Tobias Soloschenko

2018-06-21 13:49:00 UTC

Permalink

Hi Sven,

so we may create a ticket for this. :-)

kind regards

Tobias

Post by Sven Meier
Hi Tobias,
I'n not sure what's the best solution for this :/.
IMHO this isn't a crucial issue atm, since we won't be able to do API changes in 8.x anyways.
For 9.x we'll have a lot of time to do it right.
Have fun
Sven

Post by Tobias Soloschenko
+1 - at this time I was not aware of what all has to be serializable. So yep I would suggest to use the Model at this place, too.
kind regards
Tobias

Post by Martin Grigorov
With WICKET-6504 we improved FileSystemResource to use
LoadableDetachableModel<Path> instead of just path.
Maybe the same should be done for the ResourceReference too ?

Post by Maxim Solodovnik
You can have String path (instead of Path path)
And it will works as expected :)
WBR, Maxim
(from mobile, sorry for the typos)

---------------------------------------------------------------------

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