camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: camel-bean-validator and hibernate-validator for OSGi
Date Tue, 28 Sep 2010 06:46:09 GMT
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.jiang@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<bengt@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message