geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Bean validation tck failures and JNDI contexts
Date Thu, 21 Oct 2010 11:48:01 GMT
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(ContextUtil.java:201)
         at org.apache.xbean.naming.context.ContextFederation.getFederatedBindings(ContextFederation.java:118)
         at org.apache.xbean.naming.context.AbstractFederatedContext.getBindings(AbstractFederatedContext.java:99)
         at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:86)
         at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:133)
         at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
         at org.apache.geronimo.jetty8.handler.GeronimoWebAppContext.<init>(GeronimoWebAppContext.java:104)
         at org.apache.geronimo.jetty8.WebAppContextWrapper.<init>(WebAppContextWrapper.java:211)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
         at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
         at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
         at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
         at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
         at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
         at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
         at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
         at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)


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

Mime
View raw message