Hi Rick,
The code that does the lookup is here in the jetty integration code:
(GeronimoWebAppContext near line 104)
try {
javax.naming.Context ctx = integrationContext.getComponentContext();
Object validatorFactory = ctx.lookup("comp/ValidatorFactory");
setAttribute("javax.faces.validator.beanValidator.ValidatorFactory",
validatorFactory);
} catch (NamingException e) {
// ignore. We just don't set the property if it's not available.
}
I suspect it used to pass because we were only using default validatory
factories so we could always create one. Either that, or we used to throw a
NamingException when we failed (the code you quote catches a naming
exception....).
I wonder if a better solution would be to also catch and ignore a
ValidationException here?
thanks
david jencks
On Oct 21, 2010, at 7:55 AM, Rick McGuire wrote:
> 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.
>
> Rick
>
> 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(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
>
