You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Katya Todorova <ka...@gmail.com> on 2012/02/13 10:55:48 UTC
Thread context class loader delegation in openEJB
Hi guys,
While trying to run openEJB in OSGi, I came across an issue with
validator provider detection. It turned out that
org.apache.openejb.assembler.classic.ValidatorBuilder class uses its
own loader to look for available providers.
This causes problems when openEJB is not embedded in an application.
Shouldn't the ejb container use the current TCCL (application loader)
instead of resetting it to its own loader?
(ValidatorBuilder#getConfig: 116)
Thank you in advance for your help,
Katya
Re: Thread context class loader delegation in openEJB
Posted by Katya Todorova <ka...@gmail.com>.
I see. Thank you for the pointers, Romain.
On Tue, Feb 14, 2012 at 3:09 PM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Hi Katya,
>
> yes it needs a validation.xml. I just added a system property
> "openejb.bean-validation.provider" to specify a global provider (qualified
> name as value).
>
> If i remember we are using geronimo osgi locator/registry stuff to get
> META-INF/services info.
>
> Once again if i remember the main issues with OSGi was when we were using
> the app classloader and the app was not importing anything of openejb/bval.
> The goal was mainly to be able to deploy an app without needing to import
> openejb (which IMHO breaks a bit OSGi but is probably more logical for an
> app server)
>
> - Romain
>
>
> 2012/2/14 Katya Todorova <ka...@gmail.com>
>
>> Hi Romain,
>>
>> Specifying a custom provider would require adding a validation.xml to
>> every deployed app? Is this the only option?
>>
>> Regarding the OSGi issues, I think I'm missing something in the current
>> setup:
>> - openEJB has optional imports to bval but not to META-INF/services
>> - bval declares validator provider via META-INF/services but it
>> doesn't export the "package"
>> If so, I don't see how openEJB would find the declared in bval
>> provider. How this is supposed to work in standard OSGi environment?
>>
>> What kind of OSGi issues you have overcome with setting openEJB loader
>> as TCCL in case of default provider?
>>
>> Thank you very much,
>> Katya
>>
>>
>> On Mon, Feb 13, 2012 at 7:02 PM, Romain Manni-Bucau
>> <rm...@gmail.com> wrote:
>> > Hi Katya,
>> >
>> > we use this classloader when using the default provider so we want to be
>> > sure it is our default provider. If you specify the provider manually we
>> > are using the TCCL (line 97) so it should be ok.
>> >
>> > Maybe try forcing the provider...
>> >
>> > The reason why we resetted the classloader like this when falling back to
>> > the default provider was to avoid to get OSGi issues.
>> >
>> > - Romain
>> >
>> >
>> > 2012/2/13 Katya Todorova <ka...@gmail.com>
>> >
>> >> Hi guys,
>> >>
>> >> While trying to run openEJB in OSGi, I came across an issue with
>> >> validator provider detection. It turned out that
>> >> org.apache.openejb.assembler.classic.ValidatorBuilder class uses its
>> >> own loader to look for available providers.
>> >> This causes problems when openEJB is not embedded in an application.
>> >> Shouldn't the ejb container use the current TCCL (application loader)
>> >> instead of resetting it to its own loader?
>> >> (ValidatorBuilder#getConfig: 116)
>> >>
>> >> Thank you in advance for your help,
>> >> Katya
>> >>
>>
Re: Thread context class loader delegation in openEJB
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Katya,
yes it needs a validation.xml. I just added a system property
"openejb.bean-validation.provider" to specify a global provider (qualified
name as value).
If i remember we are using geronimo osgi locator/registry stuff to get
META-INF/services info.
Once again if i remember the main issues with OSGi was when we were using
the app classloader and the app was not importing anything of openejb/bval.
The goal was mainly to be able to deploy an app without needing to import
openejb (which IMHO breaks a bit OSGi but is probably more logical for an
app server)
- Romain
2012/2/14 Katya Todorova <ka...@gmail.com>
> Hi Romain,
>
> Specifying a custom provider would require adding a validation.xml to
> every deployed app? Is this the only option?
>
> Regarding the OSGi issues, I think I'm missing something in the current
> setup:
> - openEJB has optional imports to bval but not to META-INF/services
> - bval declares validator provider via META-INF/services but it
> doesn't export the "package"
> If so, I don't see how openEJB would find the declared in bval
> provider. How this is supposed to work in standard OSGi environment?
>
> What kind of OSGi issues you have overcome with setting openEJB loader
> as TCCL in case of default provider?
>
> Thank you very much,
> Katya
>
>
> On Mon, Feb 13, 2012 at 7:02 PM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > Hi Katya,
> >
> > we use this classloader when using the default provider so we want to be
> > sure it is our default provider. If you specify the provider manually we
> > are using the TCCL (line 97) so it should be ok.
> >
> > Maybe try forcing the provider...
> >
> > The reason why we resetted the classloader like this when falling back to
> > the default provider was to avoid to get OSGi issues.
> >
> > - Romain
> >
> >
> > 2012/2/13 Katya Todorova <ka...@gmail.com>
> >
> >> Hi guys,
> >>
> >> While trying to run openEJB in OSGi, I came across an issue with
> >> validator provider detection. It turned out that
> >> org.apache.openejb.assembler.classic.ValidatorBuilder class uses its
> >> own loader to look for available providers.
> >> This causes problems when openEJB is not embedded in an application.
> >> Shouldn't the ejb container use the current TCCL (application loader)
> >> instead of resetting it to its own loader?
> >> (ValidatorBuilder#getConfig: 116)
> >>
> >> Thank you in advance for your help,
> >> Katya
> >>
>
Re: Thread context class loader delegation in openEJB
Posted by Katya Todorova <ka...@gmail.com>.
Hi Romain,
Specifying a custom provider would require adding a validation.xml to
every deployed app? Is this the only option?
Regarding the OSGi issues, I think I'm missing something in the current setup:
- openEJB has optional imports to bval but not to META-INF/services
- bval declares validator provider via META-INF/services but it
doesn't export the "package"
If so, I don't see how openEJB would find the declared in bval
provider. How this is supposed to work in standard OSGi environment?
What kind of OSGi issues you have overcome with setting openEJB loader
as TCCL in case of default provider?
Thank you very much,
Katya
On Mon, Feb 13, 2012 at 7:02 PM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Hi Katya,
>
> we use this classloader when using the default provider so we want to be
> sure it is our default provider. If you specify the provider manually we
> are using the TCCL (line 97) so it should be ok.
>
> Maybe try forcing the provider...
>
> The reason why we resetted the classloader like this when falling back to
> the default provider was to avoid to get OSGi issues.
>
> - Romain
>
>
> 2012/2/13 Katya Todorova <ka...@gmail.com>
>
>> Hi guys,
>>
>> While trying to run openEJB in OSGi, I came across an issue with
>> validator provider detection. It turned out that
>> org.apache.openejb.assembler.classic.ValidatorBuilder class uses its
>> own loader to look for available providers.
>> This causes problems when openEJB is not embedded in an application.
>> Shouldn't the ejb container use the current TCCL (application loader)
>> instead of resetting it to its own loader?
>> (ValidatorBuilder#getConfig: 116)
>>
>> Thank you in advance for your help,
>> Katya
>>
Re: Thread context class loader delegation in openEJB
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Katya,
we use this classloader when using the default provider so we want to be
sure it is our default provider. If you specify the provider manually we
are using the TCCL (line 97) so it should be ok.
Maybe try forcing the provider...
The reason why we resetted the classloader like this when falling back to
the default provider was to avoid to get OSGi issues.
- Romain
2012/2/13 Katya Todorova <ka...@gmail.com>
> Hi guys,
>
> While trying to run openEJB in OSGi, I came across an issue with
> validator provider detection. It turned out that
> org.apache.openejb.assembler.classic.ValidatorBuilder class uses its
> own loader to look for available providers.
> This causes problems when openEJB is not embedded in an application.
> Shouldn't the ejb container use the current TCCL (application loader)
> instead of resetting it to its own loader?
> (ValidatorBuilder#getConfig: 116)
>
> Thank you in advance for your help,
> Katya
>