Using DataSift
Configuration
Dependencies
It is not a problem at all. DataSift will only work internally with non-primitive types, but it will be able to validate / transform your primitives by boxing them adequately.
So, int will become java.lang.Integer, float
will become java.lang.Float, etc...
This means that, if you have an int in a bean that you want to validate, you will be able
to transparently apply to it a validation that receives a java.lang.Integer
object as a data parameter.
Yes, and you can process these types of objects in two different ways:
ArrayIterator, CollectionIterator and MapIterator
(see the Predefined Entities reference documentation) which allow you to define nested
validations or transformations that these iterators will apply on each of the elements of
the arrays, Collections or Maps they may get as targets.
Yes, you can. You could for example create a validator that compares two integer values, and then use it to validate whether a certain int field in a javabean is higher than another one or not. This would allow you to validate on data values more than on data formats, even establishing dependencies among your different pieces of data, something necessary many times.
The only thing you need to do this is develop a validator or transformer which receives more than one data parameter and then process this parameters at your wish in the validator code.
Instantiating a DataSift object can be a time-consuming process the first time you do it, this is, when you create your first instance, as it will be then that the default confguration files will be read and the builtin entities be bootstrapped.
Subsequent instances will not produce such an overhead as the first one, but you must always consider that you can be using specs, validators, transformers... that you only registered in a specific instance, and so losing that instance will mean having to register them again to process your data. As a general rule, it is advisable to keep you DataSift instances, once you fully initialize them.
When looking at the configuration parameters that some resolvers, validators and transformers need, you can
see that many of them are not of type String, but instead they are Boolean,
Integer, etc. objects.
But when you write your configuration files, what you're writing is only text,
this is Strings. How can you set a Boolean configuration parameter, then?
Well, this is nothing to worry about, as DataSift will automatically get the text of your
XML configuration files and try to transform it into an object of the needed class. This way,
if for example you need a java.lang.Boolean parameter for a validator and you write
the value "true" for it in the XML, it will be transformed into
Boolean.TRUE before passing it to the validator.
Note that this conversion will not take place if you set the configuration parameters
programmatically, this is, from your java code. In this case, you would have to pass
real java.lang.Boolean (or Integer,...) objects.
DataSift makes a very intensive use of DEBUG logging, and so, using it at this log level in production environments in which speed is important can be an issue.
Turning DEBUG logging off for DataSift in your logging system will improve speed quite a lot, if this is necessary.
No, it is not always required. It will only be required if you need to use the
HttpRequestResolver to work on HTTP request objects, but you can
remove it if you don't need it. If you are not developing a web application, you
will most certainly not have a servlet implementation available in your environment.
Note that if you don't add a servlet api to the classpath, the framework will detect it and the HttpRequestResolver will not be registered at startup.
No, it is not required (although recommended). It is there only for testing purposes, but DataSift uses Jakarta commons-logging API for log operations, so that you can plug your favourite log library and make DataSift work with it.