geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Bean validation tck failures and JNDI contexts
Date Thu, 21 Oct 2010 14:55:25 GMT
I played around with different solutions and finally came up with 
something that fixes the problem.  Unfortunately, I'm not sure what I 
did is legitimate or not.  The root problem here is the naming reference 
implementations were throwing ValidationExceptions for any failures with 
creating a ValidatorFactory.  This probably was the behavior that should 
be implemented, but unfortunately, the getFederatedBindings() processing 
was triggering the resolution of these objects and the resulting 
exceptions were causing deploy failures.  The test cases in question 
were testing the very conditions that triggered the exceptions.  The 
exception was raised, but at deploy time, resulting in a test case failure.

I managed to fix this by having the reference objects we bind into jndi 
catch the exceptions and just return null.  Everything is passing in the 
TCK now, but I'm not sure returning null is the correct thing to do here.

I'm not really sure how we every were passing 100% in the container with 
the original code.  I would have thought that if the same sequence of 
calls were getting made to resolve the provider, then some of the same 
failures would have been seen.  I'm going to hold off on committing my 
changes until I get some feedback on this.


On 10/21/2010 7:48 AM, Rick McGuire wrote:
> We're down to 13 bean validation failures in the tck now, but these 
> failures are a little puzzling.   The tests in error are all giving 
> deploy failures, with the root cause being an exception triggered by 
> getFederatedBindings():
> java.lang.RuntimeException: javax.naming.NamingException: Validator 
> [Root exception is javax.validation.ValidationException: Unable to 
> find suitable provider: class 
> org.hibernate.jsr303.tck.common.TCKValidationProvider]
>         at 
> org.apache.xbean.naming.context.ContextUtil$ReadOnlyBinding.getObject(
>         at 
> org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(
>         at 
> org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(
>         at 
> org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(
>         at 
> org.apache.xbean.naming.context.AbstractContext.lookup(
>         at 
> org.apache.xbean.naming.context.AbstractContext.lookup(
>         at 
> org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.<init>(
>         at 
> org.apache.geronimo.jetty8.WebAppContextWrapper.<init>(
>         at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>         at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(
>         at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
>         at 
> java.lang.reflect.Constructor.newInstance(
>         at 
> org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(
>         at 
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(
>         at 
> org.apache.xbean.recipe.AbstractRecipe.create(
>         at 
> org.apache.xbean.recipe.AbstractRecipe.create(
>         at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(
>         at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
>         at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(
> The root cause of this failure is an exception in 
> DefaultValidatorReference.getContent():
>     @Override
>     public  Object  getContent()throws  NamingException  {
>         ValidatorFactory  factory  =null;
>                 try  {
>             factory  = (ValidatorFactory)new  
> InitialContext().lookup("java:comp/ValidatorFactory");
>         }catch(NamingException  e) {
>             factory  =Validation.buildDefaultValidatorFactory();
>         }
>                 return  factory.getValidator();
>     }
> The root cause of this failure is the NamingException on the .lookup() 
> call.  Since this occurs during the building of the federated context, 
> I suspect the initial context is not initialized correctly at this 
> phase.  There's a bit of a chicken-and-egg problem here.  The 
> buildDefaultValidatorFactory() call is failing because the incorrect 
> thread context classloader is getting used to resolve the provider.
> The puzzling piece to me is why this process is making the 
> getContent() calls in the first place.  Since this binding will create 
> a new instance each time it is requested, either A) an instance is 
> getting created needlessly and thrown away or B) this instance is 
> ending up bound to the JNDI context as a one-off, which would be an 
> incorrect result.
> I think I can fix this by making the DefaultValidatorReference look up 
> the ValidatorFactoryGBean to obtain the factory used to create the 
> ValidatorInstance rather than doing a jndi lookup, but I want to 
> verify that the lookup occurring at this point is the correct behavior 
> and there's not a better solution available.
> Rick

View raw message