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