[jira] [Commented] (ARIES-1314) Update service reference when service with higher ranking gets registered

2017-04-10 Thread Anne-Catherine Courouppe (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963156#comment-15963156
 ] 

Anne-Catherine Courouppe commented on ARIES-1314:
-

Hi, 
What the status of this ticket? Any idea when it could be fixed?

> Update service reference when service with higher ranking gets registered
> -
>
> Key: ARIES-1314
> URL: https://issues.apache.org/jira/browse/ARIES-1314
> Project: Aries
>  Issue Type: Improvement
>  Components: Blueprint
>Reporter: Jochen Kraushaar
>Assignee: Christian Schneider
>
> Consider the following scenario:
> Bundle X uses the service defined by API Bundle A. 
> Bundle A1 implements A and has a service ranking of 1. 
> Bundle A2 implements A and has a service ranking of 10.
> The bundles get started in the following order: A, A1, X, A2
> In the current implementation X will use A1 till e.g. A1 gets stopped and 
> started again - according to [~ch...@die-schneider.net] in this post: 
> http://karaf.922171.n3.nabble.com/Karaf-3-0-1-does-not-consider-service-ranking-set-by-Blueprint-tp4039991p4040041.html
> I propose that X switches from A1 to A2 when A2 gets registered as A2 has a 
> higher service ranking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot

2017-04-10 Thread Christian Schneider (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962795#comment-15962795
 ] 

Christian Schneider commented on ARIES-1698:


That sounds good to me. Can you also announce on the dev list that we switch to 
the 1.1 API SNAPSHOT and aim for being a reference impl with version 2.7.0 and 
also the time frame?
I think this is an important decision that should be done on the list .. at 
least using lazy consensus.


> Aries JPA should update to the latest OSGi API snapshot
> ---
>
> Key: ARIES-1698
> URL: https://issues.apache.org/jira/browse/ARIES-1698
> Project: Aries
>  Issue Type: Bug
>Affects Versions: jpa-2.6.0
>Reporter: Timothy Ward
>Assignee: Timothy Ward
> Fix For: jpa-2.7.0
>
>
> Given the stated intent of making Aries JPA the Reference Implementation for 
> version 1.1.0 of the OSGi JPA service, Aries JPA should start building 
> against the latest snapshot of the JPA service API. This is publicly 
> available from [https://oss.sonatype.org/content/repositories/osgi/]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot

2017-04-10 Thread Timothy Ward (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962729#comment-15962729
 ] 

Timothy Ward commented on ARIES-1698:
-

> Hi Tim. I just looked into the snapshot version of the spec you included in 
> this change. Is it any different from the 1.0.0 version? It looks to me like 
> it is identical.

It actually is different. There's a new constant identifying the name of the 
JPA extender capability.

> Do we need the new version of the spec for something? I would like to avoid 
> having a snapshot dependency as we can then not release easily.

We need it for three reasons :)

1. The OSGi CT requires the JPA Service API at version 1.1 - without this no 
tests will run
2. The OSGi CT performs a signature check on the API classes - without the new 
constant this fails.
3. The Aries JPA extender needs to be updated to check the wiring of the 
persistence bundle, and ignore it if it is wired to a different extender (or if 
it uses the wrong version of javax.persistence). This should use the constant 
from the v 1.1 API.

If there is a need for an urgent bug fix in 2.6.x then we can always do it as a 
2.6.x+1 based on top of the 2.6.x branch. I see the big 2.7.0 feature being 
"Aries as the JPA Service RI" - this should be possible in the next 3 months or 
so, which seems ok to me as a release schedule given that 2.6.0 was only 6 
weeks ago.

> Aries JPA should update to the latest OSGi API snapshot
> ---
>
> Key: ARIES-1698
> URL: https://issues.apache.org/jira/browse/ARIES-1698
> Project: Aries
>  Issue Type: Bug
>Affects Versions: jpa-2.6.0
>Reporter: Timothy Ward
>Assignee: Timothy Ward
> Fix For: jpa-2.7.0
>
>
> Given the stated intent of making Aries JPA the Reference Implementation for 
> version 1.1.0 of the OSGi JPA service, Aries JPA should start building 
> against the latest snapshot of the JPA service API. This is publicly 
> available from [https://oss.sonatype.org/content/repositories/osgi/]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: TX Control support for more recent hibernate versions

2017-04-10 Thread Timothy Ward 
Hi,

Thank you for flagging this issue - it would be great if you could raise a JIRA 
to track it. It shouldn’t be too hard to detect the Hibernate version and 
auto-select the correct implementation, although it is unpleasant that they’ve 
moved a public API in a point release of the software.

If you’d like to have a go at providing a patch then please feel free. It will 
be at least a couple of weeks before I have any time to devote to the issue I’m 
afraid.

Best Regards,

Tim Ward.

> On 22 Mar 2017, at 15:08, ivoleitao  wrote:
> 
> Hi !,
> 
> I'm testing transaction control service and I was able to use local
> transaction with hibernate 5.2.6. However with XA transactions I'm getting a
> rather nasty exception as depicted at the end of this post.
> 
> Also, it's clear on the documentation
> (http://aries.apache.org/modules/tx-control/xaJPA.html) that it was tested
> only in hibernate 5.1 but since version 5.2 brings so much to the table
> namely java 8 native it would be interesting to have it supported. Also it's
> the default version on karaf 4.1 on the enterprise feature (which is what
> I'm currently using)
> 
> I've taken a look at the code, namely at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPAEMFLocator and this line:
> 
> providerBundle.loadClass("org.hibernate.resource.transaction.TransactionCoordinatorBuilder");
> 
> expects TransactionCoordinatorBuilder in the package
> org/hibernate/resource/transaction
> (https://docs.jboss.org/hibernate/orm/5.1/javadocs/org/hibernate/resource/transaction/TransactionCoordinatorBuilder.html).
>  
> 
> Unfortunately in hibernate 5.2 this class is no longer located at this
> package :-S but on org/hibernate/resource/transaction/spi
> 
> (https://docs.jboss.org/hibernate/orm/5.2/javadocs/org/hibernate/resource/transaction/spi/TransactionCoordinatorBuilder.html)
> 
> Any plans to correct this issue in a future version of transaction control
> (0.0.3 perhaps ?). For now I have fall back to local transactions but it's
> important to have xa transactions for my use case.
> 
> java.lang.NoClassDefFoundError:
> org/hibernate/resource/transaction/TransactionCoordinatorBuilder
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPAEMFLocator$1.loadClass(XAJPAEMFLocator.java:168)
> at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPAEMFLocator.setupTransactionManager(XAJPAEMFLocator.java:98)
> at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPAEMFLocator.lambda$getResourceProvider$11(XAJPAEMFLocator.java:61)
> at
> org.apache.aries.tx.control.jpa.xa.impl.DelayedJPAEntityManagerProvider.getResource(DelayedJPAEntityManagerProvider.java:53)
> at
> org.apache.aries.tx.control.jpa.xa.impl.DelayedJPAEntityManagerProvider.getResource(DelayedJPAEntityManagerProvider.java:29)
> at
> com.celfocus.platform.samples.modules.todo.data.ri.AbstractDAO.prepare(AbstractDAO.java:43)
> at
> com.celfocus.platform.samples.modules.todo.data.ri.AbstractDAO.prepare(AbstractDAO.java:51)
> at
> com.celfocus.platform.samples.modules.todo.data.ri.db.task.TaskDAOImpl.activate(TaskDAOImpl.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:224)
> at
> org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39)
> at
> org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:617)
> at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:501)
> at
> org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:302)
> at
> org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:294)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:297)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:108)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344)
> at org.apache.felix.framework.Felix.getService(Felix.java:3699)
> at
>