Recent changes to bugs

Hard-coded dependency to SOJO

The light in the dark — Thu, 16 Jun 2011 09:05:45 -0000

The current implementation has a hard dependency to SOJO, that makes using the library with only JSON-LIB unachievable.
The offending class is the JsonView (DOH!), that creates an instance of the SojoJsonStringWriter, that depends on the net.sf.sojo.common.WalkerInterceptor, which is not even part of the sojo-optional, but the sojo core.

SOJO is not found in any maven repository, and it would be nice to be able to use it with JSON-Lib alone.

SimplePropertyFilter removes converters of ConvertUtilsBean

Gerardo Costilla — Fri, 30 Apr 2010 01:39:28 -0000

SimplePropertyFilter removes converters of ConvertUtilsBean

Summary: Removing the converters of ConvertUtilsBean is not wrong; however it's wrong to remove the converters of the instance that will be used by the static methods of BeanUtils, since this methods are used all around web applications and expect the default behavior provided by all the converters, included the ones that SimplePropertyFilter removes.

SimplePropertyFilter does a number of funny things that are OK or not depending on the environment. In my environment the funny things that SimplePropertyFilter do end up being very wrong. Let's go into the details: Since there's a number of ways to filter properties, very conveniently JsonView can be configured with any kind of custom property filter; however, because of the way
1) SimplePropertyFilter behaves during initialization and then 2) because of the way JsonView is initialized when its class is loaded by the JVM, setting a custom property filter is not enough to stop SimplePropertyFilter polluting the static configuration of BeanUtils.

As described, any kind of JsonViewFilter (any class implementing JsonViewFilter) can be used to configure JsonView; however even after specifying a custom JsonViewFilter for JsonView

still the JVM will end up intanciating SimplePropertyFilter. How? JsonView has a 'jsonViewFilter' class attribute that is initialized with a new instance of SimplePropertyFilter. Before Spring has a chance to wire JsonView, the JVM has already instantiated SimplePropertyFilter. Why? because the first thing that the JVM does whenever it loads a class is setting its class attributes,

public class JsonView extends AbstractView {
private static final String DEFAULT_ENCODING = "UTF-8";

...
// Even if we set a custom jsonViewFilter with spring,
// the piece of code inside of the constructor of SimplePropertyFilter
// will be executed.
--> private JsonViewFilter jsonViewFilter = new SimplePropertyFilter();
...
}

which is not a big deal per se; however SimplePropertyFilter does a number of things that end up messing the configuration of my web application badly, very badly. How? I'll try to put it as simply as I can:

In order to filter properties that are not to be serialized, SimplePropertyFilter sets null values into the attributes of the model that are to be filtered. The JSON serializer won't serialize attributes with null values and this is how attributes that are to be filtered are filtered.

Now, ConvertUtilsBean (org.apache.commons.beanutils.ConvertUtilsBean) registers converters for all primtives during intialization; however the converters are initialized to use default values when null values are used. e.g. BooleanConverter (org.apache.commons.beanutils.converters.BooleanConverter) will use the default value 'false' whenerver it is asked to convert 'null':

public final class BooleanConverter implements Converter {
...
public BooleanConverter(Object defaultValue) {
this.defaultValue = defaultValue;
----- > this.useDefault = true; // will use 'false', as instructed by
}
...
}

public class ConvertUtilsBean {
...
private Boolean defaultBoolean = Boolean.FALSE;
...
public ConvertUtilsBean() {
converters.setFast(false);
deregister();
converters.setFast(true);
}

public void deregister() {
...
----- > register(Boolean.TYPE, new BooleanConverter(defaultBoolean)); //use 'Boolean.FALSE'
...
}
...
}

Since SimplePropertyFilter wants to set null values to the attributes of the model that are to be filtered, it doesn't want the converters that behave like BooleanConverter, already shown, to be used. This way, SimplePropertyFilter removes the converters for Boolean, Character, Double, etc:

public class SimplePropertyFilter implements JsonViewFilter{
...
public SimplePropertyFilter(){
setUpBeanUtils();
}

protected void setUpBeanUtils() {
----- > ConvertUtilsBean cub = BeanUtilsBean.getInstance().getConvertUtils();
cub.deregister(Boolean.class);
cub.deregister(Boolean.TYPE);
cub.deregister(Byte.class);
cub.deregister(Byte.TYPE);
cub.deregister(Character.class);
cub.deregister(Character.TYPE);
cub.deregister(Double.class);
cub.deregister(Double.TYPE);
cub.deregister(Float.class);
cub.deregister(Float.TYPE);
cub.deregister(Long.class);
cub.deregister(Long.TYPE);
cub.deregister(Short.class);
cub.deregister(Short.TYPE);
}
...
}

This is a very incorrect thing to do, since one of the application lifecycle listeners for my web application also use the singleton instance of ConvertUtilsBean to read the configuration of a number of resources. Have a look at this stack trace that shows how One of the lifecycle listeners configured for my web application, when executed by the Weblogic webapp initialization routine, use the singleton instance of BeanUtilsBean.

Daemon Thread [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] (Suspended (entry into method getInstance in BeanUtilsBean))
BeanUtilsBean.getInstance() line: 80
PropertyUtilsBean.getInstance() line: 114
PropertyUtils.getPropertyDescriptor(Object, String) line: 460
BeanPropertySetterRule.end(String, String) line: 189
Digester.endElement(String, String, String) line: 1332
SAXParserImpl$JAXPSAXParser(AbstractSAXParser).endElement(QName, Augmentations) line: not available
XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanEndElement() line: not available
XMLDocumentScannerImpl$ContentDispatcher(XMLDocumentFragmentScannerImpl$FragmentContentDispatcher).dispatch(boolean) line: not available
XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) line: not available
XIncludeAwareParserConfiguration(XML11Configuration).parse(boolean) line: not available
XIncludeAwareParserConfiguration(XML11Configuration).parse(XMLInputSource) line: not available
SAXParserImpl$JAXPSAXParser(XMLParser).parse(XMLInputSource) line: not available
SAXParserImpl$JAXPSAXParser(AbstractSAXParser).parse(InputSource) line: not available
SAXParserImpl$JAXPSAXParser.parse(InputSource) line: not available
Digester.parse(InputSource) line: 1863
...
<My Web Application Lifecycle listeners>
...
EventsManager$FireContextListenerAction.run() line: 376
AuthenticatedSubject.doAs(AbstractSubject, PrivilegedAction) line: 321
SecurityManager.runAs(AuthenticatedSubject, AuthenticatedSubject, PrivilegedAction) line: 121
EventsManager.notifyContextCreatedEvent() line: 82
WebAppServletContext.preloadResources() line: 1609
WebAppServletContext.start() line: 2764
WebAppModule.startContexts() line: 889
WebAppModule.start() line: 333
ModuleStateDriver$3.next(Object) line: 204
StateMachineDriver.nextState(StateChange, Object[]) line: 26
ModuleStateDriver.start(Module[]) line: 60
ScopedModuleDriver.start() line: 200
ModuleListenerInvoker.start() line: 117
ModuleStateDriver$3.next(Object) line: 204
StateMachineDriver.nextState(StateChange, Object[]) line: 26
ModuleStateDriver.start(Module[]) line: 60
StartModulesFlow.activate() line: 26
BaseDeployment$2.next(Object) line: 635
StateMachineDriver.nextState(StateChange, Object[]) line: 26
WarDeployment(BaseDeployment).activate(DeploymentContext) line: 212
DeploymentStateChecker.activate(DeploymentContext) line: 154
AppContainerInvoker.activate(DeploymentContext) line: 80
AppDeployment(BasicDeployment).activate(DeploymentContext) line: 181
AppDeployment(BasicDeployment).activateFromServerLifecycle() line: 358
DeploymentAdapter$1.doActivate(Object) line: 52
DeploymentAdapter$1(DeploymentAdapter).activate(Object) line: 186
AppTransition$2.transitionApp(DeploymentAdapter, Object) line: 30
ConfiguredDeployments.transitionApps(AppTransition) line: 233
ConfiguredDeployments.activate() line: 169
ConfiguredDeployments.deploy() line: 123
DeploymentServerService.resume() line: 173
DeploymentServerService.start() line: 89
SubsystemRequest.run() line: 64
ExecuteThread.execute(Runnable) line: 209
ExecuteThread.run() line: 181

Recapitulating, whenver the JVM loads the class definiton of JsonView, it also intantiates SimplePropertyFilter, in order to initialize the class members of the former and once this happens, the any future use of BeanUtils will be polluted, since some of the converters that are expected to work, won't work at all, because they have been removed by the initialization routine of SimplePropertyFilter.

OK good enough, let's fix this: let SimplePropertyFilter do its thing; however it should't mess up the singleton instance of ConvertUtilsBean that is going to be used all across the application but should configure it's private instance so that it doesn't end up polluting the instance that, again, will be used by all the static methods of BeanUtilsBean.

public class SimplePropertyFilter implements JsonViewFilter{

...

// we have a new instance of BeanUtilsBean to be used locally
private BeanUtilsBean beanUtilsBean;

...

protected void setUpBeanUtils() {
// DO NOT mess up with the singleton instance of ConvertUtilsBean but:
//ConvertUtilsBean cub = BeanUtilsBean.getInstance().getConvertUtils();

// 1) create our own, configure it as we need it and
ConvertUtilsBean convertUtilsBean = new ConvertUtilsBean();
convertUtilsBean.deregister(Boolean.class);
convertUtilsBean.deregister(Boolean.TYPE);
convertUtilsBean.deregister(Byte.class);
convertUtilsBean.deregister(Byte.TYPE);
convertUtilsBean.deregister(Character.class);
convertUtilsBean.deregister(Character.TYPE);
convertUtilsBean.deregister(Double.class);
convertUtilsBean.deregister(Double.TYPE);
convertUtilsBean.deregister(Float.class);
convertUtilsBean.deregister(Float.TYPE);
convertUtilsBean.deregister(Long.class);
convertUtilsBean.deregister(Long.TYPE);
convertUtilsBean.deregister(Short.class);
convertUtilsBean.deregister(Short.TYPE);

// 2) use it for creating a new instance of BeanUtilsBean that will be used
// to filter attributes as required
beanUtilsBean = new BeanUtilsBean(convertUtilsBean, new PropertyUtilsBean());
}

...

protected void removePropertyValue(Map model, String property, String commandName) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException{
String p = null;
if(property.matches("^\$.+\$|^\$.+\$\\..+"))
p = property.replaceFirst("\$", "").replaceFirst("\$", "");
else
p = new StringBuilder().append(commandName).append(".").append(property).toString();

try{

if(log.isDebugEnabled())log.debug(p +" = " + BeanUtils.getProperty(model, p));
// DO NOT use the singleton instance that will use the unconfigured instance of BeanUtilsBean but,
// BeanUtils.setProperty(model, p, null);

// use our private instance of BeanUtilsBean, that has a configured instance of ConvertUtilsBean
beanUtilsBean.setProperty(model, p, null);
if(log.isDebugEnabled())log.debug(p +" set to " + BeanUtils.getProperty(model, p));
if(log.isDebugEnabled())log.debug("======================================");
}catch(Exception e){
if(log.isDebugEnabled())log.debug("Error excluding property: " + p + ": " + e.toString());
}
}

...

};

Versions above 1.0 won't return to callback function

djdemarco — Fri, 26 Mar 2010 03:49:12 -0000

I have posted this at: http://forum.springsource.org/showthread.php?t=86787

Basically, I'm trying to submit a form through AJAX and the form contains several fields including a file input field. With version 1.0, the javacript callback function is executed after the server returns a JSON data response. But with higher versions, the JSON data is streamed back to the client and the javascript callback function is never executed at all. It's as if I'm downloading an HTML file that contains the JSON data. I'm not exactly sure if this is an issue on spring-json or json-lib.

XStreamWriter Serialize null values in Collections as null

Kai Ulrich — Tue, 08 Dec 2009 12:51:21 -0000

XStreamWriter : Serialize null values in Collections as 'null' not '{}'

Booleans become String literals instead of JS-Booleans

Christian Kalkhoff — Mon, 07 Sep 2009 14:21:17 -0000

From version 1.2 on there is a bug in the serialization of Boolean (The object) values. It gets written into JSON as prop:"true" instead of prop:true which results in "false" becoming true in JS

BindingResult getting added to outbound model

Anonymous — Sat, 05 Sep 2009 00:17:44 -0000

If there is a DataBinder associated with the request, it is getting added to the outbound model and rendered into the Json. If my command object is named "command" the BindingResult gets added with the key "org.springframework.validation.BindingResult.command" and a value of :{"messageCodesResolver":{"prefix":""},"nestedPath":""}

This is with the SojoJsonStringWriter. Setting that key as an exclude via the following code also has no effect whatsoever:

JsonWriterConfiguratorTemplateRegistry registry = JsonWriterConfiguratorTemplateRegistry.load(request);
registry.registerConfiguratorTemplate(
new SojoJsonWriterConfiguratorTemplate(){
@Override
public SojoConfig getJsonConfig() {
SojoConfig config= new SojoConfig();
String[] excludes = new String[] {
"org.springframework.validation.BindingResult.command"
};
config.setExcludedProperties(excludes);
return config;
}
}
);

If I use JsonlibJsonStringWriter instead of the sojo writer,it throws an exception because of a cycle in the object graph. This problem has existed in the jsonlib writer for at least 8 or 9 months and the last time I investigated it, the cycle was a result of the HttpServletRequest being part of the BindingResult. I don't remember which property of the request generated the cycle but it shuld be easy enough to track down. I actually abandoned the use of jsonlib writer because of this issue, though I was able to correct it by modifying the writer config and ignoring all objects of class BindingResult.

It seems to me that putting the BindingResult directly into the output is a bug.

booleans in sojostringwriter

Anonymous — Mon, 29 Jun 2009 09:55:50 -0000

If a class that is converted to json contains booleans they won't be available in your json object when your getter is 'isVariable', but it has to be 'getVariable'.

Project Repository Broken

Chris Widhelm — Fri, 29 May 2009 17:07:08 -0000

The "Project Repository" listed in the downloads section of the maven generated site does not work.

News without dates

Chris Widhelm — Fri, 29 May 2009 17:06:31 -0000

On the website there are no dates in the news section. It is hard to tell if the "news" is new news or old news.

v1.2 in Maven Repo

Chris Widhelm — Fri, 29 May 2009 17:05:52 -0000

When will v1.2 be added to the main maven repository?