Willem,
I've created a small test case using ServiceMix bundles for JSR-303 and for
hibernate validator.
It's a maven based project with a parent project containing two projects:
bundleOne and itest.
"bundleOne" contains a simple class (EntityOne) and a service with the
method "createEntityOne". Normally it would validate and persist to the
database using OpenJPA but in this test case it just validates so that I can
test hibernate validator.
The "bundleOne" project also includes a JUnit testcase that calls the
"createEntityOne" method and verifies that it is validated. (The validation
should react on the fact that the length of the "name" property is less than
10.
The "itest" project contains a test case that is run using Pax-Exam. I
configure Pax-Exam to use Felix 3.0.2. The actual test case instantiates the
service and calls the "createEntityOne" method to verify that validation is
performed. The exact same test case as the non-OSGi JUnit test described
above. But when I run this test I get the below exception:
javax.validation.ValidationException: Unable to find a default provider
at
> javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264)
at
> javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at validator.test1.impl.ServiceOne.createEntityOne(ServiceOne.java:17)
at validator.test.itest.OsgiTest.createTest(OsgiTest.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
at
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Can you check if I'm using the validation API the wrong way or if I have
misunderstood something? I don' t think I can send attachments on this
mailing list so I'm sending a ZIP file to you personal email address.
/Bengt
2010/9/28 Bengt Rodehav <be...@rodehav.com>
> Willem,
>
> With two bundles I mean that I have two bundles who utilize hibernate
> validator. I run integration tests using Pax-Exam. My first integration test
> deploys one bundle which uses hibernate validator to validate my entity
> objects before persisting them - it works without a problem.
>
> My second integration test needs the exact same bundle as the first one
> plus an additional bundle. The additional bundle also needs hibernate
> validator but that's when I get the "Unable to find a default provider"
> exception. I cannot know whether the problem is that I have two bundles
> accessing hibernat validator or if it's another problem. I've compared the
> two bundles pretty carefully too see if I've missed something in the second
> bundle but I can't find any descrepancies. That's why I started thinking
> that maybe the problem is that I now reference hibernate validator twice
> this time.
>
> It'll take some time for me to cook down a test case for this but I'll try
> to do that. Maybe I'll find the problem myself along the way - not
> uncommon...
>
> Meanwhile, can you confirm that I use the API correctly? I use OpenJPA to
> persist my entities but I perform validation manually. Thats why I need a
> ValidatorFactory. Is it correct to use the following code:
>
> I have my own utility function that validates an object. It looks like
> this:
>
> public static Set<ConstraintViolation<?>> violations(Object theObject,
>> Class<?>... theGroups)
>
> throws ConstraintViolationException {
>
> /*
>
> * Perform bean validation
>
> */
>
> ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
>
> Validator validator = factory.getValidator();
>
> return (Set) validator.validate(theObject, theGroups);
>
> }
>
>
> The line that creates the ValidatorFactory is the one causing the
> exception. I should mention that when I do not run within OSGi the above
> code works.
>
> /Bengt
>
>
> 2010/9/28 Willem Jiang <willem.ji...@gmail.com>
>
> What do you mean about two bundles?
>> Are they two camel context, or others.
>>
>> ServiceMix's repacked bundle should supports to be used across the OSGi
>> platform, so I need more information about how do you use these validator.
>>
>> Please create a small test case to show the whole story.
>>
>>
>>
>> On 9/27/10 3:51 AM, Bengt Rodehav wrote:
>>
>>> I'm now using ServiceMix packaging of hibernate validator and the
>>> javax.validation api. It works when I only have one bundle using the
>>> validation api but when I have two bundles I get the following exception:
>>>
>>> javax.validation.ValidationException: Unable to find a default provider
>>>
>>> at
>>>
>>>>
>>>> javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264)
>>>>
>>>
>>> at
>>>
>>>>
>>>> javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
>>>>
>>>
>>> at
>>>
>>>>
>>>> se.digia.sts.util.validation.ValidatorUtil.violations(ValidatorUtil.java:18)
>>>>
>>>
>>> at
>>>
>>>>
>>>> se.digia.sts.safekeep.accounttransaction.impl.AccountTransactionService.createAccountTransaction(AccountTransactionService.java:38)
>>>>
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>
>>> at
>>>
>>>>
>>>> org.apache.aries.blueprint.proxy.Collaborator$1.invoke(Collaborator.java:66)
>>>>
>>>
>>> at
>>>
>>>>
>>>> org.apache.aries.blueprint.proxy.Collaborator.invoke(Collaborator.java:151)
>>>>
>>>
>>> at
>>>
>>>>
>>>> org.apache.aries.blueprint.proxy.CgLibInterceptorWrapper$1.intercept(CgLibInterceptorWrapper.java:125)
>>>>
>>>
>>> at
>>>
>>>>
>>>> se.digia.sts.safekeep.accounttransaction.impl.AccountTransactionService$$EnhancerByCGLIB$$a709c18.createAccountTransaction(<generated>)
>>>>
>>>
>>> at
>>>
>>>>
>>>> se.digia.sts.safekeep.itest.accounttransaction.AccountTransactionServiceTest.createAccountTransactionTest(AccountTransactionServiceTest.java:55)
>>>>
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>
>>> at
>>>
>>>>
>>>> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
>>>>
>>>
>>> at
>>>
>>>>
>>>> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
>>>>
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>
>>> at
>>>
>>>>
>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>
>>>
>>> at
>>>
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>
>>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
>>>
>>> at sun.rmi.transport.Transport$1.run(Transport.java:159)
>>>
>>> at java.security.AccessController.doPrivileged(Native Method)
>>>
>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
>>>
>>> at
>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
>>>
>>> at
>>>
>>>>
>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
>>>>
>>>
>>> at
>>>
>>>>
>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
>>>>
>>>
>>> at
>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>
>>>
>>> at
>>>
>>>>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>> I'm not sure if I'm using the api the correct way. The call (in my code)
>>> that causes this exception is:
>>>
>>> ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
>>>
>>>
>>> Should I find/create my factory some other way when I use the ServiceMix
>>> packaging? Should I use the OsgiLocator.locate() method?
>>>
>>> /Bengt
>>>
>>>
>>>
>>> 2010/9/16 Bengt Rodehav<be...@rodehav.com>
>>>
>>> Willem,
>>>>
>>>> Sorry if I appear a bit ignorant but, as I wrote before, I haven't done
>>>> any
>>>> OSGi wrapping before - I've always found what I needed. Often from
>>>> ServiceMix, sometimes from Geronimo (specs) and from SpringSource. I'm
>>>> trying to get the hang of this...
>>>>
>>>> I don't think I need to try the validator API from ServiceMix - I'm sure
>>>> it
>>>> works. I just hadn't realised that in order to use the ServiceMix
>>>> wrapper
>>>> for hibernate validator one must also use the ServiceMix wrapper for the
>>>> validation API.
>>>>
>>>> Furthermore, it seems there is definitely something for me to learn
>>>> regarding exporting of META-INF. I haven't thought about this as a
>>>> problem
>>>> but realize that I should.
>>>>
>>>> What exactly will happen if many bundles export META-INF/services? I
>>>> realise that it's a non-OSGi way of doing things. In OSGi, an OSGi
>>>> service
>>>> should be published that others can depend on. I guess that's what the
>>>> ServiceMix wrapper for the validation API does. I bet there is a pattern
>>>> here since the META-INF/services pattern is widely used.
>>>>
>>>> Thanks,
>>>>
>>>> /Bengt
>>>>
>>>> P.S.
>>>> Has ServiceMix published a a newer (4.1.Final) version of hibernate
>>>> validator? Makes sens to use that instead of my own wrapper when the
>>>> wrapping seems to be non-trivial.
>>>> D.S.
>>>>
>>>>
>>>>
>>
>>
>> --
>> Willem
>> ----------------------------------
>> Apache Camel, Apache CXF committer
>> Open Source Integration: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: http://twitter.com/willemjiang
>>
>
>
