In our product we are using Ignite ClientCache to cache objects. We are using a class object as key to store in cache. Now when I create another drive class object and store it in ClientCache cache. Here I am adding drive class object in Baseclass cache, and after I added a child class object, I have updated some of its member fields, before removable. Now when I call ClientCache.remove() on such drive class object it fails to find such key.
So my question is how can I provide custom comparator, I have already tried java equals() and hashcode() function overriding, but it does not work.
Ignite considers two objects equal when all of the following is true:
Type ID is the same (same class).
Serialized representation (byte[]) is the same.
Ignite does not use standard equals() and hashCode() for comparisons, because the DB engine operates on serialized data. There is no way to override this behavior.
Related
I am new to java.
I am not able to get my understanding around the difference between Pagefactory.initelements and Class instance. Can someone please help me on this ? Reason for this question is :
The only difference I can see is the webelement initialisation and nothing apart from that. Both can be used to access the class variables and methods.
Somename.class will do the same as 'new someclass()' ?
Page Factory uses Java Reflection API. It also has 2 public constructors for developers. One accepts already instantiated object as an argument. The second allows you to pass Object.class which is not an instance, it's more like a schema of a class.
PageFactory.initElements(driver, this);
The above method accepts the instance of Page Object, already created instance. Then, it gets it's a schema, reads fields and initializes them based on #FindBy annotations.
PageFactory.initElements(driver, PageObject.class)
The above class already has the schema so it initializes the fields and returns a newly created instance of PageObject class.
I have a class A, a cache A_CACHE and a proxy object AProxy extends A. My goal is to serialize AProxy objects as if they are A objects (automatically substitute type) and put them into A_CACHE.
Is there any way in Apache Ignite to substitute type of an object that I am trying to put into cache (serialize using BinarySerializer)?
What I have tried so far.
I have implemented and registered the same BinarySerializer for both types. I have also tried to play with BinaryNameMapper class to return the same class name for both classes, but without success. The only option that comes to my mind now is to use BinaryObjectBuilder. Is it really the only option for me?
After a small research the solution was found.
AProxy should implement writeReplace method of Serializable interface. Return proxied instance from this method. If proxied class is Serializable or Externalizable and one wants to apply custom serialization, than Binarylizable interface should be implemented by proxied class (custom binary serializers are not applied when using the hack above, but instead OptimizedMarshaller is being used).
I saw that the default LocationStrategy is STRONG, which keeps a strong reference to the class loader when creating a ClassFileLocator. Does this mean Byte Buddy can prevent a class loader from being garbage collected (eg when undeploying a webapp from a servlet container) or is there another mechanism to evacuate those?
Also in this regard- the documentation about the WEAK strategy says a ClassFileLocator will "stop working" after the corresponding class loader is garbage collected. What are the implications? How would a locator for a garbage-collected class loader be used?
You are right about your assertion. With a strong type locator, all TypeDescriptions will reference the class loader as dependent types are resolved lazily. This means for example that if you look up a type's field type, that type will only be loaded if you are using it for the first time what might never happen.
Typically, those type descriptions are not stored over the life time of a class being loaded. Since the class loader will never be garbage collected during a loading of one of its classes, referencing the class loader strongly does not render any issue. However, once you want to cache type descriptions in between multiple class loadings (what can make a lot of sence since some applications load thousands of classes using the same class loader), this might become a problem if a class loader would be garbage collected while the cache is still referencing the type description with the underlying class loader.
In this case, reusing the type descriptions will be problematic since no lazily referenced classes can be resolved after the class loader was garbage collected. Note that a type description might be resolved using a specific class loader while the class is defined by a parent of that class loader which is why this might be a problem.
Typically, if you maintain a cache of type descriptions per class loader, this should however not be a problem.
I have an API exposed via Spring Data Rest which, for the most part, is read-only but which allows for updating of some properties via PATCH requests.
Is there any (I'm supposing Jackson) configuration at a global level that would essentially make an entity read only unless specific properties were annotated in some way.
I am familiar with the#JsonProperty(access = Access.READ_ONLY) Jackson annotation however would like to avoid having to annotate all read-only properties.
For example, given the class below only the field explicitly annotated would be writable. All other fields would be readable by default:
public class Thing{
private String fieldOne;
#JsonProperty(access = Access.READ_WRITE)
private String fieldTwo;
private String fieldThree;
// a lot of other properties
}
Failing any global configuration, is there anything that can be applied at the class level?
I am not aware of any way to globally set all attributes in a class to read only. Since version 2.6+ of FaserXML you can use the following annotation to at least defined the set of properties you would ignore and only allow for serialization. The following annotation would be used at the class level:
#JsonIgnoreProperties(value={ "fieldOne", "fieldThree"}, allowGetters=true)
It is not exactly what you are looking for, but arguably makes coding a little easier.
I have noticed that some of my serialized objects stored in Redis have problems deserializing.
This typically occurs when I make changes to the object class being stored in Redis.
I want to understand the problem so that I can have a clear design for a solution.
My question is, what causes deserialization problems?
Would a removal of a public/private property cause a problem?
Adding new properties, perhaps?
Would a adding a new function to the class create problems? How about more constructors?
In my serialized object, I have a property Map, what if I change (updated some properties, added functions, etc) myObject, would it cause a deserialization problem?
what causes deserialization problems?
I would like to give you bit of background before answering your question,
The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException.
If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, It uses the following information of the class to compute SerialVersionUID,
The class name.
The class modifiers written as a 32-bit integer.
The name of each interface sorted by name.
For each field of the class sorted by field name (except private static and private transient fields:
The name of the field.
The modifiers of the field written as a 32-bit integer.
The descriptor of the field.
if a class initializer exists, write out the following:
The name of the method, .
The modifier of the method, java.lang.reflect.Modifier.STATIC, written as a 32-bit integer.
The descriptor of the method, ()V.
For each non-private constructor sorted by method name and signature:
The name of the method, .
The modifiers of the method written as a 32-bit integer.
The descriptor of the method.
For each non-private method sorted by method name and signature:
The name of the method.
The modifiers of the method written as a 32-bit integer.
The descriptor of the method.
So, to answer your question,
Would a removal of a public/private property cause a problem? Adding new properties, perhaps? Would a adding a new function to the class create problems? How about more constructors?
Yes, all these additions/removal by default will cause the problem.
But one way to overcome this is to explicitly define the SerialVersionUID, this will tell the serialization system that i know the class will evolve (or evolved) over the time and don't throw an error. So the de-serialization system reads only those fields that are present in both the side and assigns the value. Newly added fields on the de-serialization side will get the default values. If some fields are deleted on the de-serialization side, the algorithm just reads and skips.
Following is the way one can declare the SerialVersionUID,
private static final long serialVersionUID = 3487495895819393L;