Re: [bv-dev] bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
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?