You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Carl Hall <ca...@gmail.com> on 2010/02/23 20:41:53 UTC
JTA Bundle
I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
version 1.1.1) but am hitting a snag. Other bundles seem to pick up
javax.transaction & javax.transaction.xa from the system bundle but
those packages don't offer all of JTA. I've seen this issue noted by
some folks with Karaf but haven't found a definitive answer, so I
bring the issue back up to the list. One suggestion was to use
-split-package on Export-Package but I've not had the best luck with
making that work. Another suggestion is to not export the noted
packages from the system bundle.
What should I do to fix this up?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Blueprint problem
Posted by Guillaume Nodet <gn...@gmail.com>.
I would consider mixing activators and blueprint a bad practice.
Anyway, the activator will be called synchronously when the bundle is
started, while the blueprint application is started asynchronously, so
you have no way to access the blueprint application from the
activator.
On Thu, Feb 25, 2010 at 15:26, <cr...@habuma.com> wrote:
>
> Furthermore, I find that with Blueprint services, I don't often (ever?)
> need an activator. Instead, I can create a bean whose init-method
> attribute is set to call some method at creation and/or whose
> destroy-method attribute is set to call some method at destruction. If I
> really need the bundle context, then I can wire it in. Something like
> this:
>
> <bean class="com.foo.bar.StarterBean" init-method="start">
> <property name="bundleContext" ref="blueprintBundleContext"/>
> </bean>
>
>
>
>
>> Hi,
>>
>> Blueprint services are created after the bundle is started, so after
>> the bundleactivator start method returns. This way you will not find
>> references to the services in the start method, and you should not
>> wait for the services in the start method as well, since it is
>> recommended that the start method returns as fast as possible.
>>
>> you can add the blueprintBundleContext to the blueprint managed beans
>> (this is the other way around).
>>
>> <property name="bundleContext" ref="blueprintBundleContext"/>
>>
>> Regards,
>> Leen
>>
>> On Thu, Feb 25, 2010 at 12:58 PM, 程操红 <cc...@ufida.com.cn> wrote:
>>> I'm trying to use blueprint. but i don't know how to inject a bean or
>>> a service declared in blueprint xml file
>>>
>>> to BundleActivator instance, Can anyone help me, thanks a lot.
>>>
>>>
>>> 2010-02-25
>>>
>>>
>>>
>>>
>>>
>>>
>>> tribon.cheng
>>> Beijing. China
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Re: Blueprint problem
Posted by Guillaume Nodet <gn...@gmail.com>.
Not sure how those bundles depend on each other, but in OSGI, there
are two ways:
* using packages, this is a static dependency
* using services, this should be dynamic dependency
If a bundle has a dependency on a service, it needs to be prepared to
the fact that the service
is not here yet or the fact that it can disappear at any time.
Blueprint handle that for you but if you use the OSGi API, you need to
take care of those yourself.
On Fri, Feb 26, 2010 at 01:35, cch <cc...@ufida.com.cn> wrote:
> thank you very much.
>
> Based on your explanation, I know activators should not mix with blueprint. This is indeed a bad practise.
>
> Why i take this problem is that i have a base common bundle, many other bundles depend on it,
>
> but the base bundle has multi implementations, i hope one can change the implementation throught blueprint config.
>
> so i set the base bundle startlevel a lower value, but because the blueprint appliction is started asynchronously,
>
> when other bundles use this base bundle, the base bundle isn't initialized correctly.
>
> Even i set the Spring-Context: create-asynchronously:=false , It still can't guarantee that the base bundle will
>
> be initialized before any other bundles.
>
> Any suggestions? change to service? set timeout? thanks!
>
>
> BundleA---->LogBundle---->Impl1,Impl2,Impl3 (set special implementation by blueprint file)
> BundleB----->LogBundle---->Impl1,Impl2,Impl3
>
>
>
> 2010-02-26
>
>
>
>
>
>
> cch
>
>
>
>
>
> 发件人： Guillaume Nodet
> 发送时间： 2010-02-25 22:40:39
> 收件人： users
> 抄送：
> 主题： Re: Blueprint problem
>
> I would consider mixing activators and blueprint a bad practice.
> Anyway, the activator will be called synchronously when the bundle is
> started, while the blueprint application is started asynchronously, so
> you have no way to access the blueprint application from the
> activator.
> On Thu, Feb 25, 2010 at 15:26, <cr...@habuma.com> wrote:
>>
>> Furthermore, I find that with Blueprint services, I don't often (ever?)
>> need an activator. Instead, I can create a bean whose init-method
>> attribute is set to call some method at creation and/or whose
>> destroy-method attribute is set to call some method at destruction. If I
>> really need the bundle context, then I can wire it in. Something like
>> this:
>>
>> <bean class="com.foo.bar.StarterBean" init-method="start">
>> <property name="bundleContext" ref="blueprintBundleContext"/>
>> </bean>
>>
>>
>>
>>
>>> Hi,
>>>
>>> Blueprint services are created after the bundle is started, so after
>>> the bundleactivator start method returns. This way you will not find
>>> references to the services in the start method, and you should not
>>> wait for the services in the start method as well, since it is
>>> recommended that the start method returns as fast as possible.
>>>
>>> you can add the blueprintBundleContext to the blueprint managed beans
>>> (this is the other way around).
>>>
>>> <property name="bundleContext" ref="blueprintBundleContext"/>
>>>
>>> Regards,
>>> Leen
>>>
>>> On Thu, Feb 25, 2010 at 12:58 PM, 程操红 <cc...@ufida.com.cn> wrote:
>>>> I'm trying to use blueprint. but i don't know how to inject a bean or
>>>> a service declared in blueprint xml file
>>>>
>>>> to BundleActivator instance, Can anyone help me, thanks a lot.
>>>>
>>>>
>>>> 2010-02-25
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> tribon.cheng
>>>> Beijing. China
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Re: Blueprint problem
Posted by cch <cc...@ufida.com.cn>.
thank you very much.
Based on your explanation, I know activators should not mix with blueprint. This is indeed a bad practise.
Why i take this problem is that i have a base common bundle, many other bundles depend on it,
but the base bundle has multi implementations, i hope one can change the implementation throught blueprint config.
so i set the base bundle startlevel a lower value, but because the blueprint appliction is started asynchronously,
when other bundles use this base bundle, the base bundle isn't initialized correctly.
Even i set the Spring-Context: create-asynchronously:=false , It still can't guarantee that the base bundle will
be initialized before any other bundles.
Any suggestions? change to service? set timeout? thanks!
BundleA---->LogBundle---->Impl1,Impl2,Impl3 (set special implementation by blueprint file)
BundleB----->LogBundle---->Impl1,Impl2,Impl3
2010-02-26
cch
发件人： Guillaume Nodet
发送时间： 2010-02-25 22:40:39
收件人： users
抄送：
主题： Re: Blueprint problem
I would consider mixing activators and blueprint a bad practice.
Anyway, the activator will be called synchronously when the bundle is
started, while the blueprint application is started asynchronously, so
you have no way to access the blueprint application from the
activator.
On Thu, Feb 25, 2010 at 15:26, <cr...@habuma.com> wrote:
>
> Furthermore, I find that with Blueprint services, I don't often (ever?)
> need an activator. Instead, I can create a bean whose init-method
> attribute is set to call some method at creation and/or whose
> destroy-method attribute is set to call some method at destruction. If I
> really need the bundle context, then I can wire it in. Something like
> this:
>
> <bean class="com.foo.bar.StarterBean" init-method="start">
> <property name="bundleContext" ref="blueprintBundleContext"/>
> </bean>
>
>
>
>
>> Hi,
>>
>> Blueprint services are created after the bundle is started, so after
>> the bundleactivator start method returns. This way you will not find
>> references to the services in the start method, and you should not
>> wait for the services in the start method as well, since it is
>> recommended that the start method returns as fast as possible.
>>
>> you can add the blueprintBundleContext to the blueprint managed beans
>> (this is the other way around).
>>
>> <property name="bundleContext" ref="blueprintBundleContext"/>
>>
>> Regards,
>> Leen
>>
>> On Thu, Feb 25, 2010 at 12:58 PM, 程操红 <cc...@ufida.com.cn> wrote:
>>> I'm trying to use blueprint. but i don't know how to inject a bean or
>>> a service declared in blueprint xml file
>>>
>>> to BundleActivator instance, Can anyone help me, thanks a lot.
>>>
>>>
>>> 2010-02-25
>>>
>>>
>>>
>>>
>>>
>>>
>>> tribon.cheng
>>> Beijing. China
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Blueprint problem
Posted by cr...@habuma.com.
Furthermore, I find that with Blueprint services, I don't often (ever?)
need an activator. Instead, I can create a bean whose init-method
attribute is set to call some method at creation and/or whose
destroy-method attribute is set to call some method at destruction. If I
really need the bundle context, then I can wire it in. Something like
this:
<bean class="com.foo.bar.StarterBean" init-method="start">
<property name="bundleContext" ref="blueprintBundleContext"/>
</bean>
> Hi,
>
> Blueprint services are created after the bundle is started, so after
> the bundleactivator start method returns. This way you will not find
> references to the services in the start method, and you should not
> wait for the services in the start method as well, since it is
> recommended that the start method returns as fast as possible.
>
> you can add the blueprintBundleContext to the blueprint managed beans
> (this is the other way around).
>
> <property name="bundleContext" ref="blueprintBundleContext"/>
>
> Regards,
> Leen
>
> On Thu, Feb 25, 2010 at 12:58 PM, ç¨æ红 <cc...@ufida.com.cn> wrote:
>> I'm trying to use blueprint. but  i don't know how to inject a bean or
>> a service declared in blueprint xml file
>>
>> to BundleActivator instance, Can anyone help me, thanks a lot.
>>
>>
>> 2010-02-25
>>
>>
>>
>>
>>
>>
>> tribon.cheng
>> Beijing. China
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Blueprint problem
Posted by Leen Toelen <to...@gmail.com>.
Hi,
Blueprint services are created after the bundle is started, so after
the bundleactivator start method returns. This way you will not find
references to the services in the start method, and you should not
wait for the services in the start method as well, since it is
recommended that the start method returns as fast as possible.
you can add the blueprintBundleContext to the blueprint managed beans
(this is the other way around).
<property name="bundleContext" ref="blueprintBundleContext"/>
Regards,
Leen
On Thu, Feb 25, 2010 at 12:58 PM, 程操红 <cc...@ufida.com.cn> wrote:
> I'm trying to use blueprint. but i don't know how to inject a bean or a service declared in blueprint xml file
>
> to BundleActivator instance, Can anyone help me, thanks a lot.
>
>
> 2010-02-25
>
>
>
>
>
>
> tribon.cheng
> Beijing. China
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Blueprint problem
Posted by 程操红 <cc...@ufida.com.cn>.
I'm trying to use blueprint. but i don't know how to inject a bean or a service declared in blueprint xml file
to BundleActivator instance, Can anyone help me, thanks a lot.
2010-02-25
tribon.cheng
Beijing. China
Re: JTA Bundle
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
On my side, I simply added the geronimo jars into my main bundle and export
them with a version 2.0.0. Then my clients bundles can import version 2.0.0.
Of course, that's because I don't deploy 3rd parties bundles that would make
use
of those.
Hacked around, but working.
/jog
On Tue, Feb 23, 2010 at 2:41 PM, Carl Hall <ca...@gmail.com> wrote:
> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
> javax.transaction & javax.transaction.xa from the system bundle but
> those packages don't offer all of JTA. I've seen this issue noted by
> some folks with Karaf but haven't found a definitive answer, so I
> bring the issue back up to the list. One suggestion was to use
> -split-package on Export-Package but I've not had the best luck with
> making that work. Another suggestion is to not export the noted
> packages from the system bundle.
>
> What should I do to fix this up?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: JTA Bundle
Posted by Carl Hall <ca...@gmail.com>.
I beginning to understand more about the "partial=true;
mandatory:=partial" flags. Is this something that should be done for
the system bundle in Felix or is JTA in the system bundle considered
complete by the JavaSE definition?
On Tue, Feb 23, 2010 at 15:40, Carl Hall <ca...@gmail.com> wrote:
> I've been able to see this load correctly (no errors in the logs as
> before) by using split-package. If I go this route, which option
> should I use (merge-first, merge-last, first)?
>
> Adding a flag to the import (partial) is not an option for us as JTA
> is being imported by bundles that we have no control over.
>
>
> On Tue, Feb 23, 2010 at 14:58, Guillaume Nodet <gn...@gmail.com> wrote:
>> The reason to keep it is that there is a boot delegation for the
>> javax.transaction.* packages.
>> This is to avoid class cast exception in the javax.sql packages which
>> do use the classes from the javax.transaction package exported by the
>> system bundle.
>> So what happens is that the javax.transaction package from the jre and
>> the one exported by the jta bundle will actually get merged (i.e.
>> you'll wire on the jta bundle, but you'll use the classes from the jre
>> when they are defined).
>>
>> On Tue, Feb 23, 2010 at 20:48, Clifford H. James <cj...@proteuseng.com> wrote:
>>> Karaf adds a mandatory attribute (partial) to the system package export in
>>> etc/config.properties:
>>>
>>> javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \
>>>
>>> I believe this is so that you'd resolve this version of
>>> javax.transaction/transaction.xa IFF the importer
>>> specified partial=true on the Import-Package stmt.
>>>
>>> That way if you have a bundle exporting these packages as well, they don't
>>> conflict with the system package because without the mandatory attribute, it
>>> won't wire. I suppose you could just have removed it from the systemPackage
>>> list as well but I guess this gives the importer the flexible to take the
>>> default one if he/she so desires???
>>>
>>> My experience with split-packages has made me try to avoid it if at all
>>> possible.
>>>
>>> -Cliff James
>>>
>>> Carl Hall wrote:
>>>>
>>>> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
>>>> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
>>>> javax.transaction & javax.transaction.xa from the system bundle but
>>>> those packages don't offer all of JTA. I've seen this issue noted by
>>>> some folks with Karaf but haven't found a definitive answer, so I
>>>> bring the issue back up to the list. One suggestion was to use
>>>> -split-package on Export-Package but I've not had the best luck with
>>>> making that work. Another suggestion is to not export the noted
>>>> packages from the system bundle.
>>>>
>>>> What should I do to fix this up?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JTA Bundle
Posted by Carl Hall <ca...@gmail.com>.
I've been able to see this load correctly (no errors in the logs as
before) by using split-package. If I go this route, which option
should I use (merge-first, merge-last, first)?
Adding a flag to the import (partial) is not an option for us as JTA
is being imported by bundles that we have no control over.
On Tue, Feb 23, 2010 at 14:58, Guillaume Nodet <gn...@gmail.com> wrote:
> The reason to keep it is that there is a boot delegation for the
> javax.transaction.* packages.
> This is to avoid class cast exception in the javax.sql packages which
> do use the classes from the javax.transaction package exported by the
> system bundle.
> So what happens is that the javax.transaction package from the jre and
> the one exported by the jta bundle will actually get merged (i.e.
> you'll wire on the jta bundle, but you'll use the classes from the jre
> when they are defined).
>
> On Tue, Feb 23, 2010 at 20:48, Clifford H. James <cj...@proteuseng.com> wrote:
>> Karaf adds a mandatory attribute (partial) to the system package export in
>> etc/config.properties:
>>
>> javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \
>>
>> I believe this is so that you'd resolve this version of
>> javax.transaction/transaction.xa IFF the importer
>> specified partial=true on the Import-Package stmt.
>>
>> That way if you have a bundle exporting these packages as well, they don't
>> conflict with the system package because without the mandatory attribute, it
>> won't wire. I suppose you could just have removed it from the systemPackage
>> list as well but I guess this gives the importer the flexible to take the
>> default one if he/she so desires???
>>
>> My experience with split-packages has made me try to avoid it if at all
>> possible.
>>
>> -Cliff James
>>
>> Carl Hall wrote:
>>>
>>> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
>>> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
>>> javax.transaction & javax.transaction.xa from the system bundle but
>>> those packages don't offer all of JTA. I've seen this issue noted by
>>> some folks with Karaf but haven't found a definitive answer, so I
>>> bring the issue back up to the list. One suggestion was to use
>>> -split-package on Export-Package but I've not had the best luck with
>>> making that work. Another suggestion is to not export the noted
>>> packages from the system bundle.
>>>
>>> What should I do to fix this up?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JTA Bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/24/10 3:58 AM, Guillaume Nodet wrote:
> The reason to keep it is that there is a boot delegation for the
> javax.transaction.* packages.
> This is to avoid class cast exception in the javax.sql packages which
> do use the classes from the javax.transaction package exported by the
> system bundle.
> So what happens is that the javax.transaction package from the jre and
> the one exported by the jta bundle will actually get merged (i.e.
> you'll wire on the jta bundle, but you'll use the classes from the jre
> when they are defined).
>
Technically, you do not need to keep javax.transaction.* packages in the
system bundle exports to get this behavior. You can just list them in
boot delegation.
-> richard
> On Tue, Feb 23, 2010 at 20:48, Clifford H. James<cj...@proteuseng.com> wrote:
>
>> Karaf adds a mandatory attribute (partial) to the system package export in
>> etc/config.properties:
>>
>> javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \
>>
>> I believe this is so that you'd resolve this version of
>> javax.transaction/transaction.xa IFF the importer
>> specified partial=true on the Import-Package stmt.
>>
>> That way if you have a bundle exporting these packages as well, they don't
>> conflict with the system package because without the mandatory attribute, it
>> won't wire. I suppose you could just have removed it from the systemPackage
>> list as well but I guess this gives the importer the flexible to take the
>> default one if he/she so desires???
>>
>> My experience with split-packages has made me try to avoid it if at all
>> possible.
>>
>> -Cliff James
>>
>> Carl Hall wrote:
>>
>>> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
>>> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
>>> javax.transaction& javax.transaction.xa from the system bundle but
>>> those packages don't offer all of JTA. I've seen this issue noted by
>>> some folks with Karaf but haven't found a definitive answer, so I
>>> bring the issue back up to the list. One suggestion was to use
>>> -split-package on Export-Package but I've not had the best luck with
>>> making that work. Another suggestion is to not export the noted
>>> packages from the system bundle.
>>>
>>> What should I do to fix this up?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JTA Bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
The reason to keep it is that there is a boot delegation for the
javax.transaction.* packages.
This is to avoid class cast exception in the javax.sql packages which
do use the classes from the javax.transaction package exported by the
system bundle.
So what happens is that the javax.transaction package from the jre and
the one exported by the jta bundle will actually get merged (i.e.
you'll wire on the jta bundle, but you'll use the classes from the jre
when they are defined).
On Tue, Feb 23, 2010 at 20:48, Clifford H. James <cj...@proteuseng.com> wrote:
> Karaf adds a mandatory attribute (partial) to the system package export in
> etc/config.properties:
>
> javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \
>
> I believe this is so that you'd resolve this version of
> javax.transaction/transaction.xa IFF the importer
> specified partial=true on the Import-Package stmt.
>
> That way if you have a bundle exporting these packages as well, they don't
> conflict with the system package because without the mandatory attribute, it
> won't wire. I suppose you could just have removed it from the systemPackage
> list as well but I guess this gives the importer the flexible to take the
> default one if he/she so desires???
>
> My experience with split-packages has made me try to avoid it if at all
> possible.
>
> -Cliff James
>
> Carl Hall wrote:
>>
>> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
>> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
>> javax.transaction & javax.transaction.xa from the system bundle but
>> those packages don't offer all of JTA. I've seen this issue noted by
>> some folks with Karaf but haven't found a definitive answer, so I
>> bring the issue back up to the list. One suggestion was to use
>> -split-package on Export-Package but I've not had the best luck with
>> making that work. Another suggestion is to not export the noted
>> packages from the system bundle.
>>
>> What should I do to fix this up?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JTA Bundle
Posted by "Clifford H. James" <cj...@proteuseng.com>.
Karaf adds a mandatory attribute (partial) to the system package export in
etc/config.properties:
javax.transaction; javax.transaction.xa; partial=true;
mandatory:=partial, \
I believe this is so that you'd resolve this version of
javax.transaction/transaction.xa IFF the importer
specified partial=true on the Import-Package stmt.
That way if you have a bundle exporting these packages as well, they
don't conflict with the system package because without the mandatory
attribute, it won't wire. I suppose you could just have removed it from
the systemPackage list as well but I guess this gives the importer the
flexible to take the default one if he/she so desires???
My experience with split-packages has made me try to avoid it if at all
possible.
-Cliff James
Carl Hall wrote:
> I'm trying to use the Geronimo JTA bundle (geronimo-jta_1.1_spec,
> version 1.1.1) but am hitting a snag. Other bundles seem to pick up
> javax.transaction & javax.transaction.xa from the system bundle but
> those packages don't offer all of JTA. I've seen this issue noted by
> some folks with Karaf but haven't found a definitive answer, so I
> bring the issue back up to the list. One suggestion was to use
> -split-package on Export-Package but I've not had the best luck with
> making that work. Another suggestion is to not export the noted
> packages from the system bundle.
>
> What should I do to fix this up?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org