The changes are already present in master since quite some time. So it
would be difficult to release a 0.10.0 without it.
I was already tempted to create the new docs in the wiki but did not
want to confuse users with it before there is also released code to
support it.
I will do the
Hi Sascha
welcome aboard ! Great to have you there !
One thing that I would like to do in Pax JDBC is to be compliant with
blueprint (in addition of ConfigAdmin).
Thanks to that we would be able to deal with "old" and "new" style
datasource service in Karaf.
Another thing I saw is the
I have documented how the new pooling and XA support works.
I think the new support is much more straightforward to use and gives
better error reporting.
For example in the old pooling support if you use the pooling and xa
enabled DSF "H2-pool-xa" and forget to install a TransactionManager
I think we should clearly document the level of safety using those pooling
mechanism.
Afaik, hikari and dbcp2 do not support automatic transaction recovery, the
only combinations I'm aware of are:
* aries transaction manager + pax-jdbc-pooling-aries
* narayana transaction manager +
Hi all,
thank you all very much for the warm welcome!
Am 03.11.2016 um 11:08 schrieb Jean-Baptiste Onofré:
> One thing that I would like to do in Pax JDBC is to be compliant with
> blueprint (in addition of ConfigAdmin).
> Thanks to that we would be able to deal with "old" and "new" style
>
I fully agree.. The even bigger problem is that people do not really
understand what recoverable means at all.
Until recently my understanding was that without recovery all running
transactions would simply be rolled back in case of a crash .. but this
does not seem to be the case.
Luckily I
Yes, all in flight transactions will remain in-flight until the transaction
manager can heuristically determine that they should be rolled back or
committed, which happen when the transaction manager is informed about the
state of the various transactional resources (in our case, the JDBC
In the failing case,
Thread[paxweb-config-1-thread-1,5,main]
has a context class loader that is not an OSGi bundle class loader at
all. Jetty uses the context class loader, and things go badly.
I can make this problem appear and disappear by changing what is in
the classpath _outside_ the
Hi,
from my experience with "inside"/"outside" set ups, I can feel your pain.
Have you considered to package all the "outside" into a single large bundle
and deploy that "inside" ??
Niclas
On Fri, Nov 4, 2016 at 5:41 AM, Benson Margulies
wrote:
> In the failing case,
>
>
On Thu, Nov 3, 2016 at 6:08 PM, Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:
> No objection for a 0.10.0 release.
> On the other hand, I think we can consider 1.0.0 release after a 0.11.0.
I think it would be great to figure out if there are any "breaking changes"
needed. If not,
10 matches
Mail list logo