Here is an alternative specific to JSON with Padding. Since we are
depending on Jackson then perhaps Jersey's JSONWithPadding class can
extend from a Jackson/JAX-RS class json with padding class that has a
Jackson/JAX-RS provider (essentially we could move the implementation
from Jersey to Jackson?)
Jackson could also support escaping of JSON content when combined with
JSON with padding or full XSS protection (something we have not
implemented yet for JAXB/JSON).
Paul.
On Jan 22, 2010, at 9:43 PM, Tatu Saloranta wrote:
> On Fri, Jan 22, 2010 at 2:16 AM, Jakub Podlesak <Jakub.Podlesak_at_sun.com
> > wrote:
> ...
>>> Additionally, if there was a good way to pass per-request
>>> information,
>>> jackson provider could quite easily add necessary prefix (json
>>> function name, open-paren) before output, and suffix (close-paren)
>>> afterwards. But it would have to know when to do this (and with what
>>> function name).
>>
>> From Jersey standpoint, the issue is not that Jackson does not have
>> the capability
>> to serialize from Java to JavaScript, but that in this case it
>> serializes (from Java to JSON)
>> also data not intended for serialization.
>
> Ok. What does the wrapper object look like? There might be a way to
> handle it specifically.
>
>> What could help would be a way to tell Jackson to filter incoming
>> Java objects
>> before processing. If Jackson e.g. provides a way to register a
>> simple filter
>>
>> public interface Filter {
>> public Object filter(Object o);
>> }
>>
>> Jersey could implement and register such a filter for the
>> JSONWithPadding wrapper,
>> which would leave all other objects intact.
>>
>> I think the filter thing would be quite generic, so that it could
>> be used also for another
>> purpose if something appears in the future.
>>
>> Would it work for you?
>
> There is no direct support for that, although recent (1.4) work for
> JsonView did open up some possibilities for filtering. It could be
> used, but would still require bit of custom (used by jersey) code,
> either custom serializer/deserializer for wrapper type, or bean
> factory overrides.
>
> But in general this sounds like the way to go, if wrapper type is
> always the same (or can be auto-detected easily). Might require some
> changes to jackson jax-rs provider, perhaps to support jersey-specific
> sub-class (or add on if need be).
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>