You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2010/10/21 13:48:01 UTC
Bean validation tck failures and JNDI contexts
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
Re: Bean validation tck failures and JNDI contexts
Posted by Rick McGuire <ri...@gmail.com>.
On 10/21/2010 12:34 PM, David Jencks wrote:
> 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....).
Ah, I hadn't checked to see what was triggering the call. Yes, that
could be a simpler solution to this problem. I'll give that a try.
Rick
> 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
>
Re: Bean validation tck failures and JNDI contexts
Posted by Rick McGuire <ri...@gmail.com>.
On 10/21/2010 2:33 PM, David Jencks wrote:
> yikes...
>
> I didn't study this in detail recently but I wonder if we should add an xbean RuntimeNamingException that wraps the NamingException and have ContextFederation.getFederatedBindings() unwrap only this runtime exception?
I'm rebuilding Geronimo now to pick up the changes, but here's what I
added to getFederatedBindings():
// don't overwrite existing bindings
if (!bindings.containsKey(bindingName)) {
try {
bindings.put(bindingName,binding.getObject());
}catch (RuntimeException e) {
// if this is a wrapped NamingException, unwrap and throw the original
Throwable cause =e.getCause();
if (cause !=null && cause instanceof NamingException ) {
throw (NamingException)cause;
}
// Wrap this into a RuntimeException.
throw (NamingException)new NamingException("Could retrieve bound instance" +name).initCause(e);
}
}
This unwraps and rethrows a NamingException if it is there and wraps any
other RuntimeException inside of a NamingException so that only
NamingExceptions are seen down stream. I think this should give the
behavior we need to fix the TCK problems.
Rick
> david jencks
>
> On Oct 21, 2010, at 11:10 AM, Rick McGuire wrote:
>
>> On 10/21/2010 12:58 PM, David Jencks wrote:
>>> umm...
>>>
>>> doing a naming lookup should only throw NamingExceptions.... so I think what should happen is that the reference should wrap the ValidationException in a NamingException. Will this mess up the tck?
>> This seems like the correct thing to do, but unfortunately, it didn't work. The problem is in the xbean ContextUtil$ReadOnlyBinding.getObject() method:
>>
>> public Object getObject() {
>> try {
>> return resolve(value,getName(),null,context);
>> }catch (NamingException e) {
>> throw new RuntimeException(e);
>> }
>> }
>>
>> This is catching the NamingException and turning it into a RuntimeException. This doesn't seem correct to me, but the Binding interface it implements does not throw any checked exceptions, so this is the only way this error can get reflected back.
>>
>> Looking at the call chain, I'm thinking that ContextFederation.getFederatedBindings() should catch RuntimeExceptions and and either turn them into NamingExceptions or just ignore the exception like it does with the NotContextExceptions.
>>
>> Rick
>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 21, 2010, at 9:34 AM, David Jencks wrote:
>>>
>>>> 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
>
Re: Bean validation tck failures and JNDI contexts
Posted by David Jencks <da...@yahoo.com>.
yikes...
I didn't study this in detail recently but I wonder if we should add an xbean RuntimeNamingException that wraps the NamingException and have ContextFederation.getFederatedBindings() unwrap only this runtime exception?
david jencks
On Oct 21, 2010, at 11:10 AM, Rick McGuire wrote:
> On 10/21/2010 12:58 PM, David Jencks wrote:
>> umm...
>>
>> doing a naming lookup should only throw NamingExceptions.... so I think what should happen is that the reference should wrap the ValidationException in a NamingException. Will this mess up the tck?
> This seems like the correct thing to do, but unfortunately, it didn't work. The problem is in the xbean ContextUtil$ReadOnlyBinding.getObject() method:
>
> public Object getObject() {
> try {
> return resolve(value,getName(),null,context);
> }catch (NamingException e) {
> throw new RuntimeException(e);
> }
> }
>
> This is catching the NamingException and turning it into a RuntimeException. This doesn't seem correct to me, but the Binding interface it implements does not throw any checked exceptions, so this is the only way this error can get reflected back.
>
> Looking at the call chain, I'm thinking that ContextFederation.getFederatedBindings() should catch RuntimeExceptions and and either turn them into NamingExceptions or just ignore the exception like it does with the NotContextExceptions.
>
> Rick
>
>> thanks
>> david jencks
>>
>> On Oct 21, 2010, at 9:34 AM, David Jencks wrote:
>>
>>> 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
>>
>
Re: Bean validation tck failures and JNDI contexts
Posted by Rick McGuire <ri...@gmail.com>.
On 10/21/2010 12:58 PM, David Jencks wrote:
> umm...
>
> doing a naming lookup should only throw NamingExceptions.... so I think what should happen is that the reference should wrap the ValidationException in a NamingException. Will this mess up the tck?
This seems like the correct thing to do, but unfortunately, it didn't
work. The problem is in the xbean
ContextUtil$ReadOnlyBinding.getObject() method:
public Object getObject() {
try {
return resolve(value,getName(),null,context);
}catch (NamingException e) {
throw new RuntimeException(e);
}
}
This is catching the NamingException and turning it into a
RuntimeException. This doesn't seem correct to me, but the Binding
interface it implements does not throw any checked exceptions, so this
is the only way this error can get reflected back.
Looking at the call chain, I'm thinking that
ContextFederation.getFederatedBindings() should catch RuntimeExceptions
and and either turn them into NamingExceptions or just ignore the
exception like it does with the NotContextExceptions.
Rick
> thanks
> david jencks
>
> On Oct 21, 2010, at 9:34 AM, David Jencks wrote:
>
>> 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
>
Re: Bean validation tck failures and JNDI contexts
Posted by David Jencks <da...@yahoo.com>.
umm...
doing a naming lookup should only throw NamingExceptions.... so I think what should happen is that the reference should wrap the ValidationException in a NamingException. Will this mess up the tck?
thanks
david jencks
On Oct 21, 2010, at 9:34 AM, David Jencks wrote:
> 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
>>
>
Re: Bean validation tck failures and JNDI contexts
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: Bean validation tck failures and JNDI contexts
Posted by Rick McGuire <ri...@gmail.com>.
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