I have a problem with serialization of "is getter" accessor to property name.
I have a class with boolean isState() accessor method and property with name isState.
During serialization I see that object mapper is convert isState() method as state property.
Of course I can use #JsonProperty annotation but I need to do it generically for all such cases.
Before jackson-databind 2.12.0 it worked, unfortunately it stopped now because AccessorNamingStrategy has been added with a new way to find field names for getters. I can extend the AccessorNamingStrategy class and change the way to find field names, but it's too much code duplication to achieve such a minor goal. Issue: Extract getter/setter/field name mangling from 'BeanUtil' into pluggable 'AccessorNamingStrategy'
I tried to fight setAccessorNaming because it came out from version 2.12.0 and setPropertyNamingStrategy but unfortunately with poor results.
Edit:
I was able to fix the problem like this (image), if anyone has something better please let me know.
Related
I tried enabling the -parameters flag in a project in order to use the JDBI ConstructorMapper without having to annotate each parameter.
What I then discovered was that the Jackson serialization changed behavior. I have been able to identify two things that have changed, but I have been unable to find any documentation on it.
When using the JsonCreator with mode default it now defaults to mode PROPERTIES when before it defaulted to mode DELEGATING. I now have to set this explicitly.
When using JsonProperty on a constructor parameter, that name is also kept when serializing the object. It used to serialize to the getter name, unless anything else was specified.
Are these all the changes to Jackson behavior? Also, are there any global settings I can change, so that I don't have to add lots of new annotations to my codebase?
I have tried looking for documentation, but it is hard to find the correct search terms.
I am working on a project that has a fair amount of data objects that use a "fluent interface" or "method chaining" on their setters so all of the setters in each data object return this. I have looked around and found this question, but it is unclear to me whether this can be used with Yaml as the annotations specifically mention JSON, and also this seems to enable mapping to objects using an actual builder pattern, which is a little different. The project is currently using SnakeYaml, but that can be tossed away if some other lib like Jackson can do this.
It turns out that this is in fact possible. Jackson supports yaml and will work with builder style setters by default without any extra configuration.
After having invested a lot of hours in more than couple of days, I am finally giving up on this. But just to make sure that I am not missing anything, I would like to have your opinion.
So the example xml looks like this
<Query>
<SpecialFilter1>
<SpecialExpression1>some_text</SpecialExpression1>
<SpecialExpression1>some_text</SpecialExpression1>
<SpecialExpression2>some_other_text</SpecialExpression2>
<SpecialExpression2>some_other_text</SpecialExpression2>
</SpecialFilter1>
<SpecialFilter2>
<SpecialExpression1>some_text</SpecialExpression1>
</SpecialFilter2>
</Query>
Accompanying sample code is here in a Github Gist https://goo.gl/nwJWfs
The restriction with XML for me is, it is not possible to have some attribute or other element to specify class information for deserialization. That is why it has to be solved purely via code.
This code fails at deserialization because query class does not have information about property "SpecialFilter1", it only knows about base class.
I have tried many permuation-combinations for JsonTypeInfo.Id and JsonTypeInfo.As. I also tried both custom JsonTypeIdResolver and JsonTypeResolverBuilder.
In the end I got partial success with combination of custom JsonTypeResolverBuilder and DeserializationProblemHandler, by using findContextualValueDeserializer() of deserialization context in handleUnknownProperty(). But this looks very dirty and also serialization has its own zillion issues in this way.
Update 1:
After having rejected the BeanDeserialzerModifier previously, now I wonder if there is a way to modify something to solve this?
Just another Java problem (I'm a noob, I know): is it possible to use dynamic property binding in a Custom Control with a dynamic property getter in a Java bean?
I'll explain. I use this feature extensively in my Custom Controls:
<xp:inputTextarea id="DF_TiersM">
<xp:this.value><![CDATA[#{compositeData.dataSource[compositeData.fieldName]}]]></xp:this.value>
This is used in a control where both datasource and the name of the field are passed as parameters. This works, so far so good.
Now, in some cases, the datasource is a managed bean. When the above lines are interpreted, apparently code is generated to get or set the value of ... something. But what exactly?
I get this error: Error getting property 'SomeField' from bean of type com.sjef.AnyRecord which I guess is correct for there is no public getSomeField() in my bean. All properties are defined dynamically in the bean.
So how can I make XPages read the properties? Is there a universal getter (and setter) that allows me to use the name of a property as a parameter instead of the inclusion in a fixed method name? If XPages doesn't find getSomeField(), will it try something else instead, e.g. just get(String name) or so?
As always: I really appreciate your help and answers!
The way the binding works depends on whether or not your Java object implements a supported interface. If it doesn't (if it's just some random Java object), then any properties are treated as "bean-style" names, so that, if you want to call ".getSomeField()", then the binding would be like "#{obj.someField}" (or "#{obj['someField']}", or so forth).
If you want it to fall back to a common method, that's a job for either the DataObject or Map interfaces - Map is larger to implement, but is more standard (and you could inherit from AbstractMap if applicable), while DataObject is basically an XPages-ism but one I'm a big fan of (for reference, document data sources are DataObjects). Be warned, though: if you implement one of those, EL will only bind to the get or getValue method and will ignore normal setters and getters. If you want to use those when present, you'll have to write reflection code to do that (I recommend using Apache BeanUtils).
I have a post describing this in more detail on my blog: https://frostillic.us/f.nsf/posts/expanding-your-use-of-el-%28part-1%29
Can I use a Java custom annotation to add some code to a set or get method on a bean property to cleanse the property from bad html being input by my users? I've been looking for examples but I've not seen something that I feel I can extend.
You could define a custom annotation to add a validator to your setter, but is there a reason why you don't want to just embed validation into your bean without an annotation? The annotation mechanism might be difficult for others to understand if they ever need to work with your code.
I would do it this way: Rather than have your property be a String, define your own HtmlString (assuming an equivalent class doesn't already exist in a standard library) which can only be instantiated with valid HTML. Then, have your bean property be of that type. This would solve the validation problem in your component.
Define validation methods in the HtmlString to fit your requirements, so that every HtmlString instance is valid HTML; then, simply define a toString method. This method would likely be much easier for others to follow.