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

[Hardy Ferentschik]

On May 14, 2012, at 4:57 PM, Emmanuel Bernard wrote:

> 
> 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.

Right a list of class loaders would work

>>>> 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!

How else do you ensure class visibility (mind you I am just trying to understand how these environments work)

>>> 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.

On https://hibernate.onjira.com/browse/BVAL-286 I also suggested a 

ResourceBundle loadBundle(String bundleName, Locale locale);

But you are right, so far we did not take this up. We could just have the suggested ClassloaderService#getClassLoaders and 
use these class loaders for everything or we decide to already differentiate in the service itself (e.g. class loading via resource/bundle
loading)


>>> 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?

Seems to be similar to my question above. To be honest I am not sure.

--Hardy