[bv-dev] bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments

[Emmanuel Bernard]

On 14 mai 2012, at 12:31, Hardy Ferentschik wrote:

> 
> On May 14, 2012, at 10:01 AM, Emmanuel Bernard wrote:
> 
>> I'm not sure if that should be as classForName or by passing the classloader but I see the following needs:
> 
> The benefit of ClassLoaderService#classForName is that an implementation still could decide to implement strategies like
> first trying the context and the the current class loader.

You can do the same if a list of classloaders is returned.

> 
>>> From where:
>> 
>> - from the user application or from the module depending on BV
> 
> I am also trying to understand what a modular environment means for a shared ValidatorFactory.
> If a user application depends on BV and also uses custom constraints, does it not mean the application 
> would need to build its own ValidatorFactory via ValidatorFactory#usingContext()#classLoaderService(classLoaderService).

That would sucks balls!

> 
>> I also wonder if all of this should be masked behind a contract like your describe, or if the list of classloaders should be exposed to BV and processed.
> 
> How would the latter latter look like?

Something like that

interface ClassloaderService {
    /** Return an ordered list of classloaders to load classes and resources.
     * BV providers should use these classlaoders in order as this reflect the
     * application preference
     */
    List<Classloader> getClassloaders();
}

Note that neither your nor my solution differentiate classloading depending on what ought to be loaded.

> 
>> I am also not sure of the impact of object lifecycle.
> 
> What exactly do you mean here?

For example, does a module means that it has an independent bootstrap lifecycle and that all apps depending on the BV app will reuse the same ValidatorFactory?