Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
see original conversation:
http://jackson-users.ning.com/forum/topics/nested-json-via-url-references
use case:
1) there is a need to store multiple related configurations in terracotta server
http://code.google.com/p/terrastore/
which is a clustered json document store
2) for example, this url would return full configurations:
http://server/configurations/conf_01
http://server/configurations/conf_02
3) and this url would return components of full configs:
http://server/components/comp_01
http://server/components/comp_02
http://server/components/comp_03
4) the idea is that full configurations can refer to the components like this:
conf_01.json:
{
// in this case the component definition is embedded in the parent file
compA :
// and now component refers to external resource:
compB : http://server/components/comp_02
}
conf_02.json:
// both subcomponents are ferfferring to the external components resources
5) suggested basic logic: this is what comes to mind:
a) if the target java field type is string - do not try to dereference;
i.e. for:
class Test
{ String field; }test1.json { field : this-any-string }
and
test2.json { field : http://this-looks-like-url }
will just produce string
b) if the target java field type is NOT string - DO dereference;
class Test { Address address; }
class Address { String field; }
// this is doing normal de-serialization
test1.json
{ address :
}
test2.json
{ address : file://./external-resource.json }c) too bad string properties can not be url-ed; may be there is way for that?
6) probably has to treat "basedir" or "./" specially, like in http references,
relative to the location of the current document. to avoid absolut urls and enforce
for example that config stays on the same server / in the same folder;
7) may be there is an "official markup" in json for this kind of thing?
or some js libraries like jquery do this in some kind of "standard way"?
I can not imagine I am the first to ask for this 
Activity
Actually, Jackson supports object inheritance with polymorphic type information.
As to automatic resolution; I think this would work best as a property annotation, something like:
@JsonResolve // and maybe allow custom resolver; but default to one that assumes JSON String -> URL
public ConfigObject config;
which would require JSON String value, try to make URL out of it; and use it as relative or absolute (relative resolved via declared source, i.e. JsonParser MUST have been constructed with URL, File or such; may need to add a way to set "base URL", similar to XML.
Trying to auto-detect URLs from values is something that sounds like dangerous thing to do; I am not really sure that would be right thing to do. Of course one could offer a feature to enable such handling, so that if a JSON String is seen, and a POJO is expected, try resolution is a fallback.
This is highly speculative but... well, might be useful. If so, I'd probably want to add bit more generic callback to register. Challenge here is that Strings are valid things to pass to single-string-arg constructor, so would need to figure out what to do with that conflict.
Implementing this is in the edge of things that Jackson might offer; I am not yet 100% if it falls within scope or not. But it might, so why not think of how to do it.
re: "@JsonResolve" - this sounds good already; I do not think I could do it myself; I tried to delve into your source - that's too much!
also , I would assume that resolution is optional? that is, if definition is provided - used it
if not - try to go after url, if url lookup/parse fails - then really fail?
re: "need to add a way to set "base URL", similar to XML." you mean inside json content or as a feature/property to the mapper?
for my use case support limited for FILE & URL are just fine
re: "feature to enable such handling" - feature sounds good, and protects who feel endangered
re: "so why not think of how to do it" - well if you do not see how to do it, I am at loss
but why dont you try make something easy enough for you to make, I will test if for my cases,
and I will produce bunch of unit tests for you!
or link me to exmaples so I continue do digest your sources...
finally, why do you think it is dangerous? you are like #1 expert on json now;
why dont you just create new tag/feature/etc in json
and tell the world this is how json will be now
Tatu:
I made like 3 attempts on this - but got lost in jackson jungle every time ;
any chance to get some basic sample from you so I could imporve on?
thank you;
Andrei.
I can try something in 2 weeks or so, after I come back from my vacation.
and of course next natural idea which comes to mind is provide json inheritance, like maven pom.xml which has a parent, etc.
come on, if you serializing classes, then json docs also have inherit!