Re: Bundle restart are hard to tackle

[Timothy Ward]

Hi Charlie,

The problem with:

> [code]
> @Transactional (propagation=REQUIRED)
> private int txGet() {
> return 42;
> }
> [/code]


Is that it requires either proxying or bytecode enhancement to happen, both of 
these techniques impose constraints on bundle startup and/or container choice. 
Neither of these things are very OSGi friendly, particularly if you’re trying 
to get hot-deployment of changes working. Whilst blueprint does offer some 
proxying, that behaviour isn’t available when using most of the other OSGi 
technologies that exist. Transaction Control was created to provide a clean, 
technology independent, mechanism for doing this.

Another problem (not visible in your example, but one of the original reasons 
for this mail chain) is that in a modular system it can be very hard to 
identify which resources (DataSources, EntityManagers etc) will automatically 
enlist in an ongoing transaction. Also it can be incredibly hard to deal with 
these resources changing underneath you. Making mistakes here is very 
dangerous, as it looks like things are working, right up until you actually 
need the transaction! This is another way in which Transaction Control helps, 
by providing a clean, simple way to add/replace resources at runtime.

All in all, I would recommend Transaction Control over other methods, but it’s 
definitely not essential to use it. If you have the right setup then then 
combining the JDBC Service, JTA Service and JPA Service will let you do pretty 
much the same things, just with more moving parts.

> Finally, I want to personally thank you for your book that has a place of 
> choice in my library and brought me an unconditional love and interest for 
> the OSGI technology!


It’s always nice to hear when someone enjoys it, thank you :)

Best Regards,

Tim

> On 31 Jan 2017, at 15:35, Charlie Mordant  wrote:
> 
> Hi Serge (sorry, I forgot to mention you in my last mail), hi Nick,
> 
> Thanks for the tips Nick, I did not thought about putting breakpoints into 
> Felix to see which bundle refresh what, will try it for sure.
> 
> Tim, I personally see the proxy issue with @Transactional as only a 
> technical/implementation issue: as a user, I really can't see the point that 
> using:
> 
> [code]
> 
> private int txGet() {
> txControl.required(() -> {
> return 42;
> }
> }
> [/code]
> 
> is more modularity-friendly than 
> 
> [code]
> @Transactional (propagation=REQUIRED)
> private int txGet() {
> return 42;
> }
> [/code]
> 
> Finally, I want to personally thank you for your book that has a place of 
> choice in my library and brought me an unconditional love and interest for 
> the OSGI technology!
> 
> 
> 
> Best regards to all :),
> 
> 
> 
> 2017-01-31 15:35 GMT+01:00 Timothy Ward  >:
> Hi,
> 
> Just to confirm, Tx Control doesn’t do @Transactional, but it does do JPA 
> without the JPATemplate (i.e. you can just do normal JPA access within a 
> managed block). As for bringing in Java EE guys, that’s great, but at least 
> some of their usage patterns have to change if you want hot-swap and start up 
> order independence to work!
> 
> Regards,
> 
> Tim Ward
> 
> Enterprise OSGi in Action (http://www.manning.com/cummins 
> )
> Apache Aries PMC
> 
> 
>> On 31 Jan 2017, at 10:53, Charlie Mordant > > wrote:
>> 
>> Hi Timothy,
>> 
>> Thank you for all your questions and interest.
>> 
>> Concerning graphql, why not. I had in mind to provide a way to easily bring 
>> HATEOAS (via spring-hateoas, or implementing some cxf interceptors), but 
>> Graphql looks also promising, so why not, it'll be discussed...
>> 
>> About the Aries Tx Control, it is a deliberate choice to not use it (sorry 
>> :-S): the goal of Osgiliath is mainly to bring JavaEE guys into the OSGi 
>> world without disturbing (most of) their habits, giving them modularity, 
>> scalability and hot swap for free.
>> So in an ideal world, every service injection would be done with CDI 
>> annotations (that's why we're using pax-cdi), persistence with JPA 
>> annotations (without blueprint neither JPA template), transaction with 
>> @Transactional ones (without blueprint too), and if we could have web 
>> sessions/security context distributed accross bundles <3.
>> 
>> Of course, life is made of tradeof, so if DS, Tx Control and JpaTemplate are 
>> the only way to go the right way, Osgiliath will too.
>> 
>> Best regards,
>> 
>> 2017-01-31 10:50 GMT+01:00 Timothy Ward > >:
>> Hi Charlie,
>> 
>> One other question, have you tried using Aries Transaction Control? The big 
>> drivers for creating the Transaction Control Service were to simplify the 
>> service model and to handle dynamics better when performing transactional 
>> access to resources. The Aries implementation supports XA and is fully 
>> recoverable, so it 

Re: Bundle restart are hard to tackle

[Charlie Mordant]

Hi Serge (sorry, I forgot to mention you in my last mail), hi Nick,

Thanks for the tips Nick, I did not thought about putting breakpoints into
Felix to see which bundle refresh what, will try it for sure.

Tim, I personally see the proxy issue with @Transactional as only a
technical/implementation issue: as a user, I really can't see the point
that using:

[code]

private int txGet() {

txControl.required(() -> {

return 42;

}

}
[/code]

is more modularity-friendly than

[code]
@Transactional (propagation=REQUIRED)
private int txGet() {
return 42;
}
[/code]

Finally, I want to personally thank you for your book that has a place of
choice in my library and brought me an unconditional love and interest for
the OSGI technology!



Best regards to all :),



2017-01-31 15:35 GMT+01:00 Timothy Ward :

> Hi,
>
> Just to confirm, Tx Control doesn’t do @Transactional, but it does do JPA
> without the JPATemplate (i.e. you can just do normal JPA access within a
> managed block). As for bringing in Java EE guys, that’s great, but at least
> some of their usage patterns have to change if you want hot-swap and start
> up order independence to work!
>
> Regards,
>
> Tim Ward
>
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> Apache Aries PMC
>
>
> On 31 Jan 2017, at 10:53, Charlie Mordant  wrote:
>
> Hi Timothy,
>
> Thank you for all your questions and interest.
>
> Concerning graphql, why not. I had in mind to provide a way to easily
> bring HATEOAS (via spring-hateoas, or implementing some cxf interceptors),
> but Graphql looks also promising, so why not, it'll be discussed...
>
> About the Aries Tx Control, it is a deliberate choice to not use it (sorry
> :-S): the goal of Osgiliath is mainly to bring JavaEE guys into the OSGi
> world without disturbing (most of) their habits, giving them modularity,
> scalability and hot swap for free.
> So in an ideal world, every service injection would be done with CDI
> annotations (that's why we're using pax-cdi), persistence with JPA
> annotations (without blueprint neither JPA template), transaction with
> @Transactional ones (without blueprint too), and if we could have web
> sessions/security context distributed accross bundles <3.
>
> Of course, life is made of tradeof, so if DS, Tx Control and JpaTemplate
> are the only way to go the right way, Osgiliath will too.
>
> Best regards,
>
> 2017-01-31 10:50 GMT+01:00 Timothy Ward :
>
>> Hi Charlie,
>>
>> One other question, have you tried using Aries Transaction Control? The
>> big drivers for creating the Transaction Control Service were to simplify
>> the service model and to handle dynamics better when performing
>> transactional access to resources. The Aries implementation supports XA and
>> is fully recoverable, so it should be very simple to use in your project.
>>
>> Regards,
>>
>> Tim
>>
>> On 31 Jan 2017, at 09:48, Charlie Mordant  wrote:
>>
>> Hi J.B.,
>>
>> Sure, it's always reproducible, I'll send it tonight (or tomorrow if I
>> haven't the time to do it).
>> I'm not in front of my computer for now, but will do my best as reactive
>> as possible.
>>
>> Best Regards,
>>
>> 2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré :
>>
>>> Hi Charlie,
>>>
>>> do you have the feature:install -v output ? It would help us to see the
>>> cause of the refresh (optional import, or other).
>>>
>>> Thanks !
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 01/31/2017 10:39 AM, Charlie Mordant wrote:
>>>
 Hi users of the world's best application server ever ;-),

 I'm struggling with feature resolution, and would like to have your POV.

 This issue is concerning, the JDBC, the Blueprint and the transactional
 feature.

 Here's the issue with feature resolution in my pax-exam test:


 * The jdbc-pool-aries feature starts first (+ the config one and the cfg
 \o/).
 * Then the transactional feature
 * The third feature thats start is the aries jndi one, so the two
 datasources (the XA and non-XA ones) are exposed (\o/\o/).
 * But the third that starts is the blueprint one, which starts the
 xbean-blueprint bundle.
 That blueprint bundle restarts the 'optional' resolutions of aries
 transaction manager, which then restarts aries-jdbc modules (optional
 res again) & config, which stops the datasource and starts another one.
 ​Unfortunately, at this point, my 'daos' bundle is already linked with a
 proxy to the 'old' datasource​.

 A way to fix it is to reference the 'transaction' feature in the
 'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
 it would then break some modularity.

 Have you got an idea on how to properly handle it?

 The actual xml of my features, they're slightly similar to the karaf
 ones, with bundle versions aligned:
 [code]

  >>> 

Re: Bundle restart are hard to tackle

[Timothy Ward]

Hi,

Just to confirm, Tx Control doesn’t do @Transactional, but it does do JPA 
without the JPATemplate (i.e. you can just do normal JPA access within a 
managed block). As for bringing in Java EE guys, that’s great, but at least 
some of their usage patterns have to change if you want hot-swap and start up 
order independence to work!

Regards,

Tim Ward

Enterprise OSGi in Action (http://www.manning.com/cummins 
)
Apache Aries PMC


> On 31 Jan 2017, at 10:53, Charlie Mordant  wrote:
> 
> Hi Timothy,
> 
> Thank you for all your questions and interest.
> 
> Concerning graphql, why not. I had in mind to provide a way to easily bring 
> HATEOAS (via spring-hateoas, or implementing some cxf interceptors), but 
> Graphql looks also promising, so why not, it'll be discussed...
> 
> About the Aries Tx Control, it is a deliberate choice to not use it (sorry 
> :-S): the goal of Osgiliath is mainly to bring JavaEE guys into the OSGi 
> world without disturbing (most of) their habits, giving them modularity, 
> scalability and hot swap for free.
> So in an ideal world, every service injection would be done with CDI 
> annotations (that's why we're using pax-cdi), persistence with JPA 
> annotations (without blueprint neither JPA template), transaction with 
> @Transactional ones (without blueprint too), and if we could have web 
> sessions/security context distributed accross bundles <3.
> 
> Of course, life is made of tradeof, so if DS, Tx Control and JpaTemplate are 
> the only way to go the right way, Osgiliath will too.
> 
> Best regards,
> 
> 2017-01-31 10:50 GMT+01:00 Timothy Ward  >:
> Hi Charlie,
> 
> One other question, have you tried using Aries Transaction Control? The big 
> drivers for creating the Transaction Control Service were to simplify the 
> service model and to handle dynamics better when performing transactional 
> access to resources. The Aries implementation supports XA and is fully 
> recoverable, so it should be very simple to use in your project.
> 
> Regards,
> 
> Tim
> 
>> On 31 Jan 2017, at 09:48, Charlie Mordant > > wrote:
>> 
>> Hi J.B.,
>> 
>> Sure, it's always reproducible, I'll send it tonight (or tomorrow if I 
>> haven't the time to do it).
>> I'm not in front of my computer for now, but will do my best as reactive as 
>> possible.
>> 
>> Best Regards,
>> 
>> 2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré > >:
>> Hi Charlie,
>> 
>> do you have the feature:install -v output ? It would help us to see the 
>> cause of the refresh (optional import, or other).
>> 
>> Thanks !
>> 
>> Regards
>> JB
>> 
>> 
>> On 01/31/2017 10:39 AM, Charlie Mordant wrote:
>> Hi users of the world's best application server ever ;-),
>> 
>> I'm struggling with feature resolution, and would like to have your POV.
>> 
>> This issue is concerning, the JDBC, the Blueprint and the transactional
>> feature.
>> 
>> Here's the issue with feature resolution in my pax-exam test:
>> 
>> 
>> * The jdbc-pool-aries feature starts first (+ the config one and the cfg
>> \o/).
>> * Then the transactional feature
>> * The third feature thats start is the aries jndi one, so the two
>> datasources (the XA and non-XA ones) are exposed (\o/\o/).
>> * But the third that starts is the blueprint one, which starts the
>> xbean-blueprint bundle.
>> That blueprint bundle restarts the 'optional' resolutions of aries
>> transaction manager, which then restarts aries-jdbc modules (optional
>> res again) & config, which stops the datasource and starts another one.
>> ​Unfortunately, at this point, my 'daos' bundle is already linked with a
>> proxy to the 'old' datasource​.
>> 
>> A way to fix it is to reference the 'transaction' feature in the
>> 'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
>> it would then break some modularity.
>> 
>> Have you got an idea on how to properly handle it?
>> 
>> The actual xml of my features, they're slightly similar to the karaf
>> ones, with bundle versions aligned:
>> [code]
>> 
>>  > version="${org.ops4j.pax.jdbc_pax-jdbc-features.version}" resolver="(obr)">
>> osgiliath-pax-jdbc-spec
>> 
>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.ops4j.pax.jdbc_pax-jdbc-pool-common.version}
>> 
>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops4j.pax.jdbc_pax-jdbc-pool-aries.version}
>> 
>> osgiliath-aries-blueprint
>> > dependency="true">mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}
>> 
>> 
>> osgiliath-transaction
>> > dependency="true">mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/${org.apache.aries.transaction_org.apache.aries.transaction.jdbc.version}
>> 
>> 
>> 
>> 
>> 

Re: Bundle restart are hard to tackle

[Nick Baker]

I do agree that Felix can be very opaque when restarts occur. We usually end up 
sprinkling breakpoints around or attaching BTrace to log framework internals. 
refreshOptionalPackages() is often the cause. Some better logging about the 
trigger and cause of the refresh would be great. I know that we lose visibility 
to the root trigger as the events propagate across different threads, but 
someone ambitious/crafty should be able to handle it.


-Nick Baker


From: Charlie Mordant 
Sent: Tuesday, January 31, 2017 4:39:32 AM
To: user@karaf.apache.org
Subject: Bundle restart are hard to tackle

Hi users of the world's best application server ever ;-),

I'm struggling with feature resolution, and would like to have your POV.

This issue is concerning, the JDBC, the Blueprint and the transactional feature.

Here's the issue with feature resolution in my pax-exam test:


* The jdbc-pool-aries feature starts first (+ the config one and the cfg \o/).
* Then the transactional feature
* The third feature thats start is the aries jndi one, so the two datasources 
(the XA and non-XA ones) are exposed (\o/\o/).
* But the third that starts is the blueprint one, which starts the 
xbean-blueprint bundle.
That blueprint bundle restarts the 'optional' resolutions of aries transaction 
manager, which then restarts aries-jdbc modules (optional res again) & config, 
which stops the datasource and starts another one.
​Unfortunately, at this point, my 'daos' bundle is already linked with a proxy 
to the 'old' datasource​.

A way to fix it is to reference the 'transaction' feature in the 'pool-aries' 
one, and the 'blueprint' one in the 'transaction' one, but it would then break 
some modularity.

Have you got an idea on how to properly handle it?

The actual xml of my features, they're slightly similar to the karaf ones, with 
bundle versions aligned:
[code]

 
osgiliath-pax-jdbc-spec

mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.ops4j.pax.jdbc_pax-jdbc-pool-common.version}

mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops4j.pax.jdbc_pax-jdbc-pool-aries.version}

osgiliath-aries-blueprint
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-transaction
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/${org.apache.aries.transaction_org.apache.aries.transaction.jdbc.version}






aries.transaction.recoverable = true
aries.transaction.timeout = 600
aries.transaction.howl.logFileDir = ${karaf.data}/txlog
aries.transaction.howl.maxLogFiles = 2
aries.transaction.howl.maxBlocksPerFile = 512
aries.transaction.howl.bufferSize = 4

osgiliath-transaction-api
mvn:org.apache.aries/org.apache.aries.util/${org.apache.aries_org.apache.aries.util.version}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/${org.apache.aries.transaction_org.apache.aries.transaction.manager.version}

osgiliath-aries-blueprint
mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version1}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version}
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-spring
osgiliath-spring-tx




* Additional 
informations **


mvn:javax.interceptor/javax.interceptor-api/${javax.interceptor_javax.interceptor-api.version}
mvn:org.apache.geronimo.specs/geronimo-atinject_1.0_spec/${org.apache.geronimo.specs_geronimo-atinject_1.0_spec.version}
mvn:javax.el/javax.el-api/${javax.el_javax.el-api.version}
mvn:javax.enterprise/cdi-api/${javax.enterprise_cdi-api.version}

mvn:javax.transaction/javax.transaction-api/${javax.transaction_javax.transaction-api.version}

 

mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/${org.apache.geronimo.specs_geronimo-jpa_2.0_spec.version}

mvn:org.apache.geronimo.specs/geronimo-osgi-registry/${org.apache.geronimo.specs_geronimo-osgi-registry.version}

 
osgiliath-transaction-api
osgiliath-persistence-api
mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}
mvn:org.osgi/org.osgi.service.jdbc/${org.osgi_org.osgi.service.jdbc.version}

Re: Bundle restart are hard to tackle

[Charlie Mordant]

Hi Timothy,

Thank you for all your questions and interest.

Concerning graphql, why not. I had in mind to provide a way to easily bring
HATEOAS (via spring-hateoas, or implementing some cxf interceptors), but
Graphql looks also promising, so why not, it'll be discussed...

About the Aries Tx Control, it is a deliberate choice to not use it (sorry
:-S): the goal of Osgiliath is mainly to bring JavaEE guys into the OSGi
world without disturbing (most of) their habits, giving them modularity,
scalability and hot swap for free.
So in an ideal world, every service injection would be done with CDI
annotations (that's why we're using pax-cdi), persistence with JPA
annotations (without blueprint neither JPA template), transaction with
@Transactional ones (without blueprint too), and if we could have web
sessions/security context distributed accross bundles <3.

Of course, life is made of tradeof, so if DS, Tx Control and JpaTemplate
are the only way to go the right way, Osgiliath will too.

Best regards,

2017-01-31 10:50 GMT+01:00 Timothy Ward :

> Hi Charlie,
>
> One other question, have you tried using Aries Transaction Control? The
> big drivers for creating the Transaction Control Service were to simplify
> the service model and to handle dynamics better when performing
> transactional access to resources. The Aries implementation supports XA and
> is fully recoverable, so it should be very simple to use in your project.
>
> Regards,
>
> Tim
>
> On 31 Jan 2017, at 09:48, Charlie Mordant  wrote:
>
> Hi J.B.,
>
> Sure, it's always reproducible, I'll send it tonight (or tomorrow if I
> haven't the time to do it).
> I'm not in front of my computer for now, but will do my best as reactive
> as possible.
>
> Best Regards,
>
> 2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré :
>
>> Hi Charlie,
>>
>> do you have the feature:install -v output ? It would help us to see the
>> cause of the refresh (optional import, or other).
>>
>> Thanks !
>>
>> Regards
>> JB
>>
>>
>> On 01/31/2017 10:39 AM, Charlie Mordant wrote:
>>
>>> Hi users of the world's best application server ever ;-),
>>>
>>> I'm struggling with feature resolution, and would like to have your POV.
>>>
>>> This issue is concerning, the JDBC, the Blueprint and the transactional
>>> feature.
>>>
>>> Here's the issue with feature resolution in my pax-exam test:
>>>
>>>
>>> * The jdbc-pool-aries feature starts first (+ the config one and the cfg
>>> \o/).
>>> * Then the transactional feature
>>> * The third feature thats start is the aries jndi one, so the two
>>> datasources (the XA and non-XA ones) are exposed (\o/\o/).
>>> * But the third that starts is the blueprint one, which starts the
>>> xbean-blueprint bundle.
>>> That blueprint bundle restarts the 'optional' resolutions of aries
>>> transaction manager, which then restarts aries-jdbc modules (optional
>>> res again) & config, which stops the datasource and starts another one.
>>> ​Unfortunately, at this point, my 'daos' bundle is already linked with a
>>> proxy to the 'old' datasource​.
>>>
>>> A way to fix it is to reference the 'transaction' feature in the
>>> 'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
>>> it would then break some modularity.
>>>
>>> Have you got an idea on how to properly handle it?
>>>
>>> The actual xml of my features, they're slightly similar to the karaf
>>> ones, with bundle versions aligned:
>>> [code]
>>>
>>>  >> description="Provides JDBC Pooling DataSourceFactory using Aries
>>> Transaction JDBC" version="${org.ops4j.pax.jdbc_pax-jdbc-features.version}"
>>> resolver="(obr)">
>>> osgiliath-pax-jdbc-spec
>>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.op
>>> s4j.pax.jdbc_pax-jdbc-pool-common.version}
>>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops
>>> 4j.pax.jdbc_pax-jdbc-pool-aries.version}
>>> 
>>> osgiliath-aries-blueprint
>>> mvn:org.apac
>>> he.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.
>>> version}
>>> 
>>> 
>>> osgiliath-transaction
>>> mvn:org.apac
>>> he.aries.transaction/org.apache.aries.transaction.jdbc/${org
>>> .apache.aries.transaction_org.apache.aries.transaction.jdbc.
>>> version}
>>> 
>>> 
>>>
>>>
>>> 
>>> 
>>> aries.transaction.recoverable = true
>>> aries.transaction.timeout = 600
>>> aries.transaction.howl.logFileDir = ${karaf.data}/txlog
>>> aries.transaction.howl.maxLogFiles = 2
>>> aries.transaction.howl.maxBlocksPerFile = 512
>>> aries.transaction.howl.bufferSize = 4
>>> 
>>> >> prerequisite="false" dependency="false">osgiliath-t
>>> ransaction-api
>>> mvn:org.apac
>>> he.aries/org.apache.aries.util/${org.apache.aries_org.apache
>>> .aries.util.version}
>>> mvn:org.apache.aries.transaction/org.apache.aries.tr

Re: Bundle restart are hard to tackle

[Timothy Ward]

Hi Charlie,

One other question, have you tried using Aries Transaction Control? The big 
drivers for creating the Transaction Control Service were to simplify the 
service model and to handle dynamics better when performing transactional 
access to resources. The Aries implementation supports XA and is fully 
recoverable, so it should be very simple to use in your project.

Regards,

Tim

> On 31 Jan 2017, at 09:48, Charlie Mordant  wrote:
> 
> Hi J.B.,
> 
> Sure, it's always reproducible, I'll send it tonight (or tomorrow if I 
> haven't the time to do it).
> I'm not in front of my computer for now, but will do my best as reactive as 
> possible.
> 
> Best Regards,
> 
> 2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré  >:
> Hi Charlie,
> 
> do you have the feature:install -v output ? It would help us to see the cause 
> of the refresh (optional import, or other).
> 
> Thanks !
> 
> Regards
> JB
> 
> 
> On 01/31/2017 10:39 AM, Charlie Mordant wrote:
> Hi users of the world's best application server ever ;-),
> 
> I'm struggling with feature resolution, and would like to have your POV.
> 
> This issue is concerning, the JDBC, the Blueprint and the transactional
> feature.
> 
> Here's the issue with feature resolution in my pax-exam test:
> 
> 
> * The jdbc-pool-aries feature starts first (+ the config one and the cfg
> \o/).
> * Then the transactional feature
> * The third feature thats start is the aries jndi one, so the two
> datasources (the XA and non-XA ones) are exposed (\o/\o/).
> * But the third that starts is the blueprint one, which starts the
> xbean-blueprint bundle.
> That blueprint bundle restarts the 'optional' resolutions of aries
> transaction manager, which then restarts aries-jdbc modules (optional
> res again) & config, which stops the datasource and starts another one.
> ​Unfortunately, at this point, my 'daos' bundle is already linked with a
> proxy to the 'old' datasource​.
> 
> A way to fix it is to reference the 'transaction' feature in the
> 'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
> it would then break some modularity.
> 
> Have you got an idea on how to properly handle it?
> 
> The actual xml of my features, they're slightly similar to the karaf
> ones, with bundle versions aligned:
> [code]
> 
>   version="${org.ops4j.pax.jdbc_pax-jdbc-features.version}" resolver="(obr)">
> osgiliath-pax-jdbc-spec
> 
> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.ops4j.pax.jdbc_pax-jdbc-pool-common.version}
> 
> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops4j.pax.jdbc_pax-jdbc-pool-aries.version}
> 
> osgiliath-aries-blueprint
>  dependency="true">mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}
> 
> 
> osgiliath-transaction
>  dependency="true">mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/${org.apache.aries.transaction_org.apache.aries.transaction.jdbc.version}
> 
> 
> 
> 
> http://org.apache.aries.tr/>ansaction_org.apache.aries.transaction.manager.version}">
> 
> aries.transaction.recoverable = true
> aries.transaction.timeout = 600
> aries.transaction.howl.logFileDir = ${karaf.data}/txlog
> aries.transaction.howl.maxLogFiles = 2
> aries.transaction.howl.maxBlocksPerFile = 512
> aries.transaction.howl.bufferSize = 4
> 
>  prerequisite="false" dependency="false">osgiliath-transaction-api
>  dependency="true">mvn:org.apache.aries/org.apache.aries.util/${org.apache.aries_org.apache.aries.util.version}
> mvn:org.apache.aries.transaction/org.apache.aries.tr 
> ansaction.manager/${org.apache.aries.transaction_org.apache.aries.transaction.manager.version}
> 
> osgiliath-aries-blueprint
>  dependency="true">mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}
> mvn:org.apache.aries.transaction/org.apache.aries.tr 
> ansaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version1}
> mvn:org.apache.aries.transaction/org.apache.aries.tr 
> ansaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version}
>  dependency="true">mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}
> 
> 
> osgiliath-spring
>  version="${org.apache.servicemix.bundles.spring.version}" 
> dependency="true">osgiliath-spring-tx
> 
> 
> 
> * Additional 
> informations **
> 
> 
>  

Re: Bundle restart are hard to tackle

[Jean-Baptiste Onofré]

Awesome !

In the mean time, I try to reproduce on my side.

Thanks !

Regards
JB

On 01/31/2017 10:48 AM, Charlie Mordant wrote:

Hi J.B.,

Sure, it's always reproducible, I'll send it tonight (or tomorrow if I
haven't the time to do it).
I'm not in front of my computer for now, but will do my best as reactive
as possible.

Best Regards,

2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré >:

Hi Charlie,

do you have the feature:install -v output ? It would help us to see
the cause of the refresh (optional import, or other).

Thanks !

Regards
JB


On 01/31/2017 10:39 AM, Charlie Mordant wrote:

Hi users of the world's best application server ever ;-),

I'm struggling with feature resolution, and would like to have
your POV.

This issue is concerning, the JDBC, the Blueprint and the
transactional
feature.

Here's the issue with feature resolution in my pax-exam test:


* The jdbc-pool-aries feature starts first (+ the config one and
the cfg
\o/).
* Then the transactional feature
* The third feature thats start is the aries jndi one, so the two
datasources (the XA and non-XA ones) are exposed (\o/\o/).
* But the third that starts is the blueprint one, which starts the
xbean-blueprint bundle.
That blueprint bundle restarts the 'optional' resolutions of aries
transaction manager, which then restarts aries-jdbc modules
(optional
res again) & config, which stops the datasource and starts
another one.
​Unfortunately, at this point, my 'daos' bundle is already
linked with a
proxy to the 'old' datasource​.

A way to fix it is to reference the 'transaction' feature in the
'pool-aries' one, and the 'blueprint' one in the 'transaction'
one, but
it would then break some modularity.

Have you got an idea on how to properly handle it?

The actual xml of my features, they're slightly similar to the karaf
ones, with bundle versions aligned:
[code]

 
osgiliath-pax-jdbc-spec


mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.ops4j.pax.jdbc_pax-jdbc-pool-common.version}


mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops4j.pax.jdbc_pax-jdbc-pool-aries.version}

osgiliath-aries-blueprint
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-transaction
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/${org.apache.aries.transaction_org.apache.aries.transaction.jdbc.version}




http://org.apache.aries.tr>ansaction_org.apache.aries.transaction.manager.version}">

aries.transaction.recoverable = true
aries.transaction.timeout = 600
aries.transaction.howl.logFileDir = ${karaf.data}/txlog
aries.transaction.howl.maxLogFiles = 2
aries.transaction.howl.maxBlocksPerFile = 512
aries.transaction.howl.bufferSize = 4

osgiliath-transaction-api
mvn:org.apache.aries/org.apache.aries.util/${org.apache.aries_org.apache.aries.util.version}

mvn:org.apache.aries.transaction/org.apache.aries.tr

ansaction.manager/${org.apache.aries.transaction_org.apache.aries.transaction.manager.version}

osgiliath-aries-blueprint
mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}

mvn:org.apache.aries.transaction/org.apache.aries.tr

ansaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version1}

mvn:org.apache.aries.transaction/org.apache.aries.tr

ansaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version}
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-spring
osgiliath-spring-tx



*
Additional informations **



mvn:javax.in

terceptor/javax.interceptor-api/${javax.interceptor_javax.in
terceptor-api.version}

Re: Bundle restart are hard to tackle

[Charlie Mordant]

Hi J.B.,

Sure, it's always reproducible, I'll send it tonight (or tomorrow if I
haven't the time to do it).
I'm not in front of my computer for now, but will do my best as reactive as
possible.

Best Regards,

2017-01-31 10:41 GMT+01:00 Jean-Baptiste Onofré :

> Hi Charlie,
>
> do you have the feature:install -v output ? It would help us to see the
> cause of the refresh (optional import, or other).
>
> Thanks !
>
> Regards
> JB
>
>
> On 01/31/2017 10:39 AM, Charlie Mordant wrote:
>
>> Hi users of the world's best application server ever ;-),
>>
>> I'm struggling with feature resolution, and would like to have your POV.
>>
>> This issue is concerning, the JDBC, the Blueprint and the transactional
>> feature.
>>
>> Here's the issue with feature resolution in my pax-exam test:
>>
>>
>> * The jdbc-pool-aries feature starts first (+ the config one and the cfg
>> \o/).
>> * Then the transactional feature
>> * The third feature thats start is the aries jndi one, so the two
>> datasources (the XA and non-XA ones) are exposed (\o/\o/).
>> * But the third that starts is the blueprint one, which starts the
>> xbean-blueprint bundle.
>> That blueprint bundle restarts the 'optional' resolutions of aries
>> transaction manager, which then restarts aries-jdbc modules (optional
>> res again) & config, which stops the datasource and starts another one.
>> ​Unfortunately, at this point, my 'daos' bundle is already linked with a
>> proxy to the 'old' datasource​.
>>
>> A way to fix it is to reference the 'transaction' feature in the
>> 'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
>> it would then break some modularity.
>>
>> Have you got an idea on how to properly handle it?
>>
>> The actual xml of my features, they're slightly similar to the karaf
>> ones, with bundle versions aligned:
>> [code]
>>
>>  > version="${org.ops4j.pax.jdbc_pax-jdbc-features.version}"
>> resolver="(obr)">
>> osgiliath-pax-jdbc-spec
>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.
>> ops4j.pax.jdbc_pax-jdbc-pool-common.version}
>> mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.
>> ops4j.pax.jdbc_pax-jdbc-pool-aries.version}
>> 
>> osgiliath-aries-blueprint
>> mvn:org.apac
>> he.xbean/xbean-blueprint/${org.apache.xbean_xbean-bluepri
>> nt.version}
>> 
>> 
>> osgiliath-transaction
>> mvn:org.apac
>> he.aries.transaction/org.apache.aries.transaction.jdbc/${
>> org.apache.aries.transaction_org.apache.aries.transaction.
>> jdbc.version}
>> 
>> 
>>
>>
>> 
>> 
>> aries.transaction.recoverable = true
>> aries.transaction.timeout = 600
>> aries.transaction.howl.logFileDir = ${karaf.data}/txlog
>> aries.transaction.howl.maxLogFiles = 2
>> aries.transaction.howl.maxBlocksPerFile = 512
>> aries.transaction.howl.bufferSize = 4
>> 
>> > prerequisite="false" dependency="false">osgiliath-t
>> ransaction-api
>> mvn:org.apac
>> he.aries/org.apache.aries.util/${org.apache.aries_org.apache
>> .aries.util.version}
>> mvn:org.apache.aries.transaction/org.apache.aries.tr
>> ansaction.manager/${org.apache.aries.transaction_org.apache.
>> aries.transaction.manager.version}
>> 
>> osgiliath-aries-blueprint
>> mvn:org.apac
>> he.felix/org.apache.felix.coordinator/${org.apache.felix_
>> org.apache.felix.coordinator.version}
>> mvn:org.apache.aries.transaction/org.apache.aries.tr
>> ansaction.blueprint/${org.apache.aries.transaction_org.apach
>> e.aries.transaction.blueprint.version1}
>> mvn:org.apache.aries.transaction/org.apache.aries.tr
>> ansaction.blueprint/${org.apache.aries.transaction_org.apach
>> e.aries.transaction.blueprint.version}
>> mvn:org.apac
>> he.xbean/xbean-blueprint/${org.apache.xbean_xbean-bluepri
>> nt.version}
>> 
>> 
>> osgiliath-spring
>> > version="${org.apache.servicemix.bundles.spring.version}"
>> dependency="true">osgiliath-spring-tx
>> 
>> 
>>
>> * Additional
>> informations **
>>
>>
>> 
>> mvn:javax.in
>> terceptor/javax.interceptor-api/${javax.interceptor_javax.in
>> terceptor-api.version}
>> mvn:org.apache.geronimo.specs/geronimo-
>> atinject_1.0_spec/${org.apache.geronimo.specs_geronimo
>> -atinject_1.0_spec.version}
>> mvn:javax.el
>> /javax.el-api/${javax.el_javax.el-api.version}
>> mvn:javax.en
>> terprise/cdi-api/${javax.enterprise_cdi-api.version}
>> mvn:javax.transaction/javax.transaction-api/${javax.
>> transaction_javax.transaction-api.version}
>> 
>>  > version="${persistence-api_feature.version}">
>> mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/
>> 

Re: Bundle restart are hard to tackle

[Serge Huber]

Sorry I can’t really help much about this topic but just wanted to react to one 
thing :


> On 31 Jan 2017, at 10:39, Charlie Mordant  wrote:
> 
> Hi users of the world's best application server ever ;-),

fully agree here ! Karaf is a (hidden) gem of the Apache community, it needs a 
lot more exposure.

> 
> ​Best regards,​ and keep up bringing the OSGI dream comes true ;-)
> 
> 
> -- 
> Charlie Mordant
> 
> Full OSGI/EE stack made with Karaf: 
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent 
> 

A little off-topic I just looked at your project and was wondering if you were 
considering adding GraphQL to it ? 

cheers,
  Serge… 

Re: Bundle restart are hard to tackle

[Jean-Baptiste Onofré]

Hi Charlie,

do you have the feature:install -v output ? It would help us to see the 
cause of the refresh (optional import, or other).


Thanks !

Regards
JB

On 01/31/2017 10:39 AM, Charlie Mordant wrote:

Hi users of the world's best application server ever ;-),

I'm struggling with feature resolution, and would like to have your POV.

This issue is concerning, the JDBC, the Blueprint and the transactional
feature.

Here's the issue with feature resolution in my pax-exam test:


* The jdbc-pool-aries feature starts first (+ the config one and the cfg
\o/).
* Then the transactional feature
* The third feature thats start is the aries jndi one, so the two
datasources (the XA and non-XA ones) are exposed (\o/\o/).
* But the third that starts is the blueprint one, which starts the
xbean-blueprint bundle.
That blueprint bundle restarts the 'optional' resolutions of aries
transaction manager, which then restarts aries-jdbc modules (optional
res again) & config, which stops the datasource and starts another one.
​Unfortunately, at this point, my 'daos' bundle is already linked with a
proxy to the 'old' datasource​.

A way to fix it is to reference the 'transaction' feature in the
'pool-aries' one, and the 'blueprint' one in the 'transaction' one, but
it would then break some modularity.

Have you got an idea on how to properly handle it?

The actual xml of my features, they're slightly similar to the karaf
ones, with bundle versions aligned:
[code]

 
osgiliath-pax-jdbc-spec

mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${org.ops4j.pax.jdbc_pax-jdbc-pool-common.version}

mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${org.ops4j.pax.jdbc_pax-jdbc-pool-aries.version}

osgiliath-aries-blueprint
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-transaction
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/${org.apache.aries.transaction_org.apache.aries.transaction.jdbc.version}






aries.transaction.recoverable = true
aries.transaction.timeout = 600
aries.transaction.howl.logFileDir = ${karaf.data}/txlog
aries.transaction.howl.maxLogFiles = 2
aries.transaction.howl.maxBlocksPerFile = 512
aries.transaction.howl.bufferSize = 4

osgiliath-transaction-api
mvn:org.apache.aries/org.apache.aries.util/${org.apache.aries_org.apache.aries.util.version}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/${org.apache.aries.transaction_org.apache.aries.transaction.manager.version}

osgiliath-aries-blueprint
mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version1}

mvn:org.apache.aries.transaction/org.apache.aries.transaction.blueprint/${org.apache.aries.transaction_org.apache.aries.transaction.blueprint.version}
mvn:org.apache.xbean/xbean-blueprint/${org.apache.xbean_xbean-blueprint.version}


osgiliath-spring
osgiliath-spring-tx



* Additional 
informations **



mvn:javax.interceptor/javax.interceptor-api/${javax.interceptor_javax.interceptor-api.version}
mvn:org.apache.geronimo.specs/geronimo-atinject_1.0_spec/${org.apache.geronimo.specs_geronimo-atinject_1.0_spec.version}
mvn:javax.el/javax.el-api/${javax.el_javax.el-api.version}
mvn:javax.enterprise/cdi-api/${javax.enterprise_cdi-api.version}

mvn:javax.transaction/javax.transaction-api/${javax.transaction_javax.transaction-api.version}

 

mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/${org.apache.geronimo.specs_geronimo-jpa_2.0_spec.version}

mvn:org.apache.geronimo.specs/geronimo-osgi-registry/${org.apache.geronimo.specs_geronimo-osgi-registry.version}

 
osgiliath-transaction-api
osgiliath-persistence-api
mvn:org.apache.felix/org.apache.felix.coordinator/${org.apache.felix_org.apache.felix.coordinator.version}
mvn:org.osgi/org.osgi.service.jdbc/${org.osgi_org.osgi.service.jdbc.version}

mvn:org.apache.aries.jpa/org.apache.aries.jpa.api/${org.apache.aries.jpa_org.apache.aries.jpa.api.version}

mvn:org.apache.aries.jpa/org.apache.aries.jpa.container/${org.apache.aries.jpa_org.apache.aries.jpa.container.version}

mvn:org.apache.aries.jpa/org.apache.aries.jpa.support/${org.apache.aries.jpa_org.apache.aries.jpa.support.version}

osgiliath-aries-blueprint