Antw: Using maven bundle plugin to compile and bundle code not in src/main/java

[alexander.sahler]

Hello Tom.

It's nothing to do with the bundle plugin at all.
All you have to do is to set the sourceDirectory tag in the pom file (as 
subnode of build node).
Please have a look here: 
https://maven.apache.org/guides/mini/guide-using-one-source-directory.html

Pax-JDBC 1.1 hikari pool and XA Support

[alexander.sahler]

When using pax-jdbc 1.1.0 (on karaf 4.0.8) to be able to use hikari pool 
support everything is working fine until I switch on XA support.
In this case the DataSource is not created! When I comment out the XA support 
from the datasource factory config file, the DataSource pops up again.

I have transaction service 2.1.0 deployed (tried with 1.1.1 as well):
list | grep Trans
164 | Active   |  80 | 2.1.0  | Apache Aries Transaction 
Blueprint
165 | Active   |  80 | 1.3.1  | Apache Aries Transaction 
Manager

My configuration file:
osgi.jdbc.driver.name = mariadb
dataSourceName = whatever
databaseName = whatever
user = xxx
password = xxx
pool = hikari
# xa = true
hikari.maximumPoolSize = 200
hikari.connectionTimeout = 400
url = 
jdbc:mariadb:failover://1.2.3.4/bam?characterEncoding=UTF-8&useServerPrepStmts=true

service:list DataSource
[javax.sql.DataSource]
--
 databaseName = whatever
 dataSourceName = whatever
 felix.fileinstall.filename = file:/opt/
 hikari.connectionTimeout = 400
 hikari.maximumPoolSize = 200
 osgi.jdbc.driver.name = mariadb
 osgi.jndi.service.name = whatever
 password = xxx
 service.bundleid = 126
 service.factoryPid = org.ops4j.datasource
 service.id = 391
 service.pid = org.ops4j.datasource.f349f611-9c2e-48a7-8ac0-3789a8f5dd66
 service.scope = singleton
 url = 
jdbc:mariadb:failover://172.17.42.50:3309/whatever?characterEncoding=UTF-8&useServerPrepStmts=true
 user = xxx
Provided by :
 OPS4J Pax JDBC Config (126)

Antw: Re: Pax-JDBC 1.1 hikari pool and XA Support

[alexander.sahler]

I thought I was using Aries Transaction Manager still? 
Does it mean, that hikari pooling does not support XA?
When I use aries pooling, it complains about "Unable to recover XADataSource: 
aries.xa.name property not set". I tried to set it in the pax-jdbc datasource 
file but it doesn't seem to make use of it.

Alexander


>>> 
Another option would be to look at Apache Aries Transaction control. That 
provides a simple, effective model for connection pooling, resource lifecycle 
management, and transaction enlistment. It will also be the reference 
implementation of the OSGi Transaction Control specification when OSGi R7 goes 
final.

Tim

Sent from my iPhone

On 10 Jul 2017, at 16:18, Guillaume Nodet  wrote:



I don't recommand using non XA specific pooling mechanism for JDBC support, 
unless you don't care about the ability to recover in-flight transactions 
(which doesn't play well with wanting XA).
If you're using the geronimo/aries transaction manager, you may want to use the 
pax-jdbc-pool-aries instead which will support recovery.

Guillaume

2017-07-10 17:03 GMT+02:00 sahlex :


Hello.

When using pax-jdbc 1.1.0 (on karaf 4.0.8) to be able to use hikari pool 
support everything is working fine until I switch on XA support.
In this case the DataSource is not created! When I comment out the XA support 
from the datasource factory config file, the DataSource pops up again.

I have transaction service 2.1.0 deployed (tried with 1.1.1 as well):
list | grep Trans
164 | Active | 80 | 2.1.0 | Apache Aries Transaction Blueprint
165 | Active | 80 | 1.3.1 | Apache Aries Transaction Manager

My configuration file:
osgi.jdbc.driver.name = mariadb
dataSourceName = whatever
databaseName = whatever
user = xxx
password = xxx
pool = hikari
# xa = true
hikari.maximumPoolSize = 200
hikari.connectionTimeout = 400
url = 
jdbc:mariadb:failover://1.2.3.4/bam?characterEncoding=UTF-8&useServerPrepStmts=true

service:list DataSource
[javax.sql.DataSource]
--
databaseName = whatever
dataSourceName = whatever
felix.fileinstall.filename = file:/opt/
hikari.connectionTimeout = 400
hikari.maximumPoolSize = 200
osgi.jdbc.driver.name = mariadb
osgi.jndi.service.name = whatever
password = xxx
service.bundleid = 126
service.factoryPid = org.ops4j.datasource
service.id = 391
service.pid = org.ops4j.datasource.f349f611-9c2e-48a7-8ac0-3789a8f5dd66
service.scope = singleton
url = 
jdbc:mariadb:failover://172.17.42.50:3309/whatever?characterEncoding=UTF-8&useServerPrepStmts=true
user = xxx
Provided by :
OPS4J Pax JDBC Config (126)

Regards, Alexander





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Pax-JDBC-1-1-hikari-pool-and-XA-Support-tp4050977.html
Sent from the Karaf - User mailing list archive at Nabble.com.



-- 

Guillaume Nodet

Require-Capability with effective:=active not ignored

[alexander.sahler]

Hi there.

According to 
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
 (and the OSGi spec), a R-C header with effective:=active should be ignored by 
OSGi framework. But when I create a R-C header like

Require-Capability: 
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"

to indicate a dependency to a DataSource, the resolver tells me:

org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=isaac-app; type=karaf.feature; 
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
 [caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing requirement 
[isaac-app/2.1.2.SNAPSHOT] osgi.identity; osgi.identity=isaac-service; 
type=karaf.feature [caused by: Unable to resolve isaac-service/2.1.2.SNAPSHOT: 
missing requirement [isaac-service/2.1.2.SNAPSHOT] osgi.identity; 
osgi.identity=com.brodos.isaac.service; type=osgi.bundle; 
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused by: 
Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing requirement 
[com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service; 
objectClass=javax.sql.DataSource; effective:=active; 
filter:="(osgi.jndi.service.name=bam)"]]]

Shouldn't it be ignored by OSGi framework?

What I try to achieve is that a certain bundle activation is postponed until a 
given requirement is met. Is is possible anyways?

Best regards,
Alexander

Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hello Tim.

Thanks for the quick response and the clarification. In fact it's
exactly like you described. My intention is to postpone the
STARTING/ACTIVE state until a certain requirement is fulfilled. 

Using DS is currently not an option as the whole project uses blueprint
and the mix of DS and blueprint is not recommended as far as I know.

Thanks anyways. I worked around by having the activator waiting until a
given object is registered in jndi.

Regards,
Alexander


>>> 
Hi Alexander,

An active time capability is ignored by the OSGi framework. This means
that it will not prevent your OSGi bundle moving from the INSTALLED
state to the RESOLVED state. 

What you’re seeing is that the resolver can also be run elsewhere, for
example to find or validate a set of bundles to be installed. This is
usually called a “provisioning operation”, and is what Karaf is trying
to do here. When the resolver is used by these tools they are free to
decide which requirements should be effective, and in this case Karaf is
requiring that your active time capability is matched by something
(after all it’s not optional!).



What I try to achieve is that a certain bundle activation is postponed
until a given requirement is met. Is is possible anyways?

What do you mean by bundle activation? If you mean that you want your
bundle to remain in the INSTALLED state then you need to use a
resolve-time effective requirement for this. If you mean that you want
your bundle not to move to the STARTING/ACTIVE state then
requirements/capabilites cannot help with this. Instead you should react
to the registration of OSGi services. A tool like Declarative Services
will make this easy, and allow your components to dynamically respond to
the presence (or lack of) an OSGi service.

Regards,

Tim



On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de wrote:

Hi there.

According to
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-service-filter-effective-active-and-blueprint
(and the OSGi spec), a R-C header with effective:=active should be
ignored by OSGi framework. But when I create a R-C header like

Require-Capability:
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(osgi.jndi.service.name=bam)"

to indicate a dependency to a DataSource, the resolver tells me:

org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=isaac-app;
type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]";
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSHOT)(version<=2.1.2.SNAPSHOT))"
[caused by: Unable to resolve isaac-app/2.1.2.SNAPSHOT: missing
requirement [isaac-app/2.1.2.SNAPSHOT] osgi.identity;
osgi.identity=isaac-service; type=karaf.feature [caused by: Unable to
resolve isaac-service/2.1.2.SNAPSHOT: missing requirement
[isaac-service/2.1.2.SNAPSHOT] osgi.identity;
osgi.identity=com.brodos.isaac.service; type=osgi.bundle;
version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; resolution:=mandatory [caused
by: Unable to resolve com.brodos.isaac.service/2.1.2.SNAPSHOT: missing
requirement [com.brodos.isaac.service/2.1.2.SNAPSHOT] osgi.service;
objectClass=javax.sql.DataSource; effective:=active;
filter:="(osgi.jndi.service.name=bam)"]]]

Shouldn't it be ignored by OSGi framework?

What I try to achieve is that a certain bundle activation is postponed
until a given requirement is met. Is is possible anyways?

Best regards,
Alexander

Re: Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hi Tim.

Well, maybe I made myself not completely clear. Of course it is
possible to mix DS and blueprint even in the same bundle when you use
services for communication but as you say, it's normally not a good
idea.
> Mixing blueprint and DS in the same bundle isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.

However I find it very confusing to use annotations from three
different ecosystems (blueprint, pax-cdi and scr/DS). 

Currently, I in fact use sort of busy-waiting in the BundleActivator
(with rxJava/retryWhen) failing after appox. 1 minute until the resource
comes up. But I will definitely give it a try with DS as is is for sure
the cleaner approach.

Thanks for the advice!

Regards,
Alexander.

>>> Timothy Ward  schrieb am Mittwoch, 16. August
2017 um

12:27 in Nachricht <50cd1d90-699f-405d-b1cb-e02f36d05...@paremus.com>:

> Hi Alexander,
> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
> 
> By whom and why? OSGi services are OSGi services, it doesn’t matter
which 
> framework you use to register or consume them. I regularly use
mixtures of 
> frameworks without issue. Mixing blueprint and DS in the same bundle
isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.
> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
> 
> How exactly are you waiting, and is this a real 
> org.osgi.framework.BundleActivator? That’s a pretty low level type
and offers 
> you pretty much no help, you would probably get a lot of benefit by
*not* 
> using a BundleActivator and using DS or blueprint instead. Also you
*must 
> not* block in your activator start method as this risks deadlocking
the 
> system.
> 
> Regards,
> 
> Tim
> 
>> On 16 Aug 2017, at 11:08,  

>  wrote:

>> 
>> Hello Tim.
>> 
>> Thanks for the quick response and the clarification. In fact it's
exactly 
> like you described. My intention is to postpone the STARTING/ACTIVE
state 
> until a certain requirement is fulfilled.
>> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
>> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
>> 
>> Regards,
>> Alexander
>> 
>> 
>> 
>> Hi Alexander,
>> 
>> An active time capability is ignored by the OSGi framework. This
means that 
> it will not prevent your OSGi bundle moving from the INSTALLED state
to the 
> RESOLVED state. 
>> 
>> What you’re seeing is that the resolver can also be run elsewhere,
for 
> example to find or validate a set of bundles to be installed. This is
usually 
> called a “provisioning operation”, and is what Karaf is trying to do
here. 
> When the resolver is used by these tools they are free to decide
which 
> requirements should be effective, and in this case Karaf is requiring
that 
> your active time capability is matched by something (after all it’s
not 
> optional!).
>> 
>>> What I try to achieve is that a certain bundle activation is
postponed until 
> a given requirement is met. Is is possible anyways?
>> 
>> What do you mean by bundle activation? If you mean that you want
your bundle 
> to remain in the INSTALLED state then you need to use a resolve-time

> effective requirement for this. If you mean that you want your bundle
not to 
> move to the STARTING/ACTIVE state then requirements/capabilites
cannot help 
> with this. Instead you should react to the registration of OSGi
services. A 
> tool like Declarative Services will make this easy, and allow your
components 
> to dynamically respond to the presence (or lack of) an OSGi service.
>>
 
>> Regards,
>> 
>> Tim
>> 
>>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 

>  wrote:

>>> 
>>> Hi there.
>>> 
>>> According to 
>
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servic


> e-filter-effective-active-and-blueprint 
>
 ce-filter-effective-active-and-blueprint> (and the OSGi spec), a R-C
header 
> with effective:=active should be ignored by OSGi framework. But when
I create 
> a R-C header like
>>> 
>>> Require-Capability: 
>
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(o
> sgi.jndi.service.name=bam)"
>>> 
>>> to indicate a dependency to a DataSource, the resolver tells me:
>>> 
>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
root: 
> missing requirement [root] osgi.identity; osgi.identity=isaac-app; 
> type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
>
filter:="(&(osgi.identity=isaac-app)(type=karaf.feature)(version>=2.1.2.SNAPSH
> OT)(version<=2.1.2.SNAPSHOT))" [caused by: Unable to resolve 
> isaac-app/2.1.2.SNA

Re: Antw: Re: Require-Capability with effective:=active not ignored

[alexander.sahler]

Hello Tim.

How am I to use DS with @Component annotaition when having
blueprint-maven-plugin in place!
Is it possible anyways?

Regards,
Alexander.


>>> 
Hi Tim.

Well, maybe I made myself not completely clear. Of course it is
possible to mix DS and blueprint even in the same bundle when you use
services for communication but as you say, it's normally not a good
idea.
> Mixing blueprint and DS in the same bundle isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.

However I find it very confusing to use annotations from three
different ecosystems (blueprint, pax-cdi and scr/DS). 

Currently, I in fact use sort of busy-waiting in the BundleActivator
(with rxJava/retryWhen) failing after appox. 1 minute until the resource
comes up. But I will definitely give it a try with DS as is is for sure
the cleaner approach.

Thanks for the advice!

Regards,
Alexander.

>>> Timothy Ward  schrieb am Mittwoch, 16. August
2017 um

12:27 in Nachricht <50cd1d90-699f-405d-b1cb-e02f36d05...@paremus.com>:

> Hi Alexander,
> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
> 
> By whom and why? OSGi services are OSGi services, it doesn’t matter
which 
> framework you use to register or consume them. I regularly use
mixtures of 
> frameworks without issue. Mixing blueprint and DS in the same bundle
isn’t 
> normally a good idea, but even that works fine if you use services to

> communicate.
> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
> 
> How exactly are you waiting, and is this a real 
> org.osgi.framework.BundleActivator? That’s a pretty low level type
and offers 
> you pretty much no help, you would probably get a lot of benefit by
*not* 
> using a BundleActivator and using DS or blueprint instead. Also you
*must 
> not* block in your activator start method as this risks deadlocking
the 
> system.
> 
> Regards,
> 
> Tim
> 
>> On 16 Aug 2017, at 11:08,  

>  wrote:

>> 
>> Hello Tim.
>> 
>> Thanks for the quick response and the clarification. In fact it's
exactly 
> like you described. My intention is to postpone the STARTING/ACTIVE
state 
> until a certain requirement is fulfilled.
>> 
>> Using DS is currently not an option as the whole project uses
blueprint and 
> the mix of DS and blueprint is not recommended as far as I know.
>> 
>> Thanks anyways. I worked around by having the activator waiting
until a 
> given object is registered in jndi.
>> 
>> Regards,
>> Alexander
>> 
>> 
>> 
>> Hi Alexander,
>> 
>> An active time capability is ignored by the OSGi framework. This
means that 
> it will not prevent your OSGi bundle moving from the INSTALLED state
to the 
> RESOLVED state. 
>> 
>> What you’re seeing is that the resolver can also be run elsewhere,
for 
> example to find or validate a set of bundles to be installed. This is
usually 
> called a “provisioning operation”, and is what Karaf is trying to do
here. 
> When the resolver is used by these tools they are free to decide
which 
> requirements should be effective, and in this case Karaf is requiring
that 
> your active time capability is matched by something (after all it’s
not 
> optional!).
>> 
>>> What I try to achieve is that a certain bundle activation is
postponed until 
> a given requirement is met. Is is possible anyways?
>> 
>> What do you mean by bundle activation? If you mean that you want
your bundle 
> to remain in the INSTALLED state then you need to use a resolve-time

> effective requirement for this. If you mean that you want your bundle
not to 
> move to the STARTING/ACTIVE state then requirements/capabilites
cannot help 
> with this. Instead you should react to the registration of OSGi
serv
ices. A 
> tool like Declarative Services will make this easy, and allow your
components 
> to dynamically respond to the presence (or lack of) an OSGi service.
>> 
>> Regards,
>> 
>> Tim
>> 
>>> On 16 Aug 2017, at 07:43, alexander.sah...@brodos.de 

>  wrote:

>>> 
>>> Hi there.
>>> 
>>> According to 
>
http://osgi-dev.mail.osgi.narkive.com/GfJqfPGZ/require-capability-osgi-servic


> e-filter-effective-active-and-blueprint 
>
 ce-filter-effective-active-and-blueprint> (and the OSGi spec), a R-C
header 
> with effective:=active should be ignored by OSGi framework. But when
I create 
> a R-C header like
>>> 
>>> Require-Capability: 
>
osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter:="(o
> sgi.jndi.service.name=bam)"
>>> 
>>> to indicate a dependency to a DataSource, the resolver tells me:
>>> 
>>> org.osgi.service.resolver.ResolutionException: Unable to resolve
root: 
> missing requirement [root] osgi.identity; osgi.identity=isaac-app; 
> type=karaf.feature; version="[2.1.2.SNAPSHOT,2.1.2.SNAPSHOT]"; 
>
filter:=

pax-web-jetty bundle is unable to find class com.ctc.wstx.stax.WstxInputFactory

[alexander.sahler]

Hi all.

I wrote a servlet filter to be used in a web (WAR) deployment. The servlet 
filter performs a remote request to a SOAP service with a configurable WSDL 
location. So the wsdl is not known locally to the web project. When creating 
the SOAP client, I get an exception the stacktrace of which is: 

java.lang.Exception: Throwable caught while executing.
at 
com.netflix.hystrix.AbstractCommand.getExceptionFromThrowable(AbstractCommand.java:1942)[17:com.netflix.hystrix.core:1.5.6]
at 
com.netflix.hystrix.AbstractCommand.wrapWithOnExecutionErrorHook(AbstractCommand.java:1469)[17:com.netflix.hystrix.core:1.5.6]
at 
com.netflix.hystrix.AbstractCommand.access$1300(AbstractCommand.java:59)[17:com.netflix.hystrix.core:1.5.6]
at 
com.netflix.hystrix.AbstractCommand$ExecutionHookApplication$1.onError(AbstractCommand.java:1340)[17:com.netflix.hystrix.core:1.5.6]
at 
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at 
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:44)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:28)[23:io.reactivex.rxjava:1.2.0]
at 
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at 
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reactivex.rxjava:1.2.0]
at 
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDoOnEach.call(OnSubscribeDoOnEach.java:41)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeDoOnEach.call(OnSubscribeDoOnEach.java:30)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at 
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at 
rx.internal.operators.OperatorSubscribeOn$1.call(OperatorSubscribeOn.java:94)[23:io.reactivex.rxjava:1.2.0]
at 
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction$1.call(HystrixContexSchedulerAction.java:56)[17:com.netflix.hystrix.core:1.5.6]
at 
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction$1.call(HystrixContexSchedulerAction.java:47)[17:com.netflix.hystrix.core:1.5.6]
at 
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction.call(HystrixContexSchedulerAction.java:69)[17:com.netflix.hystrix.core:1.5.6]
at 
rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:55)[23:io.reactivex.rxjava:1.2.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_66]
at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_66]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_66]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_66]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
Caused by: javax.xml.stream.FactoryConfigurationError: Provider for class 
javax.xml.stream.XMLInputFactory cannot be created
at 
javax.xml.stream.FactoryFinder.findServiceProvider(FactoryFinder.java:370)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:313)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:227)
at 
javax.xml.stream.XMLInputFactory.newInstance(XMLIn

Antw: RE: pax-web-jetty bundle is unable to find class com.ctc.wstx.stax.WstxInputFactory

[alexander.sahler]

Hi Matt.

Well, setting the thread's class loader clearly assumes knowledge of
the internals of the used components. When the implementation of the
dependent components change changes, your implementation may break or
cease to work correctly. 

I consider setting the bundle classloader a code smell.

Best regards, 
Alexander.


>>> 
Hi Alex,
 
I encountered a similar issue when executing xslt from a camel route
deployed in karaf. I think your fix is fine.
 
I solved my issue my setting the thread class loader to the bundle’s
classloader before executing my code.
 
Cheers,
Matt.
 
From: alexander.sah...@brodos.de [mailto:alexander.sah...@brodos.de]
Sent: Thursday, 7 September 2017 12:32 AM
To: user@karaf.apache.org
Subject: pax-web-jetty bundle is unable to find class
com.ctc.wstx.stax.WstxInputFactory
 
Hi all.
 
I wrote a servlet filter to be used in a web (WAR) deployment. The
servlet filter performs a remote request to a SOAP service with a
configurable WSDL location. So the wsdl is not known locally to the web
project. When creating the SOAP client, I get an exception the
stacktrace of which is:
 
java.lang.Exception: Throwable caught while executing.
at
com.netflix.hystrix.AbstractCommand.getExceptionFromThrowable(AbstractCommand.java:1942)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand.wrapWithOnExecutionErrorHook(AbstractCommand.java:1469)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand.access$1300(AbstractCommand.java:59)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand$ExecutionHookApplication$1.onError(AbstractCommand.java:1340)[17:com.netflix.hystrix.core:1.5.6]
at
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:44)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:28)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDoOnEach.call(OnSubscribeDoOnEach.java:41)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDoOnEach.call(OnSubscribeDoOnEach.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava
:1.2.0]
at
rx.internal.operators.OperatorSubscribeOn$1.call(OperatorSubscribeOn.java:94)[23:io.reactivex.rxjava:1.2.0]
at
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction$1.call(HystrixContexSchedulerAction.java:56)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction$1.call(HystrixContexSchedulerAction.java:47)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.strategy.concurrency.HystrixContexSchedulerAction.call(HystrixContexSchedulerAction.java:69)[17:com.netflix.hystrix.core:1.5.6]
at
rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:55)[23:io.reactivex.rxjava:1.2.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_66]
a

OSGi Transaction control fails with hibernate

[alexander.sahler]

Hello.

I'm trying to get tx-control with XA transactions running (local is working). 
I found that tx-control opens a JTA transaction using 
RecoveryWorkAroundTransactionManager (derived from geronimo's 
TransactionManager Implementation) explicitly instead of using the registered 
TransactionManager (aries in my case for karaf 4.0.9). When hibernate 
EntityManager implementation tries to join the transaction it fails because it 
uses the TransactionManager provided by OsgiJtaPlatform (from hibernate-osgi) 
which is of course the one registered in osgi ecosystem.

I think that the tx-control implementation has to use the TransactionManager 
registered with OSGi.

Has anyone got that thing ever running?

Best Alexander.

Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

Hi Tim,

I use a JPAEntityManagerProviderFactory (providerFactory) which I
inject as a service reference into my repository class. 
Furthermore, I inject a EntityManagerFactory (emf) into the repository
class as well as the TransactionControl (txControl).

The provider Factory is created by pax-jdbc (I use hibernate).

This provider factory is then used to get the Entity manager like
this:

EntityManager em = providerFactory.getProviderFor(emf,
null).getResource(txControl);

It fails giving an exception telling that transaction cannot be joined,
because it's not open.

The wrapping call is like this:
txControl.build()
.required(
() -> repo.store(article));

Best, Alexander.


>>> 
Hi Alexander,

Do you have a code example of how you’re obtaining and using the
EntityManager? There should be no usage of the OSGiJtaPlatform from the
tx-control XA JPA resource provider, which means that there’s either a
bug in the resource provider, or something is misconfigured. If you are
a member of the Aries user mailing list then that would be a better
place to continue this discussion.

Regards,

Tim



On 13 Sep 2017, at 09:21, Guillaume Nodet  wrote:

Fwiw, you should ask on the Aries mailing list, where tx-control is
developed.

I've recently worked on a new project called pax-transx which provides
an abstraction layer on top of transaction managers so that some
features can be accessed in a common way.  I think this should be used
in tx-control instead of wrapping the tm again and not being flexible.
Right now, tx-control uses its own instance of transaction manager and
there's no way around afaik, so you can't use the karaf transaction
feature if you want to use it.
Anyway, I'd gladly support you if you go to the aries mailing list to
raise this point !

2017-09-13 9:52 GMT+02:00 :


Hello.

I'm trying to get tx-control with XA transactions running (local is
working). 
I found that tx-control opens a JTA transaction using
RecoveryWorkAroundTransactionManager (derived from geronimo's
TransactionManager Implementation) explicitly instead of using the
registered TransactionManager (aries in my case for karaf 4.0.9). When
hibernate EntityManager implementation tries to join the transaction it
fails because it uses the TransactionManager provided by OsgiJtaPlatform
(from hibernate-osgi) which is of course the one registered in osgi
ecosystem.

I think that the tx-control implementation has to use the
TransactionManager registered with OSGi.

Has anyone got that thing ever running?

Best Alexander.



-- 

Guillaume Nodet

Re: Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

Thanks Tim for the update.

I tried the approach with providing a factory config in
karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as:
osgi.unit.name=DSContext2
osgi.jdbc.driver.class=org.h2.Driver
url=jdbc:h2:mem:article
user=sa
password=

whilst having a mininmal persistence.xml like:






(without the dialect I see another exception; Access to
DialectResolutionInfo cannot be null when 'hibernate.dialect' not set).

Now I get further in the process (transaction enlistment works) but
when actually accessing the database, the entity manager throws a NPE
while trying to open the connection. In
JPAEntityManagerProviderFactoryImpl.EnlistingDataSource.enlistedConnection()
while calling supplier.call, the supplier.delegate member is null:

org.osgi.service.transaction.control.TransactionException: There was a
problem getting hold of a database connection
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.enlistedConnection(JPAEntityManagerProviderFactoryImpl.java:241)
~[?:?]
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.getConnection(JPAEntityManagerProviderFactoryImpl.java:193)
~[?:?]
at
org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
~[?:?]
at
org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35)
~[?:?]
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:99)
~[?:?]
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:129)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:47)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:146)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:172)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:148)
~[?:?]
at
org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1940)
~[?:?]
at
org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1909)
~[?:?]
at
org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1887)
~[?:?]
at org.hibernate.loader.Loader.doQuery(Loader.java:932)
~[?:?]
at
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:349)
~[?:?]
at org.hibernate.loader.Loader.doList(Loader.java:2615)
~[?:?]
at org.hibernate.loader.Loader.doList(Loader.java:2598)
~[?:?]
at
org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2430)
~[?:?]
at org.hibernate.loader.Loader.list(Loader.java:2425)
~[?:?]
at
org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:335)
~[?:?]
at
org.hibernate.internal.SessionImpl.listCustomQuery(SessionImpl.java:2153)
~[?:?]
at
org.hibernate.internal.AbstractSharedSessionContract.list(AbstractSharedSessionContract.java:991)
~[?:?]
at
org.hibernate.query.internal.NativeQueryImpl.doList(NativeQueryImpl.java:147)
~[?:?]
at
org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1410)
~[?:?]
at
org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1459)
~[?:?]
at
com.brodos.ds.persistence.h2.TestRepositoryImpl.lambda$checkHealth$0(TestRepositoryImpl.java:47)
~[?:?]
at
org.apache.aries.tx.control.service.common.impl.AbstractT
ransactionControlImpl$TransactionBuilderImpl.doWork(AbstractTransactionControlImpl.java:161)
[241:tx-control-service-xa:0.0.3]
at
org.apache.aries.tx.control.service.common.impl.AbstractTransactionControlImpl$TransactionBuilderImpl.required(AbstractTransactionControlImpl.java:84)
[241:tx-control-service-xa:0.0.3]
at
org.apache.aries.tx.control.service.common.impl.AbstractTransactionControlImpl.required(AbstractTransactionControlImpl.java:263)
[241:tx-control-service-xa:0.0.3]
at
com.brodos.ds.persistence.h2.TestRepositoryImpl.checkHealth(TestRepositoryImpl.java:44)
[160:com.brodos.example.ds.DSContext-infrastructure:1.0.0.SNAPSHOT]
at
com.brodos.ds.service.impl.MainHealthCheck.checkHealth(MainHealthCheck.java:29)
[209:com.brodos.example.ds.DSContext-service:1.0.0.SNAPSHOT]
at
com.brodos.ds.application.boundary.impl.HealthCheckImpl.checkHealth(HealthCheckImpl.java:37)
[212:com.brodos.example.ds.DSContext-appl

Re: Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

Hi Tim.

I'm using the 2.6.1 version of aries jpa support already. Normal
transaction control with blueprint and @Transactional annotation was
working fine. 

To have better control over startup dependencies and cope with
disappearing and appearing services during runtime we invest some time
in a Proof-Of-Concept for switching over to declarative services (DS).
Everything works fine so far - even restful services for DS with
cxf-dosgi works fine. Last bit to get it working is transaction
management. With DS, the @Transactional annotation is not working
anymore due to the lack of interceptors with DS.

What do you think of the idea that tx-control should pick up a JTS
Transaction manager from the service registry instead of creating an own
one with new operator which is in fact tightly coupled. To implement
loose coupling here we should add a factory that may be configurable in
the factory config file.

BTW, should we switch the discussion to aries group still?

Best, Alexander.


>>> 
Hi Alexander,

That looks like it should be fine - what version of Aries JPA are you
using? There were some fixes made to Aries JPA in 2.4.0 to add support
for JPA 2.1 configuration properties which are needed by the transaction
control implementation, and I think that there were then more fixes in
2.5.0 which are needed to get XA working with Hibernate. 2.6.1 is the
latest release version.

Regards,

Tim




On 13 Sep 2017, at 15:42, alexander.sah...@brodos.de wrote:

Thanks Tim for the update.

I tried the approach with providing a factory config in
karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as:
osgi.unit.name=DSContext2
osgi.jdbc.driver.class=org.h2.Driver
url=jdbc:h2:mem:article
user=sa
password=

whilst having a mininmal persistence.xml like:






(without the dialect I see another exception; Access to
DialectResolutionInfo cannot be null when 'hibernate.dialect' not set).

Now I get further in the process (transaction enlistment works) but
when actually accessing the database, the entity manager throws a NPE
while trying to open the connection. In
JPAEntityManagerProviderFactoryImpl.EnlistingDataSource.enlistedConnection()
while calling supplier.call, the supplier.delegate member is null:

org.osgi.service.transaction.control.TransactionException: There was a
problem getting hold of a database connection
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.enlistedConnection(JPAEntityManagerProviderFactoryImpl.java:241)
~[?:?]
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.getConnection(JPAEntityManagerProviderFactoryImpl.java:193)
~[?:?]
at
org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
~[?:?]
at
org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35)
~[?:?]
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:99)
~[?:?]
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:129)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:47)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:146)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:172)
~[?:?]
at
org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:148)
~[?:?]

   at
org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1940)
~[?:?]
at
org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1909)
~[?:?]
at
org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1887)
~[?:?]
at org.hibernate.loader.Loader.doQuery(Loader.java:932)
~[?:?]
at
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:349)
~[?:?]
at org.hibernate.loader.Loader.doList(Loader.java:2615)
~[?:?]
at org.hibernate.loader.Loader.doList(Loader.java:2598)
~[?:?]
at
org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2430)
~[?:?]
at org.hibernate.loader.Loader.list(Loader.java:2425)
~[?:?]
at
org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:335)
~[?:?]
at
org.hibernate.internal.SessionImpl.listCustomQuery(SessionImpl.java:2153)
~[?:?]
at
org.hibernate.internal.AbstractSharedSessionContract.list(AbstractSharedSessionContract.java:991)
~[?:?]
at
org.hibernate.query.inter

RE: Antw: RE: pax-web-jetty bundle is unable to find class com.ctc.wstx.stax.WstxInputFactory

[alexander.sahler]

Hi Stephan.

OMG, it's so easy! 

1st of all, you are right. It's (if anyways) an issue of war support,
not pax-web.
2nd: It's not an issue at all. I didn't have the Import-Package for
com.ctc.wstx.stax in the war bundle. As soon as I add it, I don't need
the fragment any more.

Thanks!

Bast regards, 
Alexander



>>> 
Hi,
 
to come back to the original problem. When parsing a web.xml the
war-extender should consider the class loader of the war (or wab). So if
the wab manifest is containing an import statement for com.ctc.wstx.stax
or the war is containing the Woodstox-parser this should actually be
resolvable. The pax-web-jetty fragment works because the processing is
also including the classloader of that bundle in order to be able to
load artifacts that come with the web container (jetty).
 
I didn’t find any pax-web classes in the stack trace you provided,
which confuses me a little. When do you get this exception and how does
the manifest of your war look like?
 
Best regards
Stephan
 
From: Matthew Shaw [mailto:matthew.s...@ambulance.qld.gov.au]
Sent: Donnerstag, 7. September 2017 23:21
To: user@karaf.apache.org
Subject: RE: Antw: RE: pax-web-jetty bundle is unable to find class
com.ctc.wstx.stax.WstxInputFactory
 
Yep, fair point. Depends on your situation I guess.
 
From:alexander.sah...@brodos.de [mailto:alexander.sah...@brodos.de]
Sent: Thursday, 7 September 2017 6:31 PM
To: user@karaf.apache.org
Subject: Antw: RE: pax-web-jetty bundle is unable to find class
com.ctc.wstx.stax.WstxInputFactory
 
Hi Matt.
 
Well, setting the thread's class loader clearly assumes knowledge of
the internals of the used components. When the implementation of the
dependent components change changes, your implementation may break or
cease to work correctly. 
 
I consider setting the bundle classloader a code smell.
 
Best regards,
Alexander.


>>> 
Hi Alex,
 
I encountered a similar issue when executing xslt from a camel route
deployed in karaf. I think your fix is fine.
 
I solved my issue my setting the thread class loader to the bundle’s
classloader before executing my code.
 
Cheers,
Matt.
 
From:alexander.sah...@brodos.de [mailto:alexander.sah...@brodos.de]
Sent: Thursday, 7 September 2017 12:32 AM
To: user@karaf.apache.org
Subject: pax-web-jetty bundle is unable to find class
com.ctc.wstx.stax.WstxInputFactory
 
Hi all.
 
I wrote a servlet filter to be used in a web (WAR) deployment. The
servlet filter performs a remote request to a SOAP service with a
configurable WSDL location. So the wsdl is not known locally to the web
project. When creating the SOAP client, I get an exception the
stacktrace of which is:
 
java.lang.Exception: Throwable caught while executing.
at
com.netflix.hystrix.AbstractCommand.getExceptionFromThrowable(AbstractCommand.java:1942)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand.wrapWithOnExecutionErrorHook(AbstractCommand.java:1469)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand.access$1300(AbstractCommand.java:59)[17:com.netflix.hystrix.core:1.5.6]
at
com.netflix.hystrix.AbstractCommand$ExecutionHookApplication$1.onError(AbstractCommand.java:1340)[17:com.netflix.hystrix.core:1.5.6]
at
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at
rx.observers.Subscribers$5.onError(Subscribers.java:230)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:44)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeThrow.call(OnSubscribeThrow.java:28)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reactivex.rxjava:1.2.0]

   at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)[23:io.reactivex.rxjava:1.2.0]
at
rx.Observable.unsafeSubscribe(Observable.java:10151)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:51)[23:io.reactivex.rxjava:1.2.0]
at
rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:35)[23:io.reac

Re: Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

I'll give it a try. Maybe with a little guidance of you guys. First of
all I'll try to inject a JTA TransactionManager into tx-control instead
of the internal one. If that is working, I'll let you know.


>>> 



On 14 Sep 2017, at 10:46, Guillaume Nodet  wrote:



2017-09-14 11:40 GMT+02:00 Timothy Ward :


Hi Alexander,

As has been discussed on the Aries lists before, I have no problem with
someone creating a separate implementation of the Transaction Control
service which leverages the OSGi JTA Service Specification. The reason
that the current implementation doesn’t do this is twofold:

By embedding a transaction manager the current Tx Control
implementation can avoid the javax.transaction split package from the
JVM. This makes the implementation easier to use and deploy because the
user doesn’t need to mess around with the boot class path, or worry
about what JTA version is available
By embedding a transaction manager the current Tx control
implementation can rely on specific behaviours of the transaction
manager that it uses. This means that the Tx control implementation can
support the last resource gambit and XA recovery.
Fwiw, as I already indicated, the pax-transx project provides a layer
solving those problems, in addition of providing additional features and
pluggability.

Would you be interested to incorporate it in Tx Control ?

This is not something that I have the time to do, but another
implementation of a transaction control service with a pluggable
transaction manager would be a great addition.




Guillaume
 



If this is a proof of concept project then are you able to share it
somewhere (e.g. GitHub)? I’d like to help you get to the bottom of the
NPE that you’re seeing as I don’t think it should be possible for that
to be happening!

Finally - yes the Aries user list is the best place to talk about this,
but I don’t want to move the conversation myself as I don’t know whether
you’re registered for that list, and don’t want you to miss my replies.

Regards,

Tim




On 14 Sep 2017, at 07:53, 
 wrote:

Hi Tim.

I'm using the 2.6.1 version of aries jpa support already. Normal
transaction control with blueprint and @Transactional annotation was
working fine.

To have better control over startup dependencies and cope with
disappearing and appearing services during runtime we invest some time
in a Proof-Of-Concept for switching over to declarative services (DS).
Everything works fine so far - even restful services for DS with
cxf-dosgi works fine. Last bit to get it working is transaction
management. With DS, the @Transactional annotation is not working
anymore due to the lack of interceptors with DS.

What do you think of the idea that tx-control should pick up a JTS
Transaction manager from the service registry instead of creating an own
one with new operator which is in fact tightly coupled. To implement
loose coupling here we should add a factory that may be configurable in
the factory config file.

BTW, should we switch the discussion to aries group still?

Best, Alexander.



Hi Alexander,

That looks like it should be fine - what version of Aries JPA are you
using? There were some fixes made to Aries JPA in 2.4.0 to add support
for JPA 2.1 configuration properties which are needed by the transaction
control implementation, and I think that there were then more fixes in
2.5.0 which are needed to get XA working with Hibernate. 2.6.1 is the
latest release version.

Regards,

Tim




On 13 Sep 2017, at 15:42, alexander.sah...@brodos.de wrote:

Thanks Tim for the update.

I tried the approach with providing a factory config in
karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as:
osgi.unit.name=DSContext2
osgi.jdbc.driver.class=org.h2.Driver
url=jdbc:h2:mem:article
user=sa
password=

whilst having a mininmal persistence
.xml like:






(without the dialect I see another exception; Access to
DialectResolutionInfo cannot be null when 'hibernate.dialect' not set).

Now I get further in the process (transaction enlistment works) but
when actually accessing the database, the entity manager throws a NPE
while trying to open the connection. In
JPAEntityManagerProviderFactoryImpl.EnlistingDataSource.enlistedConnection()
while calling supplier.call, the supplier.delegate member is null:

org.osgi.service.transaction.control.TransactionException: There was a
problem getting hold of a database connection
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.enlistedConnection(JPAEntityManagerProviderFactoryImpl.java:241)
~[?:?]
at
org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.getConnection(JPAEntityManagerProviderFactoryImpl.java:193)
~[?:?]
at
org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
~[?:?]
at
org.hi

Re: Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

Tim,

please find the project here:
https://github.com/sahlex/declarative-poc

Best, Alexander.


>>> 
Note that this work should be done as part of a new transaction control
service implementation (there’s some common code which should help to
speed up implementing it), not as changes to the current implementation,
which is undergoing stabilisation as the Reference Implementation of the
OSGi Transaction control service.

Also this update still won’t avoid the need for the JPA resource
provider to have a custom plugin for transaction integration. The whole
point of a managed resource is that it integrates with the Transaction
Control service that gets passed to it, not by integrating with a third
party service which may, or may not, be involved.

Alexander - is there any chance of seeing the proof of concept code? It
seems as though it’s pretty close to working with the existing bundles.

Regards,

Tim




On 14 Sep 2017, at 12:42, 
 wrote:

I'll give it a try. Maybe with a little guidance of you guys. First of
all I'll try to inject a JTA TransactionManager into tx-control instead
of the internal one. If that is working, I'll let you know.


>>> 



On 14 Sep 2017, at 10:46, Guillaume Nodet  wrote:



2017-09-14 11:40 GMT+02:00 Timothy Ward :


Hi Alexander,

As has been discussed on the Aries lists before, I have no problem with
someone creating a separate implementation of the Transaction Control
service which leverages the OSGi JTA Service Specification. The reason
that the current implementation doesn’t do this is twofold:

By embedding a transaction manager the current Tx Control
implementation can avoid the javax.transaction split package from the
JVM. This makes the implementation easier to use and deploy because the
user doesn’t need to mess around with the boot class path, or worry
about what JTA version is available
By embedding a transaction manager the current Tx control
implementation can rely on specific behaviours of the transaction
manager that it uses. This means that the Tx control implementation can
support the last resource gambit and XA recovery.
Fwiw, as I already indicated, the pax-transx project provides a layer
solving those problems, in addition of providing additional features and
pluggability.

Would you be interested to incorporate it in Tx Control ?

This is not something that I have the time to do, but another
implementation of a transaction control service with a pluggable
transaction manager would be a great addition.




Guillaume
 



If this is a proof of concept project then are you able to share it
somewhere (e.g. GitHub)? I’d like to help you get to the bottom of the
NPE that you’re seeing as I don’t think it should be possible for that
to be happening!

Finally - yes the Aries user list is the best place to talk about this,
but I don’t want to move the conversation myself as I don’t know whether
you’re registered for that list, and don’t want you to miss my replies.

Regards,

Tim




On 14 Sep 2017, at 07:53, 
 wrote:

Hi Tim.

I'm using the 2.6.1 version of aries jpa support already. Normal
transaction control with blueprint and @Transactional annotation was
working fine.

To have better control over startup dependencies and cope with
disappearing and appearing services during runtime we invest some time
in a Proof-Of-Concept for switching over to declarative services (DS).
Everything works fine so far - even restful services for DS with
cxf-dosgi works fine. Last bit to get it working is transaction
management. With DS, the @Transactional annotation is not working
anymore due to the lack of interceptors with DS.

What do you think of the idea that tx-control should pick up a JTS
Transaction manager from the service registry instead of creating an own
on
e with new operator which is in fact tightly coupled. To implement
loose coupling here we should add a factory that may be configurable in
the factory config file.

BTW, should we switch the discussion to aries group still?

Best, Alexander.



Hi Alexander,

That looks like it should be fine - what version of Aries JPA are you
using? There were some fixes made to Aries JPA in 2.4.0 to add support
for JPA 2.1 configuration properties which are needed by the transaction
control implementation, and I think that there were then more fixes in
2.5.0 which are needed to get XA working with Hibernate. 2.6.1 is the
latest release version.

Regards,

Tim




On 13 Sep 2017, at 15:42, alexander.sah...@brodos.de wrote:

Thanks Tim for the update.

I tried the approach with providing a factory config in
karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as:
osgi.unit.name=DSContext2
osgi.jdbc.driver.class=org.h2.Driver
url=jdbc:h2:mem:article
user=sa
password=

whilst having a mininmal persistence.xml like:






(without the dialect I see another exception; Access to
DialectResolutionInfo cannot be null when 'hibernate.dialect' not set).

Now I get further in the 

Antw: Re: vaadin 8 wrapped jar dependency doesn't go active

[alexander.sahler]

Hi.

Vaadin 8.1.4 uses gentyref version 1.2.0.vaadin1. I included that in my 
feature. Maybe working for 8.1.5 as well.


http
http-whiteboard
mvn:org.jsoup/jsoup/1.8.3
mvn:com.vaadin.external/gentyref/1.2.0.vaadin1
mvn:com.vaadin/vaadin-shared/${vaadin.version}
mvn:com.vaadin/vaadin-server/${vaadin.version}

mvn:com.vaadin/vaadin-osgi-integration/${vaadin.version}

mvn:com.vaadin/vaadin-client-compiled/${vaadin.version}
mvn:com.vaadin/vaadin-themes/${vaadin.version}


Regards,
Alexander


>>> 
Good Morning Steiner,

Your bundle doesnt have version specified


Bundle-Version: 0
To fix this you need to add the bundle-version to your wrap like


wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0&Bundle-Version=1.2.0
I hope this helps

Christian

Am 05.10.2017 um 21:48 schrieb Steinar Bang :



I'm trying to create a karaf 4.1.2 feature that installs vaadin 8.1.5.

One dependency is com.googlecode.gentyref.  The newest version of
gentyref I've found is this non-OSGi jar file:
https://mvnrepository.com/artifact/com.googlecode.gentyref/gentyref/1.2.0

I've tried to add this jar as a wrap bundle in the feature file:
http://karaf.apache.org/xmlns/features/v1.4.0"; 
name="fildele.application">
   
   wrap
   pax-http-whiteboard
   wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0
   mvn:no.priv.bang.fildele/fildele.application/1.0.0-SNAPSHOT
   mvn:com.vaadin/vaadin-shared/8.1.5
   mvn:com.vaadin/vaadin-server/8.1.5
   mvn:com.vaadin/vaadin-push/8.1.5
   mvn:com.vaadin/vaadin-client-compiled/8.1.5
   mvn:com.vaadin/vaadin-themes/8.1.5
   


But this feature fails in the installation:
karaf@root()> feature:repo-add 
mvn:no.priv.bang.fildele/fildele.application/LATEST/xml/features
Adding feature url 
mvn:no.priv.bang.fildele/fildele.application/LATEST/xml/features
karaf@root()> feature:install fildele
Error executing command: Unable to resolve root: missing requirement [root] 
osgi.identity; osgi.identity=fildele; type=karaf.feature; 
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=fildele)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
 [caused by: Unable to resolve fildele/1.0.0.SNAPSHOT: missing requirement 
[fildele/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=com.vaadin.server; 
type=osgi.bundle; version="[8.1.5,8.1.5]"; resolution:=mandatory [caused by: 
Unable to resolve com.vaadin.server/8.1.5: missing requirement 
[com.vaadin.server/8.1.5] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=com.googlecode.gentyref)(version>=1.2.0)(!(version>=2.0.0)))"]]
karaf@root()>

When I try to install the troublesome jar directly, it doesn't go active:
karaf@root()> bundle:install wrap:mvn:com.googlecode.gentyref/gentyref/1.2.0
Bundle ID: 52
karaf@root()> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State  | Lvl | Version | Name
---+---+-+-+
28 | Active|  80 | 4.1.2   | Apache Karaf :: OSGi Services :: Event
52 | Installed |  80 | 0   | 
wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
karaf@root()> bundle:capabilities 52
Bundle 52 is not resolved.
karaf@root()>

The manifest.mf of data/cache/bundle52/version0.0 has no imports:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Bnd-LastModified: 1507232709268
Build-Jdk: 1.7.0_51
Built-By: wouter
Bundle-ManifestVersion: 2
Bundle-Name: wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
Bundle-SymbolicName: wrap_mvn_com.googlecode.gentyref_gentyref_1.2.0
Bundle-Version: 0


Created-By: 1.8.0_141 (Oracle Corporation)
Export-Package: com.googlecode.gentyref
Generated-By-Ops4j-Pax-From: wrap:mvn:com.googlecode.gentyref/gentyref/1
 .2.0
Originally-Created-By: Apache Maven 3.2.1
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.5))"
Tool: Bnd-2.3.0.201405100607

What am I doing wrong?

Thanks!


- Steinar

Problem with NamedXAResource.

[alexander.sahler]

Hi there.

Following the description on http://cxf.apache.org/docs/jms-transactions.html, 
I set up a JMS XA transaction together with pax-jdbc datasource in karaf 4.1.2.

The datasource looks like this:

osgi.jdbc.driver.name = mariadb
dataSourceName = jmsTest
databaseName = test
user = test
password = test
pool = aries
xa = true
url = jdbc:mariadb://172.17.42.50:3309/test?characterEncoding=UTF-8

the jms config is like this (blueprint.xml):


























However, I still get an exception when committing the transaction:

2017-12-15T15:31:02,989 | ERROR | 
DefaultQuartzScheduler-com.brodos.example.jmstest.jmsTest-service-quartzCamelPublisher_Worker-4
 | Transaction   | 216 - 
org.apache.aries.transaction.manager - 1.3.3 | Please correct the integration 
and supply a NamedXAResource
java.lang.IllegalStateException: Cannot log transactions as 
TransactionContext{transactionId=null,connection=ActiveMQConnection 
{id=ID:dbserver-p2-46845-1513344298542-9:2,clientId=ID:dbserver-p2-46845-1513344298542-8:1,started=false}}
 is not a NamedXAResource.
at 
org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java:781)
 [216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:287) 
[216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java:467)
 [216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:312)
 [216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
 [216:org.apache.aries.transaction.manager:1.3.3]
at Proxy288c74b2_e728_4a18_9e5f_69dd12784603.commit(Unknown Source) 
[?:?]
at 
org.apache.aries.transaction.TransactionAttribute$5.finish(TransactionAttribute.java:138)
 [215:org.apache.aries.transaction.blueprint:2.1.0]
at 
org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:105)
 [215:org.apache.aries.transaction.blueprint:2.1.0]
at 
org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:76)
 [11:org.apache.aries.blueprint.core:1.8.2]
at 
Proxy1e31f2f9_b5f0_4b21_b4f7_80d8cf3712a1.publishNotifications(Unknown Source) 
[?:?]
at 
com.brodos.jmsconurrent.service.notification.NotificationBatchProcessor.publishNotifications(NotificationBatchProcessor.java:46)
 [194:com.brodos.example.jmstest.jmsTest-service:1.0.0.SNAPSHOT]
at sun.reflect.GeneratedMethodAccessor250.invoke(Unknown Source) 
~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:497) ~[?:?]
at 
org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:472) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.component.bean.MethodInfo$1.doProceed(MethodInfo.java:291) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:264) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:178) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.component.bean.BeanProducer.process(BeanProducer.java:41) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
 [21:org.apache.camel.camel-core:2.19.2]
...

I'm using JPA/2.6.1 feature and hibernate 5.2.10.Final as persistence provider.

Could anyone please give a hint what's wrong here?

Best,
Alexander

Antw: Re: Problem with NamedXAResource.

[alexander.sahler]

Hi Benjamin!

Thank you very much! That's indeed solved the issue.

Best, Alexander


>>> 
> 
Hi Alexander,
you didn't name your JMS XA resource. Set a name property at 
JcaPooledConnectionFactory e.g. amq. That should solve this Exception
Regards,
Benjamin

Am 15.12.2017 um 16:41 schrieb alexander.sah...@brodos.de:


Hi there.

Following the description on http://cxf.apache.org/docs/jms-transactions.html, 
I set up a JMS XA transaction together with pax-jdbc datasource in karaf 4.1.2.

The datasource looks like this:

osgi.jdbc.driver.name = mariadb
dataSourceName = jmsTest
databaseName = test
user = test
password = test
pool = aries
xa = true
url = jdbc:mariadb://172.17.42.50:3309/test?characterEncoding=UTF-8

the jms config is like this (blueprint.xml):


























However, I still get an exception when committing the transaction:

2017-12-15T15:31:02,989 | ERROR | 
DefaultQuartzScheduler-com.brodos.example.jmstest.jmsTest-service-quartzCamelPublisher_Worker-4
 | Transaction | 216 - org.apache.aries.transaction.manager - 1.3.3 | Please 
correct the integration and supply a NamedXAResource
java.lang.IllegalStateException: Cannot log transactions as 
TransactionContext{transactionId=null,connection=ActiveMQConnection{id=ID:dbserver-p2-46845-1513344298542-9:2,clientId=ID:dbserver-p2-46845-1513344298542-8:1,started=false}}
 is not a NamedXAResource.
at 
org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java:781)
 [216:org.apache.aries.transaction.manager:1.3.3]
at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:287) 
[216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java:467)
 [216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:312)
 [216:org.apache.aries.transaction.manager:1.3.3]
at 
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
 [216:org.apache.aries.transaction.manager:1.3.3]
at Proxy288c74b2_e728_4a18_9e5f_69dd12784603.commit(Unknown Source) [?:?]
at 
org.apache.aries.transaction.TransactionAttribute$5.finish(TransactionAttribute.java:138)
 [215:org.apache.aries.transaction.blueprint:2.1.0]
at 
org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:105)
 [215:org.apache.aries.transaction.blueprint:2.1.0]
at 
org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:76)
 [11:org.apache.aries.blueprint.core:1.8.2]
at Proxy1e31f2f9_b5f0_4b21_b4f7_80d8cf3712a1.publishNotifications(Unknown 
Source) [?:?]
at 
com.brodos.jmsconurrent.service.notification.NotificationBatchProcessor.publishNotifications(NotificationBatchProcessor.java:46)
 [194:com.brodos.example.jmstest.jmsTest-service:1.0.0.SNAPSHOT]
at sun.reflect.GeneratedMethodAccessor250.invoke(Unknown Source) ~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:497) ~[?:?]
at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:472) 
[21:org.apache.camel.camel-core:2.19.2]
at org.apache.camel.component.bean.MethodInfo$1.doProceed(MethodInfo.java:291) 
[21:org.apache.camel.camel-core:2.19.2]
at org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:264) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:178) 
[21:org.apache.camel.camel-core:2.19.2]
at org.apache.camel.component.bean.BeanProducer.process(BeanProducer.java:41) 
[21:org.apache.camel.camel-core:2.19.2]
at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145) 
[21:org.apache.camel.camel-core:2.19.2]
at 
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
 [21:org.apache.camel.camel-core:2.19.2]
...

I'm using JPA/2.6.1 feature and hibernate 5.2.10.Final as persistence provider.

Could anyone please give a hint what's wrong here?

Best,
Alexander