«

I have a set of classes that I will be using for validation of user input. I
was previously using a class loader to load what class I wanted to use for
validation but I ran into a few problems when switching over to tomcat. This
made me wonder if my solution was good or not.

I've made each of my validation classes implement a common interface and it
only needs to have one method:

Object validate(Object value, Object[] params);

Where the params array is a simple way to allow any number of parameters as
options to the validation function.

I initially chose a classloader because I figured it would allow any number
of validation classes without any problems at compile time. It would also be
easy since adding a validation to something would be as easy as telling the
object the validation's name, and parameters. As I was looking at the
problem I got with tomcat (file not found), I starting thinking that using
Class.newInstance might work just as well. Are there any benefits to one
over the other?

Miguel De Anda wrote:
> I have a set of classes that I will be using for validation of user input. I
> was previously using a class loader to load what class I wanted to use for
> validation but I ran into a few problems when switching over to tomcat. This
> made me wonder if my solution was good or not.

So far I'm not sure.

> I've made each of my validation classes implement a common interface and it
> only needs to have one method:
>
> Object validate(Object value, Object[] params);

I can't think of anything much more generic. In fact, I would say that
this is rather too generic. It certainly gives up on any kind of
compile-time type safety.

> Where the params array is a simple way to allow any number of parameters as
> options to the validation function.
>
> I initially chose a classloader because I figured it would allow any number
> of validation classes without any problems at compile time.

What kind of compilation problems did you think you might otherwise have?

> It would also be
> easy since adding a validation to something would be as easy as telling the
> object the validation's name, and parameters.

That's not any easier than using specific validation class. If
necessary, a validation class instance could be handed to the object.

> As I was looking at the
> problem I got with tomcat (file not found), I starting thinking that using
> Class.newInstance might work just as well. Are there any benefits to one
> over the other?

These approaches are not comparable. You cannot invoke newInstance on a
Class until you have loaded the corresponding class, which requires use
of a ClassLoader. You can use Class.forName("mypackage.MyClass") to get
a Class reference on which you may then invoke newInstance() -- that
will use the ClassLoader for the current class. There is also a version
of Class.forName that will use a ClassLoader you specify. Any way about
it, the choice is not between your custom ClassLoader and the methods of
the Class class, but rather between two or more different ClassLoaders.

If the classes in question are to be loaded from "normal" places, then
creating a custom ClassLoader is probably inappropriate, and may even
get you into trouble if your custom ClassLoader doesn't behave nicely.
Custom ClassLoaders have their uses, but it doesn't sound like yours is
one of the uses to which they are best suited.

Overall, You seem to be describing up a pluggable validation system
where the validation technique to apply in any given case is chosen at
runtime from among a set of choices that is not fully known at compile
time. If this is not what you are doing -- for instance, if the
appropriate validation scheme (or even all the available validation
schemes) is known at compile time then you are going way overboard. You
rarely need to manually load classes if you know at compile time what
classes you need or may need.


John Bollinger