tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katya Todorova <katya.k.todor...@gmail.com>
Subject Re: Thread context class loader delegation in openEJB
Date Tue, 14 Feb 2012 12:37:45 GMT
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
<rmannibucau@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 <katya.k.todorova@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
>>

Mime
View raw message