You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/09/11 01:07:07 UTC

camel-bean-validator and hibernate-validator for OSGi

I''m experimenting with the Java Bean Validation API (JSR 303). I'm not
currently doing it with Camel but thought I might ask for help here anyway.

I'm deploying in an OSGi context and need OSGi bundles for both the API
(java.validation) and Hibernate's reference implementation (preferably the
latest version which I believe is 4.1). I haven't been able to find one. The
only one I've found is bundled for Glassfish but has dependencies on
Glassfish specific classes and therefore doesn't work outside Glassfish.

Since Camel 2.4 contains the camel-bean-validator component I'm wondering if
anyone can tell me how this problem was solved in Camel.

/Bengt

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

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 <wi...@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
>>
>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by 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 <wi...@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
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Willem Jiang <wi...@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

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

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.
>
>
> 2010/9/16 Willem Jiang <wi...@gmail.com>
>
>> On 9/16/10 3:16 PM, Bengt Rodehav wrote:
>>
>>> Willem,
>>>
>>> Not sure what you mean. I solved the problem by exporting the META-INF
>>> and
>>> the META-INF.services "packages". That's all it took.
>>>
>> If you just have one bundle exports META-INF.services, that could be OK.
>> But if you have tens of bundles export that package, you will in a
>> nightmare.
>>
>>
>>
>>> However, your version does not seem to work since no default provider can
>>> be
>>> found
>>>
>>> ...Aha now I see what you wrote in your mail... You mean you need to hack
>>> the VALIDATOR API to get it to work. I just wrapped the validator API
>>> (without hacks) and it works IF you export the META-INF.services package.
>>> Isn't that preferrable to hacking the validator API?
>>>
>> Can you try out the validator API from ServiceMix here[1]?
>>
>> [1]mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr303-api-1.0.0/1.5.0
>>
>>
>> Willem
>>
>>
>>> /Bengt
>>>
>>> 2010/9/16 Willem Jiang<wi...@gmail.com>
>>>
>>>  Oh, you need to make sure the bean validator API can find the
>>>> implementor
>>>> jars in OSGi container.
>>>> ServiceMix did some work by introducing the service locator to search
>>>> the
>>>> service from META-INF/services, and you may also need to hack the
>>>> validator
>>>> API by using the locator to find the service from META-INF/services.
>>>>
>>>> If you like you can take a look at the code here[1]
>>>>
>>>> [1]
>>>> https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator
>>>>
>>>> Willem
>>>>
>>>>
>>>> On 9/16/10 2:39 PM, Bengt Rodehav wrote:
>>>>
>>>>  Willem,
>>>>>
>>>>> I ended up using my own wrapped version mostly for learning reasons.
>>>>> However, I had some problems with my wrapped version. I deployed it in
>>>>> the
>>>>> container but in runtime I got error messages saying that no default
>>>>> provider could be found. I then noticed that I hadn't exported the
>>>>> META-INF/services "package" from the bundle. When I did that, the error
>>>>> message disappeared and the validator worked.
>>>>>
>>>>> I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
>>>>> Hibernate Validator. It seems to have the same problem. Maybe someone
>>>>> should
>>>>> look into this?
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2010/9/13 Bengt Rodehav<be...@rodehav.com>
>>>>>
>>>>>  Thanks, I'll have a look,
>>>>>
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>> 2010/9/13 Willem Jiang<wi...@gmail.com>
>>>>>>
>>>>>> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>>>>>
>>>>>>
>>>>>>>  Thanks Cristian,
>>>>>>>
>>>>>>>>
>>>>>>>> I kind of suspected that Servicemix had bundled this. Actually I
>>>>>>>> ended
>>>>>>>> up
>>>>>>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>>>>>>> version.
>>>>>>>> Also wanted to see how easy/hard it was to accomplish.
>>>>>>>>
>>>>>>>> /Bengt
>>>>>>>>
>>>>>>>>
>>>>>>>>  I just created a patch[1] for the hibernate-validator bundle, you
>>>>>>> may
>>>>>>> take
>>>>>>> a look if you want use it.
>>>>>>>
>>>>>>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>>>>>>
>>>>>>> Willem
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>>
>>>>>>>>
>>>>>>>>  Hello Bengt!
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sorry, I overlooked it.
>>>>>>>>> Apache Servicemix provides the OSGI-fied version for us. You can
>>>>>>>>> find
>>>>>>>>> the
>>>>>>>>> released version 4.0.2 here [1]
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>  Thanks for your reply Christian.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact
>>>>>>>>>> I
>>>>>>>>>>
>>>>>>>>>>  think
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  its the publicly released jar from JBoss which I had problems
>>>>>>>>> with. I
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  tried
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  to use the OSGi wrapped version they use in Glassfish:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  But it turns out it requires the packages
>>>>>>>>>> "org.glassfish.api.naming.*"
>>>>>>>>>>
>>>>>>>>>>  that
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  I assume only exist in Glassfish.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>>>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned
>>>>>>>>>> above.
>>>>>>>>>> From
>>>>>>>>>> where does Camel take it?
>>>>>>>>>>
>>>>>>>>>> I don't quite understand how Camel can use the non-OSGi:fied
>>>>>>>>>> version
>>>>>>>>>> of
>>>>>>>>>> hibernate-validator. Have you tried this deployed in an OSGi
>>>>>>>>>> container?
>>>>>>>>>>
>>>>>>>>>> /Bengt
>>>>>>>>>>
>>>>>>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>  Hello Bengt,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> we use the following on [1]. I think we could also update to
>>>>>>>>>>> 4.1.0.
>>>>>>>>>>> I
>>>>>>>>>>> opened
>>>>>>>>>>> a JIRA for it [2].
>>>>>>>>>>>
>>>>>>>>>>> Hope this helps,
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>>>>>>
>>>>>>>>>  [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<bengt@rodehav.com
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   I''m experimenting with the Java Bean Validation API (JSR 303).
>>>>>>>>>>> I'm
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>  not
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>   currently doing it with Camel but thought I might ask for help
>>>>>>>>> here
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>   anyway.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  I'm deploying in an OSGi context and need OSGi bundles for both
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>  API
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>   (java.validation) and Hibernate's reference implementation
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>   (preferably
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>   the
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>  latest version which I believe is 4.1). I haven't been able to
>>>>>>>>>>> find
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  one.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>  The
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  only one I've found is bundled for Glassfish but has
>>>>>>>>>>>> dependencies
>>>>>>>>>>>> on
>>>>>>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>>>>>>
>>>>>>>>>>>>  Glassfish.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  wondering
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>  if
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  anyone can tell me how this problem was solved in Camel.
>>>>>>>>>>>>
>>>>>>>>>>>> /Bengt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by 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.


2010/9/16 Willem Jiang <wi...@gmail.com>

> On 9/16/10 3:16 PM, Bengt Rodehav wrote:
>
>> Willem,
>>
>> Not sure what you mean. I solved the problem by exporting the META-INF and
>> the META-INF.services "packages". That's all it took.
>>
> If you just have one bundle exports META-INF.services, that could be OK.
> But if you have tens of bundles export that package, you will in a
> nightmare.
>
>
>
>> However, your version does not seem to work since no default provider can
>> be
>> found
>>
>> ...Aha now I see what you wrote in your mail... You mean you need to hack
>> the VALIDATOR API to get it to work. I just wrapped the validator API
>> (without hacks) and it works IF you export the META-INF.services package.
>> Isn't that preferrable to hacking the validator API?
>>
> Can you try out the validator API from ServiceMix here[1]?
>
> [1]mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr303-api-1.0.0/1.5.0
>
>
> Willem
>
>
>> /Bengt
>>
>> 2010/9/16 Willem Jiang<wi...@gmail.com>
>>
>>  Oh, you need to make sure the bean validator API can find the implementor
>>> jars in OSGi container.
>>> ServiceMix did some work by introducing the service locator to search the
>>> service from META-INF/services, and you may also need to hack the
>>> validator
>>> API by using the locator to find the service from META-INF/services.
>>>
>>> If you like you can take a look at the code here[1]
>>>
>>> [1] https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator
>>>
>>> Willem
>>>
>>>
>>> On 9/16/10 2:39 PM, Bengt Rodehav wrote:
>>>
>>>  Willem,
>>>>
>>>> I ended up using my own wrapped version mostly for learning reasons.
>>>> However, I had some problems with my wrapped version. I deployed it in
>>>> the
>>>> container but in runtime I got error messages saying that no default
>>>> provider could be found. I then noticed that I hadn't exported the
>>>> META-INF/services "package" from the bundle. When I did that, the error
>>>> message disappeared and the validator worked.
>>>>
>>>> I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
>>>> Hibernate Validator. It seems to have the same problem. Maybe someone
>>>> should
>>>> look into this?
>>>>
>>>> /Bengt
>>>>
>>>> 2010/9/13 Bengt Rodehav<be...@rodehav.com>
>>>>
>>>>  Thanks, I'll have a look,
>>>>
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2010/9/13 Willem Jiang<wi...@gmail.com>
>>>>>
>>>>> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>>>>
>>>>>
>>>>>>  Thanks Cristian,
>>>>>>
>>>>>>>
>>>>>>> I kind of suspected that Servicemix had bundled this. Actually I
>>>>>>> ended
>>>>>>> up
>>>>>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>>>>>> version.
>>>>>>> Also wanted to see how easy/hard it was to accomplish.
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>>
>>>>>>>  I just created a patch[1] for the hibernate-validator bundle, you
>>>>>> may
>>>>>> take
>>>>>> a look if you want use it.
>>>>>>
>>>>>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>>
>>>>>>  2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>
>>>>>>>
>>>>>>>  Hello Bengt!
>>>>>>>
>>>>>>>
>>>>>>>> Sorry, I overlooked it.
>>>>>>>> Apache Servicemix provides the OSGI-fied version for us. You can
>>>>>>>> find
>>>>>>>> the
>>>>>>>> released version 4.0.2 here [1]
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>  Thanks for your reply Christian.
>>>>>>>>
>>>>>>>>
>>>>>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>>  think
>>>>>>>>>
>>>>>>>>
>>>>>>>>  its the publicly released jar from JBoss which I had problems with.
>>>>>>>> I
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  tried
>>>>>>>>>
>>>>>>>>
>>>>>>>>  to use the OSGi wrapped version they use in Glassfish:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>>>>>
>>>>>>>>
>>>>>>>>  But it turns out it requires the packages
>>>>>>>>> "org.glassfish.api.naming.*"
>>>>>>>>>
>>>>>>>>>  that
>>>>>>>>>
>>>>>>>>
>>>>>>>>  I assume only exist in Glassfish.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned
>>>>>>>>> above.
>>>>>>>>> From
>>>>>>>>> where does Camel take it?
>>>>>>>>>
>>>>>>>>> I don't quite understand how Camel can use the non-OSGi:fied
>>>>>>>>> version
>>>>>>>>> of
>>>>>>>>> hibernate-validator. Have you tried this deployed in an OSGi
>>>>>>>>> container?
>>>>>>>>>
>>>>>>>>> /Bengt
>>>>>>>>>
>>>>>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>>>>
>>>>>>>>>  Hello Bengt,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> we use the following on [1]. I think we could also update to
>>>>>>>>>> 4.1.0.
>>>>>>>>>> I
>>>>>>>>>> opened
>>>>>>>>>> a JIRA for it [2].
>>>>>>>>>>
>>>>>>>>>> Hope this helps,
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>>>>>
>>>>>>>>  [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>>>>
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I''m experimenting with the Java Bean Validation API (JSR 303).
>>>>>>>>>> I'm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>  not
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>   currently doing it with Camel but thought I might ask for help
>>>>>>>> here
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>   anyway.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  I'm deploying in an OSGi context and need OSGi bundles for both
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>  API
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>   (java.validation) and Hibernate's reference implementation
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>   (preferably
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>   the
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>  latest version which I believe is 4.1). I haven't been able to
>>>>>>>>>> find
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  one.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>  The
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  only one I've found is bundled for Glassfish but has dependencies
>>>>>>>>>>> on
>>>>>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>>>>>
>>>>>>>>>>>  Glassfish.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  wondering
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>  if
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  anyone can tell me how this problem was solved in Camel.
>>>>>>>>>>>
>>>>>>>>>>> /Bengt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Willem Jiang <wi...@gmail.com>.

On 9/16/10 3:16 PM, Bengt Rodehav wrote:
> Willem,
>
> Not sure what you mean. I solved the problem by exporting the META-INF and
> the META-INF.services "packages". That's all it took.
If you just have one bundle exports META-INF.services, that could be OK.
But if you have tens of bundles export that package, you will in a 
nightmare.

>
> However, your version does not seem to work since no default provider can be
> found
>
> ...Aha now I see what you wrote in your mail... You mean you need to hack
> the VALIDATOR API to get it to work. I just wrapped the validator API
> (without hacks) and it works IF you export the META-INF.services package.
> Isn't that preferrable to hacking the validator API?
Can you try out the validator API from ServiceMix here[1]?
[1]mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr303-api-1.0.0/1.5.0


Willem
>
> /Bengt
>
> 2010/9/16 Willem Jiang<wi...@gmail.com>
>
>> Oh, you need to make sure the bean validator API can find the implementor
>> jars in OSGi container.
>> ServiceMix did some work by introducing the service locator to search the
>> service from META-INF/services, and you may also need to hack the validator
>> API by using the locator to find the service from META-INF/services.
>>
>> If you like you can take a look at the code here[1]
>>
>> [1] https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator
>>
>> Willem
>>
>>
>> On 9/16/10 2:39 PM, Bengt Rodehav wrote:
>>
>>> Willem,
>>>
>>> I ended up using my own wrapped version mostly for learning reasons.
>>> However, I had some problems with my wrapped version. I deployed it in the
>>> container but in runtime I got error messages saying that no default
>>> provider could be found. I then noticed that I hadn't exported the
>>> META-INF/services "package" from the bundle. When I did that, the error
>>> message disappeared and the validator worked.
>>>
>>> I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
>>> Hibernate Validator. It seems to have the same problem. Maybe someone
>>> should
>>> look into this?
>>>
>>> /Bengt
>>>
>>> 2010/9/13 Bengt Rodehav<be...@rodehav.com>
>>>
>>>   Thanks, I'll have a look,
>>>>
>>>> /Bengt
>>>>
>>>> 2010/9/13 Willem Jiang<wi...@gmail.com>
>>>>
>>>> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>>>
>>>>>
>>>>>   Thanks Cristian,
>>>>>>
>>>>>> I kind of suspected that Servicemix had bundled this. Actually I ended
>>>>>> up
>>>>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>>>>> version.
>>>>>> Also wanted to see how easy/hard it was to accomplish.
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>>
>>>>> I just created a patch[1] for the hibernate-validator bundle, you may
>>>>> take
>>>>> a look if you want use it.
>>>>>
>>>>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>>
>>>>>   2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>
>>>>>>   Hello Bengt!
>>>>>>
>>>>>>>
>>>>>>> Sorry, I overlooked it.
>>>>>>> Apache Servicemix provides the OSGI-fied version for us. You can find
>>>>>>> the
>>>>>>> released version 4.0.2 here [1]
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Christian
>>>>>>>
>>>>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>   wrote:
>>>>>>>
>>>>>>>   Thanks for your reply Christian.
>>>>>>>
>>>>>>>>
>>>>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>>>>>>>>
>>>>>>>>   think
>>>>>>>
>>>>>>>   its the publicly released jar from JBoss which I had problems with. I
>>>>>>>>
>>>>>>>>   tried
>>>>>>>
>>>>>>>   to use the OSGi wrapped version they use in Glassfish:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>>>>
>>>>>>>
>>>>>>>> But it turns out it requires the packages
>>>>>>>> "org.glassfish.api.naming.*"
>>>>>>>>
>>>>>>>>   that
>>>>>>>
>>>>>>>   I assume only exist in Glassfish.
>>>>>>>>
>>>>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned
>>>>>>>> above.
>>>>>>>> From
>>>>>>>> where does Camel take it?
>>>>>>>>
>>>>>>>> I don't quite understand how Camel can use the non-OSGi:fied version
>>>>>>>> of
>>>>>>>> hibernate-validator. Have you tried this deployed in an OSGi
>>>>>>>> container?
>>>>>>>>
>>>>>>>> /Bengt
>>>>>>>>
>>>>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>>>
>>>>>>>>   Hello Bengt,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> we use the following on [1]. I think we could also update to 4.1.0.
>>>>>>>>> I
>>>>>>>>> opened
>>>>>>>>> a JIRA for it [2].
>>>>>>>>>
>>>>>>>>> Hope this helps,
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>>>>
>>>>>>>   [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>>>
>>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>   I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   not
>>>>>>>>>
>>>>>>>>
>>>>>>>   currently doing it with Camel but thought I might ask for help here
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>   anyway.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>>>>>>>>>>
>>>>>>>>>>   API
>>>>>>>>>
>>>>>>>>
>>>>>>>   (java.validation) and Hibernate's reference implementation
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>   (preferably
>>>>>>>>>
>>>>>>>>
>>>>>>>   the
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   latest version which I believe is 4.1). I haven't been able to find
>>>>>>>>>>
>>>>>>>>>>   one.
>>>>>>>>>
>>>>>>>>
>>>>>>>>   The
>>>>>>>>>
>>>>>>>>>> only one I've found is bundled for Glassfish but has dependencies
>>>>>>>>>> on
>>>>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>>>>
>>>>>>>>>>   Glassfish.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>>>>
>>>>>>>>>>   wondering
>>>>>>>>>
>>>>>>>>
>>>>>>>>   if
>>>>>>>>>
>>>>>>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>>>>>>
>>>>>>>>>> /Bengt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

Willem,

Not sure what you mean. I solved the problem by exporting the META-INF and
the META-INF.services "packages". That's all it took.

However, your version does not seem to work since no default provider can be
found

...Aha now I see what you wrote in your mail... You mean you need to hack
the VALIDATOR API to get it to work. I just wrapped the validator API
(without hacks) and it works IF you export the META-INF.services package.
Isn't that preferrable to hacking the validator API?

/Bengt

2010/9/16 Willem Jiang <wi...@gmail.com>

> Oh, you need to make sure the bean validator API can find the implementor
> jars in OSGi container.
> ServiceMix did some work by introducing the service locator to search the
> service from META-INF/services, and you may also need to hack the validator
> API by using the locator to find the service from META-INF/services.
>
> If you like you can take a look at the code here[1]
>
> [1] https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator
>
> Willem
>
>
> On 9/16/10 2:39 PM, Bengt Rodehav wrote:
>
>> Willem,
>>
>> I ended up using my own wrapped version mostly for learning reasons.
>> However, I had some problems with my wrapped version. I deployed it in the
>> container but in runtime I got error messages saying that no default
>> provider could be found. I then noticed that I hadn't exported the
>> META-INF/services "package" from the bundle. When I did that, the error
>> message disappeared and the validator worked.
>>
>> I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
>> Hibernate Validator. It seems to have the same problem. Maybe someone
>> should
>> look into this?
>>
>> /Bengt
>>
>> 2010/9/13 Bengt Rodehav<be...@rodehav.com>
>>
>>  Thanks, I'll have a look,
>>>
>>> /Bengt
>>>
>>> 2010/9/13 Willem Jiang<wi...@gmail.com>
>>>
>>> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>>
>>>>
>>>>  Thanks Cristian,
>>>>>
>>>>> I kind of suspected that Servicemix had bundled this. Actually I ended
>>>>> up
>>>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>>>> version.
>>>>> Also wanted to see how easy/hard it was to accomplish.
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>> I just created a patch[1] for the hibernate-validator bundle, you may
>>>> take
>>>> a look if you want use it.
>>>>
>>>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>>>
>>>> Willem
>>>>
>>>>
>>>>
>>>>  2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>
>>>>>  Hello Bengt!
>>>>>
>>>>>>
>>>>>> Sorry, I overlooked it.
>>>>>> Apache Servicemix provides the OSGI-fied version for us. You can find
>>>>>> the
>>>>>> released version 4.0.2 here [1]
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>>>
>>>>>> Cheers,
>>>>>> Christian
>>>>>>
>>>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>  wrote:
>>>>>>
>>>>>>  Thanks for your reply Christian.
>>>>>>
>>>>>>>
>>>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>>>>>>>
>>>>>>>  think
>>>>>>
>>>>>>  its the publicly released jar from JBoss which I had problems with. I
>>>>>>>
>>>>>>>  tried
>>>>>>
>>>>>>  to use the OSGi wrapped version they use in Glassfish:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>>>
>>>>>>
>>>>>>> But it turns out it requires the packages
>>>>>>> "org.glassfish.api.naming.*"
>>>>>>>
>>>>>>>  that
>>>>>>
>>>>>>  I assume only exist in Glassfish.
>>>>>>>
>>>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned
>>>>>>> above.
>>>>>>> From
>>>>>>> where does Camel take it?
>>>>>>>
>>>>>>> I don't quite understand how Camel can use the non-OSGi:fied version
>>>>>>> of
>>>>>>> hibernate-validator. Have you tried this deployed in an OSGi
>>>>>>> container?
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>>
>>>>>>>  Hello Bengt,
>>>>>>>
>>>>>>>>
>>>>>>>> we use the following on [1]. I think we could also update to 4.1.0.
>>>>>>>> I
>>>>>>>> opened
>>>>>>>> a JIRA for it [2].
>>>>>>>>
>>>>>>>> Hope this helps,
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>>>
>>>>>>  [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>>
>>>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>>  I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  not
>>>>>>>>
>>>>>>>
>>>>>>  currently doing it with Camel but thought I might ask for help here
>>>>>>>
>>>>>>>>
>>>>>>>>>  anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>>>>>>>>>
>>>>>>>>>  API
>>>>>>>>
>>>>>>>
>>>>>>  (java.validation) and Hibernate's reference implementation
>>>>>>>
>>>>>>>>
>>>>>>>>>  (preferably
>>>>>>>>
>>>>>>>
>>>>>>  the
>>>>>>>
>>>>>>>>
>>>>>>>>  latest version which I believe is 4.1). I haven't been able to find
>>>>>>>>>
>>>>>>>>>  one.
>>>>>>>>
>>>>>>>
>>>>>>>  The
>>>>>>>>
>>>>>>>>> only one I've found is bundled for Glassfish but has dependencies
>>>>>>>>> on
>>>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>>>
>>>>>>>>>  Glassfish.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>  Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>>>
>>>>>>>>>  wondering
>>>>>>>>
>>>>>>>
>>>>>>>  if
>>>>>>>>
>>>>>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>>>>>
>>>>>>>>> /Bengt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Willem Jiang <wi...@gmail.com>.

Oh, you need to make sure the bean validator API can find the 
implementor jars in OSGi container.
ServiceMix did some work by introducing the service locator to search 
the service from META-INF/services, and you may also need to hack the 
validator API by using the locator to find the service from 
META-INF/services.

If you like you can take a look at the code here[1]

[1] https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator

Willem

On 9/16/10 2:39 PM, Bengt Rodehav wrote:
> Willem,
>
> I ended up using my own wrapped version mostly for learning reasons.
> However, I had some problems with my wrapped version. I deployed it in the
> container but in runtime I got error messages saying that no default
> provider could be found. I then noticed that I hadn't exported the
> META-INF/services "package" from the bundle. When I did that, the error
> message disappeared and the validator worked.
>
> I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
> Hibernate Validator. It seems to have the same problem. Maybe someone should
> look into this?
>
> /Bengt
>
> 2010/9/13 Bengt Rodehav<be...@rodehav.com>
>
>> Thanks, I'll have a look,
>>
>> /Bengt
>>
>> 2010/9/13 Willem Jiang<wi...@gmail.com>
>>
>> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>>
>>>> Thanks Cristian,
>>>>
>>>> I kind of suspected that Servicemix had bundled this. Actually I ended up
>>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>>> version.
>>>> Also wanted to see how easy/hard it was to accomplish.
>>>>
>>>> /Bengt
>>>>
>>>
>>> I just created a patch[1] for the hibernate-validator bundle, you may take
>>> a look if you want use it.
>>>
>>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>>
>>> Willem
>>>
>>>
>>>
>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>
>>>>   Hello Bengt!
>>>>>
>>>>> Sorry, I overlooked it.
>>>>> Apache Servicemix provides the OSGI-fied version for us. You can find
>>>>> the
>>>>> released version 4.0.2 here [1]
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>>
>>>>> Cheers,
>>>>> Christian
>>>>>
>>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>   wrote:
>>>>>
>>>>>   Thanks for your reply Christian.
>>>>>>
>>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>>>>>>
>>>>> think
>>>>>
>>>>>> its the publicly released jar from JBoss which I had problems with. I
>>>>>>
>>>>> tried
>>>>>
>>>>>> to use the OSGi wrapped version they use in Glassfish:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>>
>>>>>>
>>>>>> But it turns out it requires the packages "org.glassfish.api.naming.*"
>>>>>>
>>>>> that
>>>>>
>>>>>> I assume only exist in Glassfish.
>>>>>>
>>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned above.
>>>>>> From
>>>>>> where does Camel take it?
>>>>>>
>>>>>> I don't quite understand how Camel can use the non-OSGi:fied version of
>>>>>> hibernate-validator. Have you tried this deployed in an OSGi container?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>>
>>>>>>   Hello Bengt,
>>>>>>>
>>>>>>> we use the following on [1]. I think we could also update to 4.1.0. I
>>>>>>> opened
>>>>>>> a JIRA for it [2].
>>>>>>>
>>>>>>> Hope this helps,
>>>>>>> Christian
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>>
>>>>>> [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>   I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>>>>>>>>
>>>>>>> not
>>>>>
>>>>>> currently doing it with Camel but thought I might ask for help here
>>>>>>>>
>>>>>>> anyway.
>>>>>>>
>>>>>>>>
>>>>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>>>>>>>>
>>>>>>> API
>>>>>
>>>>>> (java.validation) and Hibernate's reference implementation
>>>>>>>>
>>>>>>> (preferably
>>>>>
>>>>>> the
>>>>>>>
>>>>>>>> latest version which I believe is 4.1). I haven't been able to find
>>>>>>>>
>>>>>>> one.
>>>>>>
>>>>>>> The
>>>>>>>> only one I've found is bundled for Glassfish but has dependencies on
>>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>>
>>>>>>> Glassfish.
>>>>>>
>>>>>>>
>>>>>>>> Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>>
>>>>>>> wondering
>>>>>>
>>>>>>> if
>>>>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>>>>
>>>>>>>> /Bengt
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

Willem,

I ended up using my own wrapped version mostly for learning reasons.
However, I had some problems with my wrapped version. I deployed it in the
container but in runtime I got error messages saying that no default
provider could be found. I then noticed that I hadn't exported the
META-INF/services "package" from the bundle. When I did that, the error
message disappeared and the validator worked.

I then tested your (ServiceMix) wrapped version of the 4.0.2 version of
Hibernate Validator. It seems to have the same problem. Maybe someone should
look into this?

/Bengt

2010/9/13 Bengt Rodehav <be...@rodehav.com>

> Thanks, I'll have a look,
>
> /Bengt
>
> 2010/9/13 Willem Jiang <wi...@gmail.com>
>
> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>>
>>> Thanks Cristian,
>>>
>>> I kind of suspected that Servicemix had bundled this. Actually I ended up
>>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>>> version.
>>> Also wanted to see how easy/hard it was to accomplish.
>>>
>>> /Bengt
>>>
>>
>> I just created a patch[1] for the hibernate-validator bundle, you may take
>> a look if you want use it.
>>
>> [1] https://issues.apache.org/activemq/browse/SMX4-592
>>
>> Willem
>>
>>
>>
>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>
>>>  Hello Bengt!
>>>>
>>>> Sorry, I overlooked it.
>>>> Apache Servicemix provides the OSGI-fied version for us. You can find
>>>> the
>>>> released version 4.0.2 here [1]
>>>>
>>>> [1]
>>>>
>>>>
>>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>>
>>>> Cheers,
>>>> Christian
>>>>
>>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>>  wrote:
>>>>
>>>>  Thanks for your reply Christian.
>>>>>
>>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>>>>>
>>>> think
>>>>
>>>>> its the publicly released jar from JBoss which I had problems with. I
>>>>>
>>>> tried
>>>>
>>>>> to use the OSGi wrapped version they use in Glassfish:
>>>>>
>>>>>
>>>>>
>>>>>
>>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>>
>>>>>
>>>>> But it turns out it requires the packages "org.glassfish.api.naming.*"
>>>>>
>>>> that
>>>>
>>>>> I assume only exist in Glassfish.
>>>>>
>>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>>> javax.validation. Glassfish wraps it in the same jar I mentioned above.
>>>>> From
>>>>> where does Camel take it?
>>>>>
>>>>> I don't quite understand how Camel can use the non-OSGi:fied version of
>>>>> hibernate-validator. Have you tried this deployed in an OSGi container?
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>>
>>>>>  Hello Bengt,
>>>>>>
>>>>>> we use the following on [1]. I think we could also update to 4.1.0. I
>>>>>> opened
>>>>>> a JIRA for it [2].
>>>>>>
>>>>>> Hope this helps,
>>>>>> Christian
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>>
>>>>> [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>  I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>>>>>>>
>>>>>> not
>>>>
>>>>> currently doing it with Camel but thought I might ask for help here
>>>>>>>
>>>>>> anyway.
>>>>>>
>>>>>>>
>>>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>>>>>>>
>>>>>> API
>>>>
>>>>> (java.validation) and Hibernate's reference implementation
>>>>>>>
>>>>>> (preferably
>>>>
>>>>> the
>>>>>>
>>>>>>> latest version which I believe is 4.1). I haven't been able to find
>>>>>>>
>>>>>> one.
>>>>>
>>>>>> The
>>>>>>> only one I've found is bundled for Glassfish but has dependencies on
>>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>>
>>>>>> Glassfish.
>>>>>
>>>>>>
>>>>>>> Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>>
>>>>>> wondering
>>>>>
>>>>>> if
>>>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

Thanks, I'll have a look,

/Bengt

2010/9/13 Willem Jiang <wi...@gmail.com>

> On 9/13/10 3:58 AM, Bengt Rodehav wrote:
>
>> Thanks Cristian,
>>
>> I kind of suspected that Servicemix had bundled this. Actually I ended up
>> doing my own bundling anyway since I wanted to use the 4.1.0.Final
>> version.
>> Also wanted to see how easy/hard it was to accomplish.
>>
>> /Bengt
>>
>
> I just created a patch[1] for the hibernate-validator bundle, you may take
> a look if you want use it.
>
> [1] https://issues.apache.org/activemq/browse/SMX4-592
>
> Willem
>
>
>
>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>
>>  Hello Bengt!
>>>
>>> Sorry, I overlooked it.
>>> Apache Servicemix provides the OSGI-fied version for us. You can find the
>>> released version 4.0.2 here [1]
>>>
>>> [1]
>>>
>>>
>>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>>
>>> Cheers,
>>> Christian
>>>
>>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>
>>>  wrote:
>>>
>>>  Thanks for your reply Christian.
>>>>
>>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>>>>
>>> think
>>>
>>>> its the publicly released jar from JBoss which I had problems with. I
>>>>
>>> tried
>>>
>>>> to use the OSGi wrapped version they use in Glassfish:
>>>>
>>>>
>>>>
>>>>
>>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>
>>>>
>>>> But it turns out it requires the packages "org.glassfish.api.naming.*"
>>>>
>>> that
>>>
>>>> I assume only exist in Glassfish.
>>>>
>>>> Related to the above, one also needs an OSGi bundle for the API:
>>>> javax.validation. Glassfish wraps it in the same jar I mentioned above.
>>>> From
>>>> where does Camel take it?
>>>>
>>>> I don't quite understand how Camel can use the non-OSGi:fied version of
>>>> hibernate-validator. Have you tried this deployed in an OSGi container?
>>>>
>>>> /Bengt
>>>>
>>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>>
>>>>  Hello Bengt,
>>>>>
>>>>> we use the following on [1]. I think we could also update to 4.1.0. I
>>>>> opened
>>>>> a JIRA for it [2].
>>>>>
>>>>> Hope this helps,
>>>>> Christian
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>>
>>>>
>>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>
>>>> [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>>
>>>>>
>>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>  I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>>>>>>
>>>>> not
>>>
>>>> currently doing it with Camel but thought I might ask for help here
>>>>>>
>>>>> anyway.
>>>>>
>>>>>>
>>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>>>>>>
>>>>> API
>>>
>>>> (java.validation) and Hibernate's reference implementation
>>>>>>
>>>>> (preferably
>>>
>>>> the
>>>>>
>>>>>> latest version which I believe is 4.1). I haven't been able to find
>>>>>>
>>>>> one.
>>>>
>>>>> The
>>>>>> only one I've found is bundled for Glassfish but has dependencies on
>>>>>> Glassfish specific classes and therefore doesn't work outside
>>>>>>
>>>>> Glassfish.
>>>>
>>>>>
>>>>>> Since Camel 2.4 contains the camel-bean-validator component I'm
>>>>>>
>>>>> wondering
>>>>
>>>>> if
>>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Willem Jiang <wi...@gmail.com>.

On 9/13/10 3:58 AM, Bengt Rodehav wrote:
> Thanks Cristian,
>
> I kind of suspected that Servicemix had bundled this. Actually I ended up
> doing my own bundling anyway since I wanted to use the 4.1.0.Final version.
> Also wanted to see how easy/hard it was to accomplish.
>
> /Bengt

I just created a patch[1] for the hibernate-validator bundle, you may 
take a look if you want use it.

[1] https://issues.apache.org/activemq/browse/SMX4-592

Willem

>
> 2010/9/11 Christian Müller<ch...@gmail.com>
>
>> Hello Bengt!
>>
>> Sorry, I overlooked it.
>> Apache Servicemix provides the OSGI-fied version for us. You can find the
>> released version 4.0.2 here [1]
>>
>> [1]
>>
>> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>>
>> Cheers,
>> Christian
>>
>> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav<be...@rodehav.com>  wrote:
>>
>>> Thanks for your reply Christian.
>>>
>>> However, the JAR you refer to isn't an OSGi bundle either. In fact I
>> think
>>> its the publicly released jar from JBoss which I had problems with. I
>> tried
>>> to use the OSGi wrapped version they use in Glassfish:
>>>
>>>
>>>
>> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>>>
>>> But it turns out it requires the packages "org.glassfish.api.naming.*"
>> that
>>> I assume only exist in Glassfish.
>>>
>>> Related to the above, one also needs an OSGi bundle for the API:
>>> javax.validation. Glassfish wraps it in the same jar I mentioned above.
>>> From
>>> where does Camel take it?
>>>
>>> I don't quite understand how Camel can use the non-OSGi:fied version of
>>> hibernate-validator. Have you tried this deployed in an OSGi container?
>>>
>>> /Bengt
>>>
>>> 2010/9/11 Christian Müller<ch...@gmail.com>
>>>
>>>> Hello Bengt,
>>>>
>>>> we use the following on [1]. I think we could also update to 4.1.0. I
>>>> opened
>>>> a JIRA for it [2].
>>>>
>>>> Hope this helps,
>>>> Christian
>>>>
>>>> [1]
>>>>
>>>>
>>>
>> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
>>>> [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>>>>
>>>>
>>>> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav<be...@rodehav.com>
>>> wrote:
>>>>
>>>>> I''m experimenting with the Java Bean Validation API (JSR 303). I'm
>> not
>>>>> currently doing it with Camel but thought I might ask for help here
>>>> anyway.
>>>>>
>>>>> I'm deploying in an OSGi context and need OSGi bundles for both the
>> API
>>>>> (java.validation) and Hibernate's reference implementation
>> (preferably
>>>> the
>>>>> latest version which I believe is 4.1). I haven't been able to find
>>> one.
>>>>> The
>>>>> only one I've found is bundled for Glassfish but has dependencies on
>>>>> Glassfish specific classes and therefore doesn't work outside
>>> Glassfish.
>>>>>
>>>>> Since Camel 2.4 contains the camel-bean-validator component I'm
>>> wondering
>>>>> if
>>>>> anyone can tell me how this problem was solved in Camel.
>>>>>
>>>>> /Bengt
>>>>>
>>>>
>>>
>>
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

Thanks Cristian,

I kind of suspected that Servicemix had bundled this. Actually I ended up
doing my own bundling anyway since I wanted to use the 4.1.0.Final version.
Also wanted to see how easy/hard it was to accomplish.

/Bengt

2010/9/11 Christian Müller <ch...@gmail.com>

> Hello Bengt!
>
> Sorry, I overlooked it.
> Apache Servicemix provides the OSGI-fied version for us. You can find the
> released version 4.0.2 here [1]
>
> [1]
>
> http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/
>
> Cheers,
> Christian
>
> On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > Thanks for your reply Christian.
> >
> > However, the JAR you refer to isn't an OSGi bundle either. In fact I
> think
> > its the publicly released jar from JBoss which I had problems with. I
> tried
> > to use the OSGi wrapped version they use in Glassfish:
> >
> >
> >
> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
> >
> > But it turns out it requires the packages "org.glassfish.api.naming.*"
> that
> > I assume only exist in Glassfish.
> >
> > Related to the above, one also needs an OSGi bundle for the API:
> > javax.validation. Glassfish wraps it in the same jar I mentioned above.
> > From
> > where does Camel take it?
> >
> > I don't quite understand how Camel can use the non-OSGi:fied version of
> > hibernate-validator. Have you tried this deployed in an OSGi container?
> >
> > /Bengt
> >
> > 2010/9/11 Christian Müller <ch...@gmail.com>
> >
> > > Hello Bengt,
> > >
> > > we use the following on [1]. I think we could also update to 4.1.0. I
> > > opened
> > > a JIRA for it [2].
> > >
> > > Hope this helps,
> > > Christian
> > >
> > > [1]
> > >
> > >
> >
> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
> > > [2] https://issues.apache.org/activemq/browse/CAMEL-3115
> > >
> > >
> > > On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav <be...@rodehav.com>
> > wrote:
> > >
> > > > I''m experimenting with the Java Bean Validation API (JSR 303). I'm
> not
> > > > currently doing it with Camel but thought I might ask for help here
> > > anyway.
> > > >
> > > > I'm deploying in an OSGi context and need OSGi bundles for both the
> API
> > > > (java.validation) and Hibernate's reference implementation
> (preferably
> > > the
> > > > latest version which I believe is 4.1). I haven't been able to find
> > one.
> > > > The
> > > > only one I've found is bundled for Glassfish but has dependencies on
> > > > Glassfish specific classes and therefore doesn't work outside
> > Glassfish.
> > > >
> > > > Since Camel 2.4 contains the camel-bean-validator component I'm
> > wondering
> > > > if
> > > > anyone can tell me how this problem was solved in Camel.
> > > >
> > > > /Bengt
> > > >
> > >
> >
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Christian Müller <ch...@gmail.com>.

Hello Bengt!

Sorry, I overlooked it.
Apache Servicemix provides the OSGI-fied version for us. You can find the
released version 4.0.2 here [1]

[1]
http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/

Cheers,
Christian

On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav <be...@rodehav.com> wrote:

> Thanks for your reply Christian.
>
> However, the JAR you refer to isn't an OSGi bundle either. In fact I think
> its the publicly released jar from JBoss which I had problems with. I tried
> to use the OSGi wrapped version they use in Glassfish:
>
>
> http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar
>
> But it turns out it requires the packages "org.glassfish.api.naming.*" that
> I assume only exist in Glassfish.
>
> Related to the above, one also needs an OSGi bundle for the API:
> javax.validation. Glassfish wraps it in the same jar I mentioned above.
> From
> where does Camel take it?
>
> I don't quite understand how Camel can use the non-OSGi:fied version of
> hibernate-validator. Have you tried this deployed in an OSGi container?
>
> /Bengt
>
> 2010/9/11 Christian Müller <ch...@gmail.com>
>
> > Hello Bengt,
> >
> > we use the following on [1]. I think we could also update to 4.1.0. I
> > opened
> > a JIRA for it [2].
> >
> > Hope this helps,
> > Christian
> >
> > [1]
> >
> >
> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
> > [2] https://issues.apache.org/activemq/browse/CAMEL-3115
> >
> >
> > On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >
> > > I''m experimenting with the Java Bean Validation API (JSR 303). I'm not
> > > currently doing it with Camel but thought I might ask for help here
> > anyway.
> > >
> > > I'm deploying in an OSGi context and need OSGi bundles for both the API
> > > (java.validation) and Hibernate's reference implementation (preferably
> > the
> > > latest version which I believe is 4.1). I haven't been able to find
> one.
> > > The
> > > only one I've found is bundled for Glassfish but has dependencies on
> > > Glassfish specific classes and therefore doesn't work outside
> Glassfish.
> > >
> > > Since Camel 2.4 contains the camel-bean-validator component I'm
> wondering
> > > if
> > > anyone can tell me how this problem was solved in Camel.
> > >
> > > /Bengt
> > >
> >
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Bengt Rodehav <be...@rodehav.com>.

Thanks for your reply Christian.

However, the JAR you refer to isn't an OSGi bundle either. In fact I think
its the publicly released jar from JBoss which I had problems with. I tried
to use the OSGi wrapped version they use in Glassfish:

http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar

But it turns out it requires the packages "org.glassfish.api.naming.*" that
I assume only exist in Glassfish.

Related to the above, one also needs an OSGi bundle for the API:
javax.validation. Glassfish wraps it in the same jar I mentioned above. From
where does Camel take it?

I don't quite understand how Camel can use the non-OSGi:fied version of
hibernate-validator. Have you tried this deployed in an OSGi container?

/Bengt

2010/9/11 Christian Müller <ch...@gmail.com>

> Hello Bengt,
>
> we use the following on [1]. I think we could also update to 4.1.0. I
> opened
> a JIRA for it [2].
>
> Hope this helps,
> Christian
>
> [1]
>
> http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
> [2] https://issues.apache.org/activemq/browse/CAMEL-3115
>
>
> On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > I''m experimenting with the Java Bean Validation API (JSR 303). I'm not
> > currently doing it with Camel but thought I might ask for help here
> anyway.
> >
> > I'm deploying in an OSGi context and need OSGi bundles for both the API
> > (java.validation) and Hibernate's reference implementation (preferably
> the
> > latest version which I believe is 4.1). I haven't been able to find one.
> > The
> > only one I've found is bundled for Glassfish but has dependencies on
> > Glassfish specific classes and therefore doesn't work outside Glassfish.
> >
> > Since Camel 2.4 contains the camel-bean-validator component I'm wondering
> > if
> > anyone can tell me how this problem was solved in Camel.
> >
> > /Bengt
> >
>

Re: camel-bean-validator and hibernate-validator for OSGi

Posted by Christian Müller <ch...@gmail.com>.

Hello Bengt,

we use the following on [1]. I think we could also update to 4.1.0. I opened
a JIRA for it [2].

Hope this helps,
Christian

[1]
http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar
[2] https://issues.apache.org/activemq/browse/CAMEL-3115


On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav <be...@rodehav.com> wrote:

> I''m experimenting with the Java Bean Validation API (JSR 303). I'm not
> currently doing it with Camel but thought I might ask for help here anyway.
>
> I'm deploying in an OSGi context and need OSGi bundles for both the API
> (java.validation) and Hibernate's reference implementation (preferably the
> latest version which I believe is 4.1). I haven't been able to find one.
> The
> only one I've found is bundled for Glassfish but has dependencies on
> Glassfish specific classes and therefore doesn't work outside Glassfish.
>
> Since Camel 2.4 contains the camel-bean-validator component I'm wondering
> if
> anyone can tell me how this problem was solved in Camel.
>
> /Bengt
>