Relative paths (java.nio.file.Path) are serialized as absolute.

[yiding]

As pointed out in #1264, relative paths are serialized as absolute by virtue of the fact that the new URI-based path serializer introduced in #1235.

[cowtowncoder]

PRs welcome.

[ittaiz]

This was closed due to in-activity, right?
As far as I can see this is still the current behavior.
I'm trying to see how this can be solved. I first tried to understand the motivation of #1235 and I think (not sure) that the problem they had was that the previous implementation only worked for the default file-system. Is that right?
Reason I'm only half sure is because the Deserializer uses Paths.get which is bound to the default file-system.
On the other hand I can't understand what problem was solved.

Looking at the code it seems I can just drop the uri intermediate parts and support relative paths but I'd rather not do that before I understand #1235

[cowtowncoder]

@ittaiz I'll invoke @bimargulies since he knows the reasoning and can hopefully offer a more informed opinion.

As to closing: the original issue did suggest a problem, but there was no follow-up and I unfortunately do not know what could or should be done (including questions like whether relative paths are reliably transferable).

[bimargulies]

Paths.get(URI) is not restricted to the default file system, it works for any registered file system. Note the jimfs tests in the patch. If you want to serialize and deserialize arbitrary file systems' paths, I think there needs to be a URI in the path. It might be possible for it to be relative, I'm not in this neighborhood any longer.

[ittaiz]

I did not know Paths.get isn't bound to the default file system. Thanks for that information, I was probably misinformed. @cowtowncoder I'll leave this be for now since I solved it for my use case but I guess that if relative conflicts with non default file systems then one should be able to toggle the behavior

[cowtowncoder]

Ok. I am open to improvement ideas, but one challenge is that as things are, there's really no good way for configuring type-specific aspects -- so ideally one could use one of general mechanisms of @JsonFormat annotation (for example; can be applied via "config overrides", not just annotation).
For example, perhaps lenient property there could allow relative paths? Or something.

Still, it'd be also necessary to know what expected alternative behaviors are.

So in some sense I almost think maybe users would be expected to provide their custom serializers here. Anyway, I am open to suggestions.

[ittaiz]

I suggest we keep to custom serializer (maybe have one in the library to ease people) until we have a clearer or stronger usecase. Wdyt?

…

On Mon, 12 Jun 2017 at 20:10 Tatu Saloranta ***@***.***> wrote: Ok. I am open to improvement ideas, but one challenge is that as things are, there's really no good way for configuring type-specific aspects -- so ideally one could use one of general mechanisms of @jsonformat annotation (for example; can be applied via "config overrides", not just annotation). For example, perhaps lenient property there could allow relative paths? Or something. Still, it'd be also necessary to know what expected alternative behaviors are. So in some sense I almost think maybe users would be expected to provide their custom serializers here. Anyway, I am open to suggestions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1422 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF5o6hytjXNDIBFOMaIsRzyRckjrNks5sDXEAgaJpZM4KZRwZ> .

[cowtowncoder]

It might be worth considering possibility of some kind of "sandbox" or "util" library that could contain alternate handlers to use. I don't think such handlers should be contained in standard databind, unless they can be nicely integrated, but I have nothing against add-on lib/repo.

[ittaiz]

Do you want to open such a library (naming and machinery wise) and I'll add the ser/Feder plus test to it?

…

On Tue, 13 Jun 2017 at 3:07 Tatu Saloranta ***@***.***> wrote: It might be worth considering possibility of some kind of "sandbox" or "util" library that could contain alternate handlers to use. I don't think such handlers should be contained in standard databind, unless they can be nicely integrated, but I have nothing against add-on lib/repo. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1422 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF1PEzBY6AaYXkcGqeKO2qIf02kK4ks5sDdKvgaJpZM4KZRwZ> .