A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string. A string is very much like a C or Java string.This means that you may have a valid JSON key but and invalid Java identifier when transforming form JSON to Java. In order to avoid this problem, Json-lib defines a set of helpers of type JavaIdentifierTransformer that will handle the following cases:
JsonConfig.setJavaIdentifierTransformer()
fromObject
of
JSONObject&JSONArray, all you have to do is enabled event triggering on JsonConfig. The following is a list of events
generated by the build process: start/end (object), start/end (array), propertySet( object), elementAdd (array), warning, error.
fromObject
or with the JSONSerializer you may skip all transient fields of the source
bean, provided that the name of the property returned from the PropertyDescriptor matches the name of the field, meaning that
this option will not work if you have a BeanInfo that changes the name of a read method or provides a synthetic property.
When serializing to JSON there may be some times where you would like to exclude some properties from being processed, the current exclusion mechanism matches the property name to a list of Strings, but what if you would like to filter out all properties that match a regex or extend a particular class? PropertyFilter will help you attain that goal with ease, and what's more, it will also work when converting back to Java. Here is an example filter that will exclude all properties that are a Number when serializing to JSON:
This is another filter example, this time converting back to Java, it will filter out any property named 'bool' or 'integer':
Please review the net.sf.json.filters
package to find out more about default filters and composite filters.
JsonBeanProcessor
s are maped to classes but sometimes you'll like that some subclasses may be mapped to the same
processor or perhaps you are serializing a recently hydrated instance coming from a database with Hibernate, because the instance's
class is not exactly the one you expect (it actually is a cglib proxy class) the default class matching mechanism will not work.
In order to solve these problems you may register a JsonBeanProcessorMatcher
that will take care of the job of selecting
the proper JsonBeanProcessor
, just as you need it.
java.sql.Timestamp
. Json-lib has an option
to overcome this "restriction", just register a NewBeanInstanceStrategy
into JsonConfig and you are in business.
DefaultValueProcessor
will let you change that rules, along with DefaultValueProcessorMatcher
which will let you select the most
appropriate processor, as it is done with JsonBeanProcessors.
PropertySetStrategy
through JsonConfig. This feature comes in handy
with map backed beans that are neither a Map nor a DynaBean.