Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.6

[Timothy Ward]

+ 1

> On 23 Sep 2019, at 07:59, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On Fri, 20 Sep 2019 at 15:35, Carlos Sierra Andrés 
> wrote:
> 
>> Hello all,
>> 
>> I have staged a release 1.0.6 for Aries JAX-RS Whiteboard.
>> 
>> The release notes can be found here:
>> 
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12346248
>> 
>> which are important fixes and there are also improvements in performance.
>> 
>> The modules are tagged at
>> 
>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs-1.0.6
>> 
>> Artifacts are in one staged repo,
>> https://repository.apache.org/content/repositories/orgapachearies-1169
>> 
>> Instructions for verifying the release are at
>> http://aries.apache.org/development/verifyingrelease.html.
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Here is my +1.
>> 
>> Thanks to all.
>> 
>> Carlos.
>> 
>> 
>> 
>> 
>> 
>> 
>> 

Re: [Discuss] Remove Aries JAX-RS servlet on top level (by default)

[Timothy Ward]

I’m pretty sure that the page you’re talking about is not a servlet, but a 
default JAX-RS resource designed to show you that you have the whiteboard up 
and running. The servlet(s) registered by the JAX-RS whiteboard cannot be 
removed without breaking the whiteboard (they provide the HTTP input to the 
JAX-RS resources).

Tim

> On 20 Sep 2019, at 13:57, Raymond Auge  wrote:
> 
> https://issues.apache.org/jira/browse/ARIES-1931
> 
> On Fri, Sep 20, 2019 at 8:25 AM Raymond Auge 
> wrote:
> 
>> I think I'm the only one that likes it so I guess we should remove it ☺️.
>> 
>> - Ray
>> 
>> On Fri, Sep 20, 2019, 03:35 Christian Schneider, 
>> wrote:
>> 
>>> I can not speak for other users of jax-rs but for me personally it was
>>> rather annoying that the main page of my web server suddenly shows some
>>> kind of advertisement for Aries JAX-RS. The page also does not really help
>>> in getting your first jax-rs sevice up.
>>> 
>>> Of course better documentation allows to easily understand how to remove
>>> it
>>> again, but it forces everyone to apply this configuration. No one will
>>> want
>>> this information page on top level in their finished product.
>>> 
>>> How about instead of showing this page we offer a pre built example bundle
>>> that can simply be installed to show the system is running. This would
>>> leave the main jar ready for production use and still allow the user to
>>> easily check jax-rs works in his environment. I am willing to create such
>>> an example and document how to use it.
>>> 
>>> Christian
>>> 
>>> Am Do., 19. Sept. 2019 um 17:02 Uhr schrieb Raymond Auge <
>>> raymond.a...@liferay.com>:
>>> 
 In fact I could add this tidbit of information in the default web page
 itself.
 
 I think it's nice to boot up a bare jaxrs runtime with at least
>>> something
 that shows it works.
 
 - Ray
 
 On Thu, Sep 19, 2019 at 11:00 AM Raymond Auge >>> 
 wrote:
 
> Is setting the configuration property `default.web=false` in a
> configuration for PID `org.apache.aries.jax.rs.whiteboard.default`
>>> not
> sufficient?
> 
> - Ray
> 
> On Thu, Sep 19, 2019 at 8:48 AM Jean-Baptiste Onofré >>> 
> wrote:
> 
>> +1
>> 
>> it makes sense and it would avoid to eventually "conflict" with user
>> space servlet.
>> 
>> Regards
>> JB
>> 
>> On 19/09/2019 14:46, Christian Schneider wrote:
>>> Currently when you install the Aries JAX-RS whiteboard it installs
>>> a
>>> servlet on top level of the http server with some information
>>> around
>> Aries
>>> JAX-RS.
>>> I think this is not a good idea as it interferes with possible
>>> other
>>> servlets. It can be deactivated with a property but I think this is
>> still a
>>> bad default.
>>> 
>>> So I propose to not install the servlet by default and instead
>>> allow
 to
>>> activate it via a property or even better an OSGi config.
>>> 
>>> WDYT?
>>> 
>>> Christian
>>> 
>> 
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
> 
> 
> --
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> 
 
 
 --
 *Raymond Augé* 
 (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
 
>>> 
>>> 
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Computer Scientist
>>> http://www.adobe.com
>>> 
>> 
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)

Re: [VOTE] Apache Aries Proxy 1.1.5 release

[Timothy Ward]

+1

> On 17 Jun 2019, at 20:33, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Aries Proxy 1.1.5 release to your vote.
> 
> This proxy release updates to ASM 7.1 in order to support JDK 12.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344850
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachearies-1164
> 
> Git Tag:
> org.apache.aries.proxy-1.1.5
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks !
> 
> Regards
> JB

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.5

[Timothy Ward]

+1 (binding)

> On 28 May 2019, at 16:47, Grzegorz Grzybek  wrote:
> 
> +1
> 
> regards
> Grzegorz Grzybek
> 
> wt., 28 maj 2019 o 15:23 Jean-Baptiste Onofré  napisał(a):
> 
>> +1 (binding)
>> 
>> Regards
>> JB
>> 
>> On 28/05/2019 12:59, Carlos Sierra Andrés wrote:
>>> Hello all,
>>> 
>>> I have staged a release 1.0.5 for Aries JAX-RS Whiteboard.
>>> 
>>> The release notes for Whiteboard 1.0.5 can be found here:
>>> 
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12345589
>>> 
>>> which are important fixes and there are also improvements in
>>> registration and packaging.
>>> 
>>> The modules are tagged at
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs-1.0.5
>>> 
>>> Artifacts are in one staged repo,
>>> https://repository.apache.org/content/repositories/orgapachearies-1163
>>> 
>>> Instructions for verifying the release are at
>>> http://aries.apache.org/development/verifyingrelease.html.
>>> 
>>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>>> 
>>> Here is my +1.
>>> 
>>> Thanks to all.
>>> 
>>> Carlos.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 

Re: [VOTE] Release Spi-Fly Version 1.2.1

[Timothy Ward]

+1

> On 7 Mar 2019, at 20:15, Raymond Auge  wrote:
> 
> Hello everyone,
> 
> Here are the release notes for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344558
> 
> The staging repo is here:
> https://repository.apache.org/content/repositories/orgapachearies-1158
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1158 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Resolved] (ARIES-1900) Release Transaction Control 1.0.1

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1900.
-
Resolution: Fixed

> Release Transaction Control 1.0.1
> -
>
> Key: ARIES-1900
> URL: https://issues.apache.org/jira/browse/ARIES-1900
> Project: Aries
>  Issue Type: New Feature
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Jira issue to track the release of Aries Tx Control 1.0.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Aries Transaction Control Services and Providers 1.0.1

[Timothy Ward]

This vote passes with 6 binding +1 votes.

Thank you all.

Tim

> On 21 Feb 2019, at 20:09, Dominik Przybysz  wrote:
> 
> +1
> 
> czw., 21 lut 2019 o 19:14 Jean-Baptiste Onofré  napisał(a):
> 
>> +1 (binding)
>> 
>> Regards
>> JB
>> 
>> On 21/02/2019 16:34, Timothy Ward wrote:
>>> Hello all,
>>> 
>>> I have staged a release 1.0.1 for the entirety of Aries Transaction
>> Control.
>>> 
>>> The release notes for this release can be found here<
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344984>,
>> but are included below for your convenience:
>>> 
>>> Artifacts are in one staged repo
>> https://repository.apache.org/content/repositories/orgapachearies-1157
>>> 
>>> Instructions for verifying the release are at
>>> http://aries.apache.org/development/verifyingrelease.html.
>>> 
>>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>>> 
>>> Here is my +1.
>>> 
>>> Thanks to all.
>>> 
>>> Tim
>>> 
>>> Release Notes
>>> 
>>> Improvement
>>> 
>>>  *   [ARIES-1897<https://issues.apache.org/jira/browse/ARIES-1897>] -
>> Update to HikariCP 3.3.0
>>>  *   [ARIES-1898<https://issues.apache.org/jira/browse/ARIES-1898>] -
>> Update to bnd 4.1.0
>>> 
>>> Test
>>> 
>>>  *   [ARIES-1895<https://issues.apache.org/jira/browse/ARIES-1895>] -
>> Add tests for OpenJPA 3.0
>>>  *   [ARIES-1896<https://issues.apache.org/jira/browse/ARIES-1896>] -
>> Provide integration tests for the Transaction Control Service
>> implementations
>>> 
>>> 
>> 
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
> 
> 
> -- 
> Pozdrawiam / Regards,
> Dominik Przybysz

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.4 and integrations 1.0.2

[Timothy Ward]

+1 (binding)

Tim

> On 21 Feb 2019, at 16:46, Dominik Przybysz  wrote:
> 
> +1
> 
> czw., 21 lut 2019 o 16:42 Christian Schneider 
> napisał(a):
> 
>> +1
>> 
>> Christian
>> 
>> Am Do., 21. Feb. 2019 um 15:37 Uhr schrieb Carlos Sierra Andrés <
>> csie...@apache.org>:
>> 
>>> Hello all,
>>> 
>>> I have staged a release 1.0.4 for Aries JAX-RS Whiteboard and 1.0.2 for
>>> whiteboard integrations.
>>> 
>>> The release notes for Whiteboard 1.0.4 can be found here:
>>> 
>>> 
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344853
>>> 
>>> The modules are tagged at
>>> 
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs-1.0.4
>>> 
>>> and
>>> 
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs.integration-1.0.2
>>> 
>>> Artifacts are in one staged repo,
>>> https://repository.apache.org/content/repositories/orgapachearies-1156
>>> 
>>> Instructions for verifying the release are at
>>> http://aries.apache.org/development/verifyingrelease.html.
>>> 
>>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>>> 
>>> Here is my +1.
>>> 
>>> Thanks to all.
>>> 
>>> Carlos.
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Computer Scientist
>> http://www.adobe.com
>> 
> 
> 
> -- 
> Pozdrawiam / Regards,
> Dominik Przybysz

[VOTE] Release Aries Transaction Control Services and Providers 1.0.1

[Timothy Ward]

Hello all,

I have staged a release 1.0.1 for the entirety of Aries Transaction Control.

The release notes for this release can be found 
here,
 but are included below for your convenience:

Artifacts are in one staged repo 
https://repository.apache.org/content/repositories/orgapachearies-1157

Instructions for verifying the release are at
http://aries.apache.org/development/verifyingrelease.html.

The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1

Here is my +1.

Thanks to all.

Tim

Release Notes

Improvement

  *   [ARIES-1897] - Update 
to HikariCP 3.3.0
  *   [ARIES-1898] - Update 
to bnd 4.1.0

Test

  *   [ARIES-1895] - Add 
tests for OpenJPA 3.0
  *   [ARIES-1896] - Provide 
integration tests for the Transaction Control Service implementations

[jira] [Created] (ARIES-1900) Release Transaction Control 1.0.1

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1900:
---

 Summary: Release Transaction Control 1.0.1
 Key: ARIES-1900
 URL: https://issues.apache.org/jira/browse/ARIES-1900
 Project: Aries
  Issue Type: New Feature
  Components: tx-control
Affects Versions: tx-control-1.0.0
Reporter: Timothy Ward
 Fix For: tx-control-1.0.1


Jira issue to track the release of Aries Tx Control 1.0.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSS] - Release of Aries Tx Control 1.0.1

[Timothy Ward]

There have been some minor improvements across the Transaction Control 
components since the 1.0.0 release. Mostly these are additional tests (OpenJPA 
3.0, Transaction Control), but there have also been updates to bnd and HikariCP.

The latest build snapshots still pass the OSGi compliance tests, and our 
existing test suite is pretty comprehensive, particularly with the new 
additions. I’m therefore proposing that it’s time for a 1.0.1 release (the last 
release was 9 months ago). 

My hope is that the next set of updates will be to add JPA 2.2 support, but 
this would be a significant effort (updates to Aries JPA and then a 1.1.0 of 
the JPA resource provider) and I don’t think it should block the release of 
these other enhancements.

I’m sending this mail out just to check whether anyone else has pending changes 
that they want to put into the release. If so we can discuss adding them. 
Assuming there isn’t anything I’ll be in a position to start a vote by the end 
of the week.

Thanks,

Tim

[jira] [Commented] (ARIES-1897) Update to HikariCP 3.3.0

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1897:
-

Update in 99a405d0039d556b6bfa8f66448388d4d15ef268

> Update to HikariCP 3.3.0
> 
>
> Key: ARIES-1897
> URL: https://issues.apache.org/jira/browse/ARIES-1897
> Project: Aries
>  Issue Type: Improvement
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Minor
> Fix For: tx-control-1.0.1
>
>
> The Resource Providers for JDBC and JPA embed HikariCP for database 
> connection pooling. We should update to the latest released version of this 
> library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARIES-1898) Update to bnd 4.1.0

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1898:
---

 Summary: Update to bnd 4.1.0
 Key: ARIES-1898
 URL: https://issues.apache.org/jira/browse/ARIES-1898
 Project: Aries
  Issue Type: Improvement
  Components: tx-control
Affects Versions: tx-control-1.0.0
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: tx-control-1.0.1


Update to bnd 4.1.0 which adds support for R7 bundle annotations and DS 
annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1898) Update to bnd 4.1.0

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1898.
-
Resolution: Fixed

> Update to bnd 4.1.0
> ---
>
> Key: ARIES-1898
> URL: https://issues.apache.org/jira/browse/ARIES-1898
> Project: Aries
>  Issue Type: Improvement
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Update to bnd 4.1.0 which adds support for R7 bundle annotations and DS 
> annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1898) Update to bnd 4.1.0

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1898:
-

Update in c86b8c80a160beab3c5c222b036aa5c4a6cb051c

> Update to bnd 4.1.0
> ---
>
> Key: ARIES-1898
> URL: https://issues.apache.org/jira/browse/ARIES-1898
> Project: Aries
>  Issue Type: Improvement
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Update to bnd 4.1.0 which adds support for R7 bundle annotations and DS 
> annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1897) Update to HikariCP 3.3.0

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1897.
-
Resolution: Fixed

> Update to HikariCP 3.3.0
> 
>
> Key: ARIES-1897
> URL: https://issues.apache.org/jira/browse/ARIES-1897
> Project: Aries
>  Issue Type: Improvement
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Minor
> Fix For: tx-control-1.0.1
>
>
> The Resource Providers for JDBC and JPA embed HikariCP for database 
> connection pooling. We should update to the latest released version of this 
> library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARIES-1897) Update to HikariCP 3.3.0

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1897:
---

 Summary: Update to HikariCP 3.3.0
 Key: ARIES-1897
 URL: https://issues.apache.org/jira/browse/ARIES-1897
 Project: Aries
  Issue Type: Improvement
  Components: tx-control
Affects Versions: tx-control-1.0.0
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: tx-control-1.0.1


The Resource Providers for JDBC and JPA embed HikariCP for database connection 
pooling. We should update to the latest released version of this library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1896) Provide integration tests for the Transaction Control Service implementations

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1896.
-
Resolution: Fixed

> Provide integration tests for the Transaction Control Service implementations
> -
>
> Key: ARIES-1896
> URL: https://issues.apache.org/jira/browse/ARIES-1896
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Currently the Resource Providers have integration tests but the Transaction 
> Control implementations do not. There is good unit testing, but we should 
> provide at least some validation that the implementations start up and work 
> in an OSGi framework



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARIES-1896) Provide integration tests for the Transaction Control Service implementations

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1896:
---

 Summary: Provide integration tests for the Transaction Control 
Service implementations
 Key: ARIES-1896
 URL: https://issues.apache.org/jira/browse/ARIES-1896
 Project: Aries
  Issue Type: Test
  Components: tx-control
Affects Versions: tx-control-1.0.0
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: tx-control-1.0.1


Currently the Resource Providers have integration tests but the Transaction 
Control implementations do not. There is good unit testing, but we should 
provide at least some validation that the implementations start up and work in 
an OSGi framework



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1896) Provide integration tests for the Transaction Control Service implementations

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1896:
-

Tests added in 5baa38519ee155d03b96a33bb3f6cf310ee14c3d

> Provide integration tests for the Transaction Control Service implementations
> -
>
> Key: ARIES-1896
> URL: https://issues.apache.org/jira/browse/ARIES-1896
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Currently the Resource Providers have integration tests but the Transaction 
> Control implementations do not. There is good unit testing, but we should 
> provide at least some validation that the implementations start up and work 
> in an OSGi framework



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1895) Add tests for OpenJPA 3.0

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward updated ARIES-1895:

Affects Version/s: (was: 1.0)
   tx-control-1.0.0

> Add tests for OpenJPA 3.0
> -
>
> Key: ARIES-1895
> URL: https://issues.apache.org/jira/browse/ARIES-1895
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: tx-control-1.0.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Apache OpenJPA has released version 3.0 with JPA 2.1 support - we should 
> include this version in our integration tests to prove that we work properly 
> with this new major version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1895) Add tests for OpenJPA 3.0

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward updated ARIES-1895:

Fix Version/s: (was: 1.0.1)
   tx-control-1.0.1

> Add tests for OpenJPA 3.0
> -
>
> Key: ARIES-1895
> URL: https://issues.apache.org/jira/browse/ARIES-1895
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: 1.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: tx-control-1.0.1
>
>
> Apache OpenJPA has released version 3.0 with JPA 2.1 support - we should 
> include this version in our integration tests to prove that we work properly 
> with this new major version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1895) Add tests for OpenJPA 3.0

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1895.
-
Resolution: Fixed

> Add tests for OpenJPA 3.0
> -
>
> Key: ARIES-1895
> URL: https://issues.apache.org/jira/browse/ARIES-1895
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: 1.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: 1.0.1
>
>
> Apache OpenJPA has released version 3.0 with JPA 2.1 support - we should 
> include this version in our integration tests to prove that we work properly 
> with this new major version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1895) Add tests for OpenJPA 3.0

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1895:
-

Basic tests added in 4c825206e55e87cf96b0fe00c1fd4f69ecf4488c

XA tests added in acf0b4ad6cced73aae32122340bd2f419ff7ad10

 

 

> Add tests for OpenJPA 3.0
> -
>
> Key: ARIES-1895
> URL: https://issues.apache.org/jira/browse/ARIES-1895
> Project: Aries
>  Issue Type: Test
>  Components: tx-control
>Affects Versions: 1.0
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: 1.0.1
>
>
> Apache OpenJPA has released version 3.0 with JPA 2.1 support - we should 
> include this version in our integration tests to prove that we work properly 
> with this new major version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Aries CDI version 1.0.0

[Timothy Ward]

+1 (binding)

> On 7 Feb 2019, at 05:01, Raymond Auge  wrote:
> 
> Hi,
> This is release 1.0.0 of Aries CDI, the very first implementation of
> OSGi CDI Integration spec v1.0.
> 
> Staging repository is
> here:https://repository.apache.org/content/repositories/orgapachearies-1154
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [DISCUSS] Goals, Requirements and API for journaled events

[Timothy Ward]

Hi all,

I think this is an interesting area to look at, but one thing I see immediately 
is that the API is being designed in a way to encourage lifecycle issues. 
Specifically the service interface “subscribe” method receives a consumer 
function from the client. It would be *much* better if the subscribe method did 
not take a consumer, but instead the Subscription returned by the subscribe 
method should return a PushStream.

Making this change avoids the provider implementation from having to maintain a 
registry of instances from client bundles (the listener pattern is “considered 
harmful” in OSGi), which can leak memory and/or class loaders as client bundles 
are started/stopped/updated. Allowing the client to create PushStream instances 
on demand gives finer grained control for the client over when the stream of 
data processing is closed (both from within and without the data stream), and 
provides easier fail-safe defaults for late-registering clients.

You obviously get the further advantages of PushStreams including buffering, 
windowing and transformation pipelines. Using this would allow for simpler 
optimisation of the fetch logic in the Kafka/Mongo/Memory client when 
processing bulk messages from history.

Best Regards,

Tim

On 2 Jan 2019, at 07:30, Christian Schneider 
mailto:ch...@die-schneider.net>> wrote:

Am Mi., 2. Jan. 2019 um 02:05 Uhr schrieb Timothee Maret 
mailto:tma...@apache.org>
:

Hi,

I looked at the API considering how we could use it for our replication use
case. I identified one key concept that seemed to be missing, the indexing
of messages with monotonically increasing offsets.

For replication, we leverage those offsets extensively, for instance to
efficiently compute sub ranges of messages, to skip range of messages, to
delay processing of messages, to clean up resources, etc. If we want to
leverage the journaled event API to guarantee portability, it seems to me
that we'd need to have the offset or an equivalent construct part of the
API.

How about adding a "getOffset" signature and documenting the offset
requirement in the Position interface ?


I just started implementing the in memory impl of the API and also used an
offset.
For the cases I know an offset makes sense. Alexei and I were just unsure
if the offset
is really a general abstraction. If we all agree an offset makes sense then
I am in favour of adding it.
Actually in the case of no partitions (wich we currently assume) the
position is not more than an offset.


Another unclear intention to me in the API, is the support for partitions
(similar to Kafka). The documentation indicates it is not a goal, however
the API seems to contain some hints for multi-partition support such as the
"TopicPosition" interface. How about supporting multiple partitions in the
API by allowing to specify a key (with a semantic similar to Kafka) in the
"newMessage" signature ?


I removed the TopicPosition interface again a few days ago. It was not part
of the API Alexei and I discussed and makes no
sense when we limit ourself to no partitions (or 1 partition in case of
kafka).
So the main question is if limiting ourselves is a good idea. I think it is
but I would be very interested in other opinions.

Cheers
Christian

--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.3 and integrations 1.0.1

[Timothy Ward]

+1

> On 21 Dec 2018, at 15:13, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On Fri, 21 Dec 2018 at 14:09, Carlos Sierra Andrés 
> wrote:
> 
>> Hello all,
>> 
>> I have staged a release 1.0.3 for Aries JAX-RS Whiteboard and 1.0.1 for
>> whiteboard integrations.
>> 
>> This release fixes a bug that was causing a bad interaction with Karaf,a
>> missing license headers and a wrong artifact reference in the former
>> release of the whiteboard integrations.
>> 
>> The release notes for Whiteboard 1.0.3 can be found here:
>> 
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344639
>> 
>> The modules are tagged at
>> 
>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs-1.0.3
>> 
>> and
>> 
>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs.whiteboard.integrations-1.0.1
>> 
>> 
>> Artifacts are in one staged repo,
>> https://repository.apache.org/content/repositories/orgapachearies-1152
>> 
>> Instructions for verifying the release are at
>> http://aries.apache.org/development/verifyingrelease.html.
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Here is my +1.
>> 
>> Thanks to all.
>> 
>> Carlos.
>> 
>> 
>> 

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.2 and integrations 1.0.0

[Timothy Ward]

Sounds great to me. You already have my +1 :)

> On 11 Dec 2018, at 16:02, Raymond Auge  wrote:
> 
> Hey Tim,
> 
> Carlos and I talked more or less about a few cleanup tasks that are needed.
> But we decided to follow "release early, release often" mantra and fix
> those for the next release.
> 
> Sound good?
> - Ray
> 
> On Tue, Dec 11, 2018 at 8:05 AM Timothy Ward 
> wrote:
> 
>> +1 (binding)
>> 
>> Some things to note:
>> 
>> 
>>  *   The jettison tests depend on the itest fragment (version 1.0.0).
>> This isn’t deployed to central, so the tests only pass if it is in your
>> local repo. I was able to get the source for that, build it, and then
>> everything built cleanly. I don’t think this should hold up the release,
>> but I think it points at a potential issue in the jettison integration
>> project which will make it hard for users to deploy.
>>  *   The Shiro integration has one (and only one) missing licence header
>> `integrations/shiro/shiro-authc/src/main/java/org/apache/aries/jax/rs/shiro/authc/impl/ShiroAuthenticationFeatureProvider.java`
>> 
>> 
>> I don’t think these are serious enough to respin the releases. I assume
>> that others agree?
>> 
>> Tim
>> 
>> On 11 Dec 2018, at 06:40, Christian Schneider > <mailto:ch...@die-schneider.net>> wrote:
>> 
>> +1 (binding)
>> 
>> Christian
>> 
>> Am Mo., 10. Dez. 2018 um 19:15 Uhr schrieb Carlos Sierra Andrés <
>> csie...@apache.org<mailto:csie...@apache.org>>:
>> 
>> Hello all,
>> 
>> I have staged a release 1.0.2 for Aries JAX-RS Whiteboard and 1.0.0 for
>> whiteboard integrations.
>> 
>> The release notes for Whiteboard 1.0.2 can be found here:
>> 
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343907=12310981
>> 
>> The release notes for whiteboard integrations can be found here:
>> 
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344174
>> 
>> The module is tagged at
>> 
>> 
>> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs.whiteboard.integrations-1.0.0
>> 
>> Artifacts are in one staged repo,
>> https://repository.apache.org/content/repositories/orgapachearies-1151
>> 
>> Instructions for verifying the release are at
>> http://aries.apache.org/development/verifyingrelease.html.
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Here is my +1.
>> 
>> Thanks to all,
>> 
>> Carlos.
>> 
>> 
>> 
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Computer Scientist
>> http://www.adobe.com
>> 
>> 
> 
> -- 
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.2 and integrations 1.0.0

[Timothy Ward]

+1 (binding)

Some things to note:


  *   The jettison tests depend on the itest fragment (version 1.0.0). This 
isn’t deployed to central, so the tests only pass if it is in your local repo. 
I was able to get the source for that, build it, and then everything built 
cleanly. I don’t think this should hold up the release, but I think it points 
at a potential issue in the jettison integration project which will make it 
hard for users to deploy.
  *   The Shiro integration has one (and only one) missing licence header 
`integrations/shiro/shiro-authc/src/main/java/org/apache/aries/jax/rs/shiro/authc/impl/ShiroAuthenticationFeatureProvider.java`


I don’t think these are serious enough to respin the releases. I assume that 
others agree?

Tim

On 11 Dec 2018, at 06:40, Christian Schneider 
mailto:ch...@die-schneider.net>> wrote:

+1 (binding)

Christian

Am Mo., 10. Dez. 2018 um 19:15 Uhr schrieb Carlos Sierra Andrés <
csie...@apache.org>:

Hello all,

I have staged a release 1.0.2 for Aries JAX-RS Whiteboard and 1.0.0 for
whiteboard integrations.

The release notes for Whiteboard 1.0.2 can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343907=12310981

The release notes for whiteboard integrations can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344174

The module is tagged at

https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs.whiteboard.integrations-1.0.0

Artifacts are in one staged repo,
https://repository.apache.org/content/repositories/orgapachearies-1151

Instructions for verifying the release are at
http://aries.apache.org/development/verifyingrelease.html.

The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1

Here is my +1.

Thanks to all,

Carlos.



--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1866:
-

We've had confirmation from the OSGi EEG that this fix matches the intent of 
the spec, and that an erratum will be issued to clarify that this is what 
should be done by the implementation.

> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1867:
-

{quote}That makes me nervous because we generally assume that changes in 
configuration are not part of the business logic of an application. 
Configuration is the deployers domain, not application domain.

[~timothyjward] thoughts on this?
{quote}
 

I agree that this sounds like a bad idea - reconfiguring resources (and as a 
result unregistering/re-registering the resources) as part of a request made to 
those resources could have negative side effects (e.g. wiping the user session, 
re-injecting resource context properties, closing asynchronous responses before 
the response is made).

 

 

> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java, 
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
>   private Sse sse;
>   private SseBroadcaster eventBroadcaster;
>   @Context
>   public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
>   }
>   @GET
>   @Produces(MediaType.SERVER_SENT_EVENTS)
>   public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
>   }
> }
> {code}
>  
>  
> In addition, I have a CORS filter:
>  
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
>   @Override
>   public void filter(ContainerRequestContext requestContext, 
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for 
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin", 
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>  
> The CORS filter gets fired on all requests as I expect, _except_ for ones to 
> the EventResource.subscribeToEvents method. Hence browsers complain when 
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter 
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level 
> issue. I will try and come up with a plain CXF test of the same thing for 
> comparison.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1866:
-

{quote}BTW, what kind of release timetable would there be to getting a 
non-snapshot release with this in?
{quote}
 

We were planning one this week, but will now spend a little more time trying to 
iron out the recently identified bugs. Assuming nothing catastrophic emerges I 
would expect to see a release in Maven Central before the end of the year, 
hopefully in the next couple of weeks.

> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1856) Issue with redeployment in Bndtools

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1856.
-
   Resolution: Duplicate
Fix Version/s: jax-rs-whiteboard-1.0.2

> Issue with redeployment in Bndtools
> ---
>
> Key: ARIES-1856
> URL: https://issues.apache.org/jira/browse/ARIES-1856
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.1
>Reporter: Timothy Ward
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.2
>
>
> When using Bndtools for development there are many redeploys of the JAX-RS 
> whiteboard bundle (the bundle gets rebuilt on save). For some reason I am 
> seeing an NPE, after which my application is broken until I restart the 
> framework.
> This is happening using the OSGi enRoute 7.0.0 templates.
>  
> java.lang.NullPointerException: null
> at 
> org.apache.aries.jax.rs.whiteboard.internal.utils.ServiceReferenceResourceProvider.getResourceClass(ServiceReferenceResourceProvider.java:56)
> at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProviders(JAXRSServerFactoryBean.java:391)
> at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProvider(JAXRSServerFactoryBean.java:381)
> at 
> org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.rewire(CxfJaxrsServiceRegistrator.java:282)
> at 
> org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.remove(CxfJaxrsServiceRegistrator.java:178)
> at 
> org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.add(CxfJaxrsServiceRegistrator.java:90)
> at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:615)
> at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)
> at org.apache.aries.component.dsl.OSGi.lambda$null$76(OSGi.java:710)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Collections$2.tryAdvance(Collections.java:4717)
> at java.util.Collections$2.forEachRemaining(Collections.java:4725)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at 
> org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42)
> at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)
> at org.apache.aries.component.dsl.OSGi.lambda$map$77(OSGi.java:710)
> at 
> org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)
> at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)
> at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)
> at 
> org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)
> at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)
> at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)
> at 
> org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)
> at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)
> at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)
> at 
> org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)
> at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)
> at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:694)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)
> at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:735)
> at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)
> at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)
> at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Collections$2.tryAdvance(Collections.java:4717)
> at java.util.Collections$2.forEachRemaining(Collections.java:4725)
> at java.util.stream.AbstractPipeline.copyInto(Ab

[jira] [Created] (ARIES-1856) Issue with redeployment in Bndtools

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1856:
---

 Summary: Issue with redeployment in Bndtools
 Key: ARIES-1856
 URL: https://issues.apache.org/jira/browse/ARIES-1856
 Project: Aries
  Issue Type: Bug
  Components: jax-rs-whiteboard
Affects Versions: jax-rs-whiteboard-1.0.1
Reporter: Timothy Ward


When using Bndtools for development there are many redeploys of the JAX-RS 
whiteboard bundle (the bundle gets rebuilt on save). For some reason I am 
seeing an NPE, after which my application is broken until I restart the 
framework.

This is happening using the OSGi enRoute 7.0.0 templates.

 

java.lang.NullPointerException: null

at 
org.apache.aries.jax.rs.whiteboard.internal.utils.ServiceReferenceResourceProvider.getResourceClass(ServiceReferenceResourceProvider.java:56)

at 
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProviders(JAXRSServerFactoryBean.java:391)

at 
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProvider(JAXRSServerFactoryBean.java:381)

at 
org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.rewire(CxfJaxrsServiceRegistrator.java:282)

at 
org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.remove(CxfJaxrsServiceRegistrator.java:178)

at 
org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.add(CxfJaxrsServiceRegistrator.java:90)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:615)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.OSGi.lambda$null$76(OSGi.java:710)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)

at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)

at java.util.Collections$2.tryAdvance(Collections.java:4717)

at java.util.Collections$2.forEachRemaining(Collections.java:4725)

at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)

at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)

at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)

at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)

at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)

at 
org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$map$77(OSGi.java:710)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:694)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:735)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)

at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)

at java.util.Collections$2.tryAdvance(Collections.java:4717)

at java.util.Collections$2.forEachRemaining(Collections.java:4725)

at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)

at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)

at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)

at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)

at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)

at 
org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39

[jira] [Closed] (ARIES-1848) jaxrs whiteboard jar contains SseEventSource.Builder but not the impl

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward closed ARIES-1848.
---
Resolution: Won't Fix

Support for SSE is required by the OSGi JAX-RS whiteboard specification. There 
is an argument that the whiteboard could be separated into server and client 
modules, but the client module would still need to contain the SSE 
implementation to comply with the OSGi spec.

I am also not sure that it would be worth separating the client and server 
features of the whiteboard. It would add deployment complexity, and I'm pretty 
sure it would add bloat as we would end up inlining multiple copies of CXF 
(common code used by server and client).

Note that it is not possible for the JAX-RS whiteboard to use an external CXF 
dependency (i.e. it must be embedded). There are some CXF packages that have 
additional classes added (to customize/extend CXF behaviour) and we could not 
do that as an external module. This was a deliberate implementation decision to 
allow the Aries implementation to be small and easily deployable.

> jaxrs whiteboard jar contains SseEventSource.Builder but not the impl
> -
>
> Key: ARIES-1848
> URL: https://issues.apache.org/jira/browse/ARIES-1848
> Project: Aries
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> org.apache.aries.jax.rs.whiteboard-1.0.1.jar!/META-INF/services/javax.ws.rs.sse.SseEventSource.Builder
>  shouldn't be part of aries jaxrs whiteboard packaging since the impl is not 
> provided and is optional for cxf



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Aries Remote Service Admin 1.13.0 (OSGi R7)

[Timothy Ward]

+1

> On 1 Oct 2018, at 22:27, Carlos Sierra Andrés  wrote:
> 
> +1
> 
> Thanks.
> 
> Carlos.
> 
> 
> El 1/10/18 a las 11:40, Christian Schneider escribió:
>> This release fixes some bugs that were reported by users and found during
>> stabilization of the OSGi R7 CT checks.
>> 
>> See here for the specs we implement:
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
>> 
>> Keep in mind though that at the moment only the TCP transport fully
>> supports the new spec.
>> 
>> I've staged the release at
>> 
>> https://repository.apache.org/content/repositories/orgapachearies-1145
>> 
>> For a list of issues resolved see:
>> 
>> https://issues.apache.org/jira/projects/ARIES/versions/12342751
>> 
>> 
>> Release Notes - Aries - Version rsa-1.13.0
>> 
>> ** Bug
>>* [ARIES-1751] - Typo in namespace url in
>> OSGI-INF/metatype/zookeeper.xml
>>* [ARIES-1788] - NPE on log line
>>* [ARIES-1815] - ConcurrentModificationException in
>> TopologyManagerImport.unImportForGoneEndpoints
>>* [ARIES-1817] - Export remove do no always end up in REMOVE events
>> (timing issue)
>>* [ARIES-1837] - ConcurrentModificationException in
>> InterestManager.endpointChanged
>>* [ARIES-1838] - Zookeeper discovery does not send modified events
>>* [ARIES-1839] - Invalid zookeeper path
>> /osgi/service_registry#osgi#service_registry is created
>>* [ARIES-1840] - ConcurrentModificationException in
>> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.importServices
>> 
>> ** Test
>>* [ARIES-1835] - TestFastbinRoundTrip fails in a high percentage of the
>> builds
>> 
>> ** Dependency upgrade
>>* [ARIES-1779] - Upgrade ZooKeeper to 3.4.13
>>* [ARIES-1822] - Upgrade plugins
>> 
>> 
>> Please review and vote
>> 
>> Here is my
>> +1
>> 
>> Christian
>> 
> 

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.1

[Timothy Ward]

+1

> On 25 Sep 2018, at 11:33, Carlos Sierra Andrés  wrote:
> 
> Hello all,
> 
> I have staged a release 1.0.1 for Aries JAX-RS Whiteboard. It brings bug
> fixes and a new optional feature to prepend paths to all applications
> inside a whiteboard.
> 
> The module is tagged at
> https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=refs/tags/org.apache.aries.jax.rs-1.0.1
> 
> Artifacts are in one staged repo,
> https://repository.apache.org/content/repositories/orgapachearies-1144
> 
> Instructions for verifying the release are at
> http://aries.apache.org/development/verifyingrelease.html. Alternately,
> cut and paste the following to run a full check:
> 
> -
> 
> wget --no-check-certificate
> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
> chmod a+x verify_staged_release.sh
> ./verify_staged_release.sh 1144 mytempdirectory 2>&1 | tee verifyresults.txt
> grep FAIL verifyresults.txt
> grep ERROR verifyresults.txt
> 
> -
> 
> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
> 
> Here is my +1.
> 
> Thanks to all,
> 
> Carlos.
> 

[jira] [Commented] (ARIES-1824) Add missing `osgi.jaxrs.media.type` properties to extensions

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1824:
-

Moved to a new "integration-jackson" release project as this isn't released as 
part of the whiteboard

> Add missing `osgi.jaxrs.media.type` properties to extensions
> 
>
> Key: ARIES-1824
> URL: https://issues.apache.org/jira/browse/ARIES-1824
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: jax-rs-integration-jackson-1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1824) Add missing `osgi.jaxrs.media.type` properties to extensions

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward updated ARIES-1824:

Fix Version/s: (was: jax-rs-whiteboard-1.0.1)
   jax-rs-integration-jackson-1.0.0

> Add missing `osgi.jaxrs.media.type` properties to extensions
> 
>
> Key: ARIES-1824
> URL: https://issues.apache.org/jira/browse/ARIES-1824
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: jax-rs-integration-jackson-1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1829) FELIX: tx-control-local combined with jdbc-local give me a null java.sql.Connection

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1829:
-

Thank you for the bug report - are you able to share the application as a 
whole, perhaps on GitHub? It would be really useful to see the deployment as a 
whole, because the call to getResource should never return null. If you are 
able to share the project it would be ideal because otherwise we'll be guessing 
about what framework, database and DS versions you might be using.

> FELIX: tx-control-local combined with jdbc-local give me a null 
> java.sql.Connection
> ---
>
> Key: ARIES-1829
> URL: https://issues.apache.org/jira/browse/ARIES-1829
> Project: Aries
>  Issue Type: Question
>  Components: tx-control
>Affects Versions: transaction-jdbc-1.0.0
>Reporter: Andrea Fino
>Priority: Minor
>  Labels: beginner
> Attachments: JDBCTester.java, bundles.PNG, jdbc-local.PNG, 
> transaction-control.PNG
>
>
> Hi all,
> I'm using tx-control-local [version 1.0.0] combined with jdbc-local [version 
> 1.0.0] into apche felix enviroment.
>  
> I have followed all instructions written into Apache Aries tutorial:
>  
>  * Find and install a JDBC Service implementation for your chosen database 
> --> I'm using SQL Server
>  * Create a factory configuration using the factory pid 
> _org.apache.aries.tx.control.jdbc.local_ --> My configuration looks like this:
>  
> {code:java}
> osgi.jdbc.driver.class=com.microsoft.sqlserver.jdbc.SQLServerDriver
> url=jdbc:sqlserver://localhost:1433;databaseName=2017_TEST;user=osgiuser;password=osgiuser;
> dataSourceName=test{code}
>  
> So, in my apache felix enviroment I can see that JDBC Local bundle create a 
> new service under JDBCConnectionProvider interface with all properties shown 
> up. Also Local Transaction control register its own service correctly.
>  
> But here comes problems, when I install my test bundle that perform a simple 
> read query seems that, when it receives JDBCConnectionProvider and try to get 
> SQL Connection through these instructions, it return a null connection:
> {code:java}
>  @Reference()
>  void setProvider(JDBCConnectionProvider provider) {
>conn = provider.getResource(control);
>  }{code}
>  
> So when it tries to create SQLStatement it gave me this error:
>      {color:#FF}*java.lang.NullPointerException*{color}
>  
> I don't know if I have missed some steps, but I can't solve this problem. I 
> report below all checks I have done:
>  
>  * JDBC URL is correct, I was able to connect with a simple Java Program that 
> perform JDBC Connection
>  * User ha all privileges to access to database
>  
> Can someone help me?
> Thanks. 
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Aries Component-DSL 1.2.1

[Timothy Ward]

+1

> On 22 Sep 2018, at 08:28, Christian Schneider  wrote:
> 
> +1
> 
> Christian
> 
> Am Fr., 21. Sep. 2018 um 19:12 Uhr schrieb Carlos Sierra Andrés <
> csie...@apache.org>:
> 
>> Hello all,
>> 
>> I have staged a release 1.2.1 for Aries Component DSL. It brings mostly
>> bug fixes.
>> 
>> The module is tagged at
>> 
>> https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.component-dsl.parent-1.2.1
>> 
>> Artifacts are in one staged repo,
>> https://repository.apache.org/content/repositories/orgapachearies-1143
>> 
>> Instructions for verifying the release are at
>> http://aries.apache.org/development/verifyingrelease.html. Alternately,
>> cut and paste the following to run a full check:
>> 
>> -
>> 
>> wget --no-check-certificate
>> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
>> chmod a+x verify_staged_release.sh
>> ./verify_staged_release.sh 1143 mytempdirectory 2>&1 | tee
>> verifyresults.txt
>> grep FAIL verifyresults.txt
>> grep ERROR verifyresults.txt
>> 
>> -
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Here is my +1.
>> 
>> Thanks to all,
>> 
>> Carlos.
>> 
>> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

[jira] [Created] (ARIES-1825) NullPointerException in the JAX-RS Whiteboard

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1825:
---

 Summary: NullPointerException in the JAX-RS Whiteboard
 Key: ARIES-1825
 URL: https://issues.apache.org/jira/browse/ARIES-1825
 Project: Aries
  Issue Type: Bug
  Components: jax-rs-whiteboard
Affects Versions: 1.0
Reporter: Timothy Ward
 Fix For: 1.0.1


11:06:29.176 [CM Event Dispatcher (Fire ConfigurationEvent: 
pid=org.apache.aries.jax.rs.jackson)] WARN  
o.a.a.j.r.w.i.AriesJaxrsServiceRuntime - Resource CachingServiceReference {

cachedProperties=\{osgi.jaxrs.application.select=(osgi.jaxrs.name=rest-ui), 
osgi.jaxrs.name=Domain Viewer, 
osgi.jaxrs.extension.select=[(osgi.jaxrs.media.type=application/json), 
(osgi.jaxrs.name=aries.shiro.authz)], osgi.jaxrs.whiteboard.target=null 
(cached)}

serviceReference=[com.acme.ui.rest.DomainResource]

} is registered with error

11:06:29.178 [CM Event Dispatcher (Fire ConfigurationEvent: 
pid=org.apache.aries.jax.rs.jackson)] ERROR o.a.a.j.r.w.internal.Whiteboard - 
ServiceReference CachingServiceReference {

cachedProperties=\{osgi.jaxrs.application.select=(osgi.jaxrs.name=rest-ui), 
osgi.jaxrs.name=Domain Viewer, 
osgi.jaxrs.extension.select=[(osgi.jaxrs.media.type=application/json), 
(osgi.jaxrs.name=aries.shiro.authz)], osgi.jaxrs.whiteboard.target=null 
(cached)}

serviceReference=[com.acme.ui.rest.DomainResource]

} for endpoint produced error: {}

java.lang.NullPointerException: null

at 
org.apache.aries.jax.rs.whiteboard.internal.Whiteboard.lambda$null$51(Whiteboard.java:810)

at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:693)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:734)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:617)

at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:617)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)

at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)

at java.util.Collections$2.tryAdvance(Collections.java:4717)

at java.util.Collections$2.forEachRemaining(Collections.java:4725)

at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)

at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)

at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)

at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)

at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)

at 
org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:611)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:611)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:693)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:734)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28)

at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25)

at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)

at java.util.Collections$2.tryAdvance(Collections.java:4717)

at java.util.Collections$2.forEachRemaining(Collections.java:4725)

at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)

at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)

at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)

at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)

at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)

at 
org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$recoverWith$81(OSGi.java:730)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$flatMap$74(OSGi.java:693)

at 
org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39)

at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50)

at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:693

Re: [HEADS UP] Move current git repos to gitbox

[Timothy Ward]

+1

> On 27 Jul 2018, at 13:47, Grzegorz Grzybek  wrote:
> 
> +1
> 
> regards
> Grzegorz Grzybek
> 
> 2018-07-27 14:18 GMT+02:00 Christian Schneider :
> 
>> It seems that our git repos are still on git-wip. I would like to move them
>> to gitbox.
>> This allows us to directly work with the github UI like reviewing, merging
>> and closing PRs.
>> 
>> The current repos we have are:
>> https://github.com/apache/aries-rsa
>> https://github.com/apache/aries-jpa
>> https://github.com/apache/aries-jax-rs-whiteboard
>> https://github.com/apache/aries-containers
>> 
>> This is already on gitbox:
>> https://github.com/apache/aries-tx-control
>> 
>> If no one objects during the next days I will ask infra to move the repos.
>> 
>> Christian
>> 
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Computer Scientist
>> http://www.adobe.com
>> 

Re: [VOTE] Release Aries JAX-RS Whiteboard 1.0.0

[Timothy Ward]

+1

The verification checks all work for me

Tim

> On 26 Jun 2018, at 10:46, Carlos Sierra Andrés  wrote:
> 
> Hello all,
> 
> I have staged a release 1.0.0 for Aries JAX-RS Whiteboard.
> 
> The module is tagged at 
> https://git-wip-us.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;a=tag;h=d33739d7eef06620c7155f0faab3f30f08a5d118
> 
> Artifacts are in one staged repo: 
> https://repository.apache.org/content/repositories/orgapachearies-1139
> 
> Instructions for verifying the release are at 
> http://aries.apache.org/development/verifyingrelease.html. Alternately, cut 
> and paste the following to run a full check:
> 
> -
> 
> wget --no-check-certificate 
> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
> chmod a+x verify_staged_release.sh
> ./verify_staged_release.sh 1139 mytempdirectory 2>&1 | tee verifyresults.txt
> grep FAIL verifyresults.txt
> grep ERROR verifyresults.txt
> 
> -
> 
> There are a couple of RAT warnings in highlight.js and github.css that should 
> be covered in LICENSE file.
> 
> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
> 
> Bests,
> 
> Carlos Sierra.
> 

Re: [VOTE] Release Aries Component-DSL 1.2.0

[Timothy Ward]

I’ve run the verification scripts and rat checks. Everything seems fine

+1 from me (binding)

Tim

> On 22 Jun 2018, at 11:55, Carlos Sierra Andrés  wrote:
> 
> Hello all,
> 
> As discussed in an earlier mail thread, I have staged a release 1.2.0 for 
> Aries Component DSL.
> 
> The module is tagged at 
> https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.component-dsl.parent-1.2.0
> 
> Artifacts are in one staged repo, 
> https://repository.apache.org/content/repositories/orgapachearies-1138
> 
> Instructions for verifying the release are at 
> http://aries.apache.org/development/verifyingrelease.html. Alternately, cut 
> and paste the following to run a full check:
> 
> -
> 
> wget --no-check-certificate 
> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
> chmod a+x verify_staged_release.sh
> ./verify_staged_release.sh 1138 mytempdirectory 2>&1 | tee verifyresults.txt
> grep FAIL verifyresults.txt
> grep ERROR verifyresults.txt
> 
> -
> 
> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
> 
> Thanks to all,
> 
> Carlos.
> 

Re: New release of Aries Component DSL 1.2.0

[Timothy Ward]

Obviously that was meant to be 1.1.1… 

Clearly it’s time to step away from the keyboard for the day!

Tim

> On 19 Jun 2018, at 19:04, Timothy Ward  wrote:
> 
> +1, but I do have one question. Is this actually a 1.2.0, or really just a 
> 1.2.1? If the only changes are bug fixes I would expect to see a micro 
> release.
> 
> Tim
> 
>> On 19 Jun 2018, at 13:55, David Bosschaert  
>> wrote:
>> 
>> +1
>> 
>> David
>> 
>> On Mon, 18 Jun 2018 at 17:06, Carlos Sierra Andrés 
>> wrote:
>> 
>>> Hello all,
>>> 
>>> I would like to make a new release 1.2.0 of Aries Component DSL.
>>> 
>>> Four JIRA tickets have been closed:
>>> 
>>> * ARIES-1810
>>> 
>>> * ARIES-1811
>>> 
>>> * ARIES-1812
>>> 
>>> * ARIES-1813
>>> 
>>> some of which can be considered severe bugs that could prevent usage in
>>> some scenarios.
>>> 
>>> If no one opposes I will open a vote in the next days.
>>> 
>>> Thanks.
>>> 
>>> Carlos.
>>> 
>>> 
>>> 
> 

Re: New release of Aries Component DSL 1.2.0

[Timothy Ward]

+1, but I do have one question. Is this actually a 1.2.0, or really just a 
1.2.1? If the only changes are bug fixes I would expect to see a micro release.

Tim

> On 19 Jun 2018, at 13:55, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On Mon, 18 Jun 2018 at 17:06, Carlos Sierra Andrés 
> wrote:
> 
>> Hello all,
>> 
>> I would like to make a new release 1.2.0 of Aries Component DSL.
>> 
>> Four JIRA tickets have been closed:
>> 
>> * ARIES-1810
>> 
>> * ARIES-1811
>> 
>> * ARIES-1812
>> 
>> * ARIES-1813
>> 
>> some of which can be considered severe bugs that could prevent usage in
>> some scenarios.
>> 
>> If no one opposes I will open a vote in the next days.
>> 
>> Thanks.
>> 
>> Carlos.
>> 
>> 
>> 

Re: recent Aries Proxy overzealous weaving

[Timothy Ward]

> Can we tone it back a little? I'd recommend to make it not weave anything
> by default!

If you did that then proxy would be effectively disabled.

> On 30 May 2018, at 20:51, Raymond Auge  wrote:
> 
> Hello all,
> 
> Does someone know why Proxy is so aggressively weaving by default?
> 
> It seems that the default opt-in is everything (except itself)
> 
> public static final String WEAVING_ENABLED_CLASSES_DEFAULT = "*";
> 
> with the default opt outs being only:
> 
> public static final String WEAVING_DISABLED_CLASSES_DEFAULT =
> "org.objectweb.asm.*,org.slf4j.*,org.apache.log4j.*,javax.*,ch.qos.logback.*";
> 
> this has the tendency to blow stuff up.
> 
> Can we tone it back a little? I'd recommend to make it not weave anything
> by default!
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[VOTE RESULT] Release Aries Tx Control 1.0.0

[Timothy Ward]

The vote passes with 4 binding and 2 non binding votes.

Thanks,

Tim

> On 1 May 2018, at 11:45, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> +1 (binding)
> 
> Christian
> 
> 2018-04-30 19:45 GMT+02:00 Timothy Ward <timothyjw...@apache.org>:
> 
>> As discussed in an earlier mail thread, Aries Tx Control will be the
>> reference implementation for the Transaction Control Service 1.0 from OSGi
>> R7. This marks the first proper release of Tx Control at 1.0.0. I’ve
>> therefore staged a release candidate for the whole Aries Tx Control
>> project. The module is staged and tagged in https://gitbox.apache.org/
>> repos/asf?p=aries-tx-control.git;a=tag;h=refs/tags/1.0.0.
>> 
>> Instructions for verifying the release are at http://aries.apache.org/
>> development/verifyingrelease.html. Alternately, cut and paste the
>> following to run a full check:
>> 
>> wget --no-check-certificate https://svn.apache.org/repos/
>> asf/aries/scripts/verify_staged_release.sh
>> chmod a+x verify_staged_release.sh
>> ./verify_staged_release.sh 1128 mytempdirectory 2>&1 | tee
>> verifyresults.txt
>> grep FAIL verifyresults.txt
>> grep ERROR verifyresults.txt
>> 
>> Artifacts are in one staged repo, https://repository.apache.org/
>> content/repositories/orgapachearies-1128/. The main source zip file for
>> is available at https://repository.apache.org/content/repositories/
>> orgapachearies-1128/org/apache/aries/tx-control/tx-
>> control/1.0.0/tx-control-1.0.0-source-release.zip.
>> 
>> The RAT and IANAL build checks flag errors in the README.md and .gitignore
>> files, but I could see no issues in actual sources or resources.
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Best Regards,
>> 
>> Tim Ward
>> 
> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: [HEADS UP] blueprint-maven-plugin release

[Timothy Ward]

I have no changes for this.

> On 1 May 2018, at 06:28, Jean-Baptiste Onofré  wrote:
> 
> +1, you can go ahead from my side.
> 
> Regards
> JB
> 
> On 04/27/2018 03:32 PM, Dominik Przybysz wrote:
>> Hi
>> I'd like to release the blueprint-maven-plugin (1.10.0).
>> If you have no other changes I'd like to release it in the second week of
>> may.
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Release Aries Component-DSL 1.0.0

[Timothy Ward]

+1

> On 1 May 2018, at 08:44, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On 30 April 2018 at 20:47, Carlos Sierra Andrés 
> wrote:
> 
>> Hello all,
>> 
>> As discussed in an earlier mail thread, Aries Component DSL 1.0 is a
>> dependency for Aries JAX-RS Whiteboard 1.0, which will be the reference
>> implementation for the JAX-RS Whiteboard from OSGi R7.
>> 
>> The module is tagged at
>> https://svn.apache.org/repos/asf/aries/tags/org.apache.
>> aries.component-dsl.parent-1.0.0
>> 
>> Artifacts are in one staged repo,
>> https://repository.apache.org/content/repositories/orgapachearies-1129
>> 
>> Instructions for verifying the release are at
>> http://aries.apache.org/development/verifyingrelease.html. Alternately,
>> cut and paste the following to run a full check:
>> 
>> -
>> 
>> wget --no-check-certificate
>> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
>> chmod a+x verify_staged_release.sh
>> ./verify_staged_release.sh 1129 mytempdirectory 2>&1 | tee
>> verifyresults.txt
>> grep FAIL verifyresults.txt
>> grep ERROR verifyresults.txt
>> 
>> -
>> 
>> The vote will be open for at least 72 hours. [ ] +1 [ ] 0 [ ] -1
>> 
>> Bests,
>> 
>> Carlos Sierra.
>> 
>> 

Re: [VOTE] Release Apache Aries Remote Service Admin 1.12.0 (OSGi R7)

[Timothy Ward]

JB you are correct that this attempt was failing a lot of rat checks. Christian 
fixed and re-staged the release vote in a second thread. I see that you’ve 
voted on that one already. 

Tim

Sent from my iPhone

> On 1 May 2018, at 06:30, Jean-Baptiste Onofré  wrote:
> 
> -1 (binding)
> 
> It seems a lot of files doesn't have ASF header. Can you please take a look ?
> 
> Regards
> JB
> 
>> On 04/27/2018 10:31 AM, Christian Schneider wrote:
>> This release of Aries RSA is the reference implementation of Remote
>> Services and Remote Service Admin from the OSGi R7 spec. It was tested
>> against the TCK and passes all tests.
>> 
>> See here for the specs we implement:
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
>> 
>> Keep in mind though that at the moment only the TCP transport fully
>> supports the new spec.
>> 
>> Some highlights are:
>> 
>>   - Support for async return types like: Future,
>>   CompletableFuture, CompletionStage, Promises
>>   - Can transport all primitive types including the OSGi DTO types
>>   - Zookeeper discovery now creates a lot less nodes and needs only one
>>   listener
>> 
>> I've staged the release at
>> 
>> https://repository.apache.org/content/repositories/orgapachearies-1113/
>> 
>> For a list of issues resolved see:
>> 
>> https://issues.apache.org/jira/projects/ARIES/versions/12341022
>> 
>> 
>> Release Notes - Aries - Version rsa-1.12.0
>> 
>> ** Bug
>>* [ARIES-1759] - Fastbin fails to bind if a configuration exists with
>> the same port
>>* [ARIES-1760] - Primitive type do not work as parameters in TCP
>> transport
>>* [ARIES-1763] - Upgrade capabilities and API for remote service admin
>> 1.1.0 spec
>> 
>> 
>> ** New Feature
>>* [ARIES-1756] - Support osgi.basic.timeout
>>* [ARIES-1757] - Implement osgi.async intent
>>* [ARIES-1758] - Support osgi.basic intent
>>* [ARIES-1764] - Also send events using eventadmin
>> 
>> 
>> ** Improvement
>>* [ARIES-1769] - Make sure services with unsupported intents are not
>> exported
>>* [ARIES-1771] - Support modification events
>>* [ARIES-1774] - Refactor Zookeeper discovery to use only one listener
>> for all zk endpoints
>>* [ARIES-1775] - Remove DiscoveryPlugin
>>* [ARIES-1776] - Fixes for tck secure tests
>>* [ARIES-1778] - Use endpoint id as path in zookeeper
>> 
>> 
>> Please review and vote
>> 
>> Here is my
>> +1
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Release Apache Aries Remote Service Admin 1.12.0 (OSGi R7) take 2

[Timothy Ward]

+1

> On 30 Apr 2018, at 13:46, Christian Schneider  wrote:
> 
> I added the missing license headers and made sure rat runs on all builds.
> ---
> 
> This release of Aries RSA is the reference implementation of Remote
> Services and Remote Service Admin from the OSGi R7 spec. It was tested
> against the TCK and passes all tests.
> 
> See here for the specs we implement:
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.
> html
> 
> Keep in mind though that at the moment only the TCP transport fully
> supports the new spec.
> 
> Some highlights are:
> 
>   - Support for async return types like: Future, CompletableFuture,
> CompletionStage,
>   Promises
>   - Can transport all primitive types including the OSGi DTO types
>   - Zookeeper discovery now creates a lot less nodes and needs only one
>   listener
> 
> I've staged the release at
> 
> https://repository.apache.org/content/repositories/orgapachearies-1127
> 
> For a list of issues resolved see:
> 
> https://issues.apache.org/jira/projects/ARIES/versions/12341022
> 
> 
> Release Notes - Aries - Version rsa-1.12.0
> 
> ** Bug
>* [ARIES-1759] - Fastbin fails to bind if a configuration exists with
> the same port
>* [ARIES-1760] - Primitive type do not work as parameters in TCP
> transport
>* [ARIES-1763] - Upgrade capabilities and API for remote service admin
> 1.1.0 spec
> 
> 
> ** New Feature
>* [ARIES-1756] - Support osgi.basic.timeout
>* [ARIES-1757] - Implement osgi.async intent
>* [ARIES-1758] - Support osgi.basic intent
>* [ARIES-1764] - Also send events using eventadmin
> 
> 
> ** Improvement
>* [ARIES-1769] - Make sure services with unsupported intents are not
> exported
>* [ARIES-1771] - Support modification events
>* [ARIES-1774] - Refactor Zookeeper discovery to use only one listener
> for all zk endpoints
>* [ARIES-1775] - Remove DiscoveryPlugin
>* [ARIES-1776] - Fixes for tck secure tests
>* [ARIES-1778] - Use endpoint id as path in zookeeper
> 
> 
> Please review and vote
> 
> Here is my
> +1
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

[VOTE RESULT] Release Aries JPA 2.7.0

[Timothy Ward]

The release vote passes with 4 binding +1 votes and 2 non binding +1 votes.

Thanks,

Tim

Re: [VOTE] Release Apache Aries Remote Service Admin 1.12.0 (OSGi R7)

[Timothy Ward]

I think that the bnd files need headers too. They include non-trivial 
information describing how the bundles should be packaged.

The files are just properties files so they support comments. For example 
https://github.com/apache/aries-jpa/blob/master/jpa-container/osgi.bnd#L1-L16

Tim

On 29 Apr 2018, at 13:31, Christian Schneider 
<ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote:

I did not specifically run rat tests. To be honest I thought they were part
of the apache parent so I did not check.

I added rat checks to the build on master now and fixed the reported files.
Can you review this?

Christian

2018-04-29 11:56 GMT+02:00 Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>>:

Hi Christian,

Did you run RAT checks on this before you staged it? I am seeing the
following, which includes a lot of source files with no license headers.
All the pom files, bnd files, xsd files, and definitely the .java files
should have ASL v2 headers. Some of these are long-standing files, so
they’ve clearly been released several times without headers.

This is the output I see:

./repository/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/repository/pom.xml
./itests/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/itests/tck/install/install-tests.sh
./itests/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/itests/tck/tck.bndrun
./itests/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/itests/tck/README.md
./target/rat.txt: !? DEPENDENCIES
./target/rat.txt: !? Readme.md
./eapub/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/eapub/pom.xml
./eapub/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/eapub/Readme.md
./eapub/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/eapub/bnd.bnd
./rsa/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/rsa/pom.xml
./rsa/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/rsa/Readme.md
./rsa/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/rsa/bnd.bnd
./rsa/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/rsa/src/main/java/org/
apache/aries/rsa/core/event/EventAdminSender.java
./features/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/features/src/main/resources/features.xml
./discovery/config/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/config/Readme.md
./discovery/config/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/config/bnd.bnd
./discovery/zookeeper/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/Readme.md
./discovery/zookeeper/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/bnd.bnd
./discovery/zookeeper/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/
test/java/org/apache/aries/rsa/discovery/zookeeper/repository/
ZookeeperEndpointRepositoryTest.java
./discovery/zookeeper/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/
test/java/org/apache/aries/rsa/discovery/zookeeper/
ZookeeperDiscoveryTest.java
./discovery/zookeeper/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/
main/java/org/apache/aries/rsa/discovery/zookeeper/repository/
ZookeeperEndpointRepository.java
./discovery/local/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/mytempdirectory/1126-unzips/
org.apache.aries.rsa.main-1.12.0/discovery/local/Readme.md
./discovery/local/target/rat.txt: !? /Users/timothyjward/
development/apache/verify/myt

Re: [VOTE] Release Apache Aries Remote Service Admin 1.12.0 (OSGi R7)

[Timothy Ward]

Hi Christian,

Did you run RAT checks on this before you staged it? I am seeing the following, 
which includes a lot of source files with no license headers. All the pom 
files, bnd files, xsd files, and definitely the .java files should have ASL v2 
headers. Some of these are long-standing files, so they’ve clearly been 
released several times without headers.

This is the output I see:

./repository/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/repository/pom.xml
./itests/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/itests/tck/install/install-tests.sh
./itests/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/itests/tck/tck.bndrun
./itests/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/itests/tck/README.md
./target/rat.txt: !? DEPENDENCIES
./target/rat.txt: !? Readme.md
./eapub/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/eapub/pom.xml
./eapub/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/eapub/Readme.md
./eapub/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/eapub/bnd.bnd
./rsa/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/rsa/pom.xml
./rsa/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/rsa/Readme.md
./rsa/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/rsa/bnd.bnd
./rsa/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/rsa/src/main/java/org/apache/aries/rsa/core/event/EventAdminSender.java
./features/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/features/src/main/resources/features.xml
./discovery/config/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/config/Readme.md
./discovery/config/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/config/bnd.bnd
./discovery/zookeeper/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/Readme.md
./discovery/zookeeper/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/bnd.bnd
./discovery/zookeeper/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/test/java/org/apache/aries/rsa/discovery/zookeeper/repository/ZookeeperEndpointRepositoryTest.java
./discovery/zookeeper/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/test/java/org/apache/aries/rsa/discovery/zookeeper/ZookeeperDiscoveryTest.java
./discovery/zookeeper/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/zookeeper/src/main/java/org/apache/aries/rsa/discovery/zookeeper/repository/ZookeeperEndpointRepository.java
./discovery/local/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/local/Readme.md
./discovery/local/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/local/bnd.bnd
./discovery/local/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/local/src/test/resources/ed2.xml
./discovery/local/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/local/src/test/resources/ed2-generated.xml
./discovery/local/target/rat.txt: !? 
/Users/timothyjward/development/apache/verify/mytempdirectory/1126-unzips/org.apache.aries.rsa.main-1.12.0/discovery/local/src/main/resources/endpoint-description.xsd
./discovery/command/target/rat.txt: !? 

[VOTE] Release Aries JPA 2.7.0

[Timothy Ward]

As discussed in an earlier mail thread, Aries JPA will be the reference 
implementation for the JPA Service 1.1 from OSGi R7. This requires a release of 
the Aries JPA container, but the whole project has moved to Git and started 
using the OSGi contract namespace since its previous release. I’ve therefore 
staged a release candidate for the whole Aries JPA project. The module is 
staged and tagged in 
https://git-wip-us.apache.org/repos/asf?p=aries-jpa.git;a=tag;h=refs/tags/2.7.0.

Instructions for verifying the release are at 
http://aries.apache.org/development/verifyingrelease.html. Alternately, cut and 
paste the following to run a full check:

wget --no-check-certificate 
https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh
chmod a+x verify_staged_release.sh
./verify_staged_release.sh 1125 mytempdirectory 2>&1 | tee verifyresults.txt
grep FAIL verifyresults.txt
grep ERROR verifyresults.txt

Artifacts are in one staged repo, 
https://repository.apache.org/content/repositories/orgapachearies-1125/. The 
main source zip file for is available at 
https://repository.apache.org/content/repositories/orgapachearies-1125/org/apache/aries/jpa/org.apache.aries.jpa.main/2.7.0/org.apache.aries.jpa.main-2.7.0-source-release.zip.

The RAT and IANAL build checks flag errors in the README.md and .gitignore 
files, but I could see no issues in actual sources or resources.

The vote will be open for at least 72 hours, but as that takes us into a 
weekend I will leave it open until at least midday UTC on Monday 30th. [ ] +1 [ 
] 0 [ ] -1

Re: OSGi R7 releases

[Timothy Ward]

This page helps a lot http://aries.apache.org/development/releasingaries.html!

The first thing to do is to get your GPG signing key generated and added to the 
Aries release keys. While that’s happening you can run the rat checks and fix 
up any legal issues (basically just missing licence headers). When both of 
those things are done you can prepare and stage the release. Then do the vote, 
then promote the release.

Not too challenging really :)

Tim

On 25 Apr 2018, at 11:05, Carlos Sierra Andrés 
<carlos.sie...@liferay.com<mailto:carlos.sie...@liferay.com>> wrote:


Hi...

I will take on the release of Aries JAX-RS Whiteboard. I can use all the help I 
can get since I haven't done this before.

Cheers.

Carlos.

El 25/4/18 a las 10:08, Timothy Ward escribió:

Hi all,

The OSGi R7 specifications and API jars are now official.  I know of at least 
four Aries components that are due to be reference implementations for these 
specifications - Aries JPA, Aries Tx Control, Aries RSA and Aries JAX-RS 
whiteboard.

There are only about six weeks now until released versions of these Reference 
Implementations need to be available, thankfully they’re all passing the 
relevant CT suites already. There are dependency chains between some of the 
reference implementations so I’m proposing to start the release processes now 
rather than having to do things in a mad panic next month.

I’m happy to drive the Aries JPA and Aries Tx Control releases. I imagine that 
Christian Schneider and Carlos Sierra will want to take on the releases for 
Aries RSA.

If anyone knows of any showstopper problems then now would be a good time to 
speak up!

Best Regards,

Tim

--
Carlos Sierra
Core Engineer
Liferay España y Portugal / Liferay Spain and Portugal
Tel. +34 917336343
www.liferay.com<http://www.liferay.com/>


Enterprise. Open Source. For Life.

Visit Us: www.liferay.com<http://www.liferay.com/>  |  Like Us: 
facebook.com/liferay<http://facebook.com/liferay>  |  Follow Us: 
twitter.com/liferay_es<http://twitter.com/liferay>

AVISO DE CONFIDENCIALIDAD: “La información contenida en este mensaje y/o 
archivo(s) adjunto(s), enviada desde LIFERAY SL, es confidencial/privilegiada y 
está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. 
Le recordamos que sus datos han sido incorporados en un fichero y que siempre y 
cuando se cumplan los requisitos exigidos por la normativa, podrá ejercer los 
derechos de acceso, rectificación, cancelación y oposición, ante nuestra 
entidad.
Si usted lee este mensaje y no es el destinatario señalado, el empleado o el 
agente responsable de entregar el mensaje al destinatario, o ha recibido esta 
comunicación por error, le informamos que está totalmente prohibida, y puede 
ser ilegal, cualquier divulgación, distribución o reproducción de esta 
comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva 
el mensaje original a la dirección arriba mencionada. Gracias.”
"The information contained in this message and any attached file(s) sent by 
Liferay SL is confidential / privileged and intended solely for the 
addressee(s). If you are not the intended recipient, any form of disclosure, 
reproduction, distribution or any action taken or refrained from in reliance on 
it, is prohibited and may be unlawful. Please notify the sender immediately and 
destroy this e-mail. Thank you."

[jira] [Updated] (ARIES-1777) need to add aries-blueprint as a dependency to jpa feature

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward updated ARIES-1777:

Fix Version/s: (was: jpa-2.7.0)
   jpa-2.8.0

> need to add aries-blueprint as a dependency to jpa feature
> --
>
> Key: ARIES-1777
> URL: https://issues.apache.org/jira/browse/ARIES-1777
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.6.1
>Reporter: AmirMohammad Vosough
>Priority: Major
>  Labels: easyfix
> Fix For: jpa-2.8.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When working on Vaseline framework, I faced this problem:
> After using karaf-assembly I found out I can not have jpa as a startup 
> feature.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

OSGi R7 releases

[Timothy Ward]

Hi all,

The OSGi R7 specifications and API jars are now official.  I know of at least 
four Aries components that are due to be reference implementations for these 
specifications - Aries JPA, Aries Tx Control, Aries RSA and Aries JAX-RS 
whiteboard.

There are only about six weeks now until released versions of these Reference 
Implementations need to be available, thankfully they’re all passing the 
relevant CT suites already. There are dependency chains between some of the 
reference implementations so I’m proposing to start the release processes now 
rather than having to do things in a mad panic next month.

I’m happy to drive the Aries JPA and Aries Tx Control releases. I imagine that 
Christian Schneider and Carlos Sierra will want to take on the releases for 
Aries RSA.

If anyone knows of any showstopper problems then now would be a good time to 
speak up!

Best Regards,

Tim

Re: ARIES-1783 TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[Timothy Ward]

Hi,

I’m afraid that the answer to this is non-trivial.

Section 3.3 of the JPA specification indicates that In the case of a 
Transaction scoped persistence context you should be getting a new entity 
manager instance in the new transaction (i.e. not calling joinTransaction). 

In the case of an extended scope persistence context then it should join the 
current transaction if the entity manager is not already joined to the current 
transaction

Regards,

Tim

> On 15 Mar 2018, at 16:26, Daniel Estermann  wrote:
> 
> Hi everybody,
> 
> I write to this mailing list because I reported ARIES-1783
>  and also tried to
> investigate why the exception occurs.
> 
> Both in our productive environment as well as in the integration tests (for
> which I created a test in my pull request
> ) I came to the same
> conclusion: In the subject case the exception occurs, because the join
> status of the transaction is NOT_JOINED. I discovered it by looking at
> TransactionCoordinatorImpl#isTransactionInProgress()
> ,
> which returns false.
> 
> What seems to help is to call joinTransaction() on the EntityManager in the
> beginning of a method annotated with REQUIRES_NEW. However I can't tell if
> that would be a proper fix. It feels at least not as proper solution.
> 
> I would appreciate any support on that issue.
> 
> Kind Regards
> Daniel

[jira] [Commented] (ARIES-1789) ClientBuilder and SSE

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1789:
-

This code does not seem to be using clientBuilder.newBuilder(). The exception 
stack trace indicates that the failing line is SSEEventSource.target().

 

In any event, when using the JAX-RS whiteboard a ClientBuilder must be obtained 
as an OSGi service from the service registry. The same is true of the 
SSEEventSource (which must be obtained as a factory).

 

The specification describes this process 
[here|[https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e134170]|https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e134170].],
 and the SSEEventSourceFactory is documented [here 
title|[https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.client.SseEventSourceFactory].]

 

Note that the Aries JAX-RS whiteboard does not yet support the SSE features - 
this work is ongoing. [~csierra] can probably tell you more.

> ClientBuilder and SSE
> -
>
> Key: ARIES-1789
> URL: https://issues.apache.org/jira/browse/ARIES-1789
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.0
>Reporter: Stefan Bischof
>Priority: Major
>
> Hi,
> when using:
> clientBuilder.newBuilder();
> i got a
>  
> {code:java}
> java.lang.ClassNotFoundException: 
> org.glassfish.jersey.client.JerseyClientBuilder not found by 
> org.apache.aries.javax.jax.rs-api
> or 
> java.lang.ClassNotFoundException: 
> org.glassfish.jersey.media.sse.internal.JerseySseEventSource$Builder not 
> found by org.apache.aries.javax.jax.rs-api [7]
>     at 
> javax.ws.rs.sse.SseEventSource$Builder.newBuilder(SseEventSource.java:153)
>     at javax.ws.rs.sse.SseEventSource.target(SseEventSource.java:238)
>     at de.jena.servicehub.phone.demo.DemoSseClient.test(DemoSseClient.java:38)
>     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.gogo.runtime.Reflective.invoke(Reflective.java:136)
>     at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:91)
>     at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:571)
>     at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:497)
>     at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:386)
>     at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
>     at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>     at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: 
> org.glassfish.jersey.media.sse.internal.JerseySseEventSource$Builder not 
> found by org.apache.aries.javax.jax.rs-api [7]
>     at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639{code}
>  
> Both builders uses defaultClassNames
>  
> {code:java}
> javax.ws.rs.client.ClientBuilder
> JAXRS_DEFAULT_CLIENT_BUILDER = 
> "org.glassfish.jersey.client.JerseyClientBuilder";
>  
> javax.ws.rs.sse.SseEventSource.Builder
> String JAXRS_DEFAULT_SSE_BUILDER = 
> "org.glassfish.jersey.media.sse.internal.JerseySseEventSource$Builder";
> {code}
> Both calls
> javax.ws.rs.client.FactoryFinder.find(..)
> and tryes to get the Object over
> -ServiceLoader
> -java.home/jaxrs.properties
> -SystemPropertys
> -Class.forName(defaultclassName);
> 1. is there any was to use .newBuilder?
> 2. is ther eny way to @Reference SseEventSource?
> 3. is there any handling of serverside events in Aries Whiteboard or is it 
> necessary to register the SseFeature of(cxf/jersy) by myselfe?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [HEADS UP] Removal of DiscoveryPlugin in Aries RSA zookeeper discovery

[Timothy Ward]

+1 for removing it. I disagreed with it as a solution in the first place - it 
is up to the Topology Manager and RemoteServiceAdmin to generate an 
EndpointDescription. Once it has been generated it should not be “fiddled with” 
by the discovery layer as this could break a lot of things!

Tim

On 7 Feb 2018, at 10:08, Christian Schneider 
> wrote:

I am currently preparing Aries RSA for the OSGi R7 tck tests.

During this work I am also looking into cleaning up old stuff.
I found that the DiscoveryPlugin facility in the zookeeper discovery does not 
seem to work at all.
The properties are changed but never used in writing the endpoint to zookeeper.
So as this was not found until now I doubt anyone is using the DiscoveryPlugin 
services.

I would like to take the opportunity to remove this extensibility point.

Please speak up if you need or use this.

Christian

--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Release Blueprint bundles

[Timothy Ward]

On 6 Feb 2018, at 18:54, Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>> wrote:

2018-02-06 19:30 GMT+01:00 Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>>:

I have run the normal verification checks and found a few problems:

These source files have no licence headers (triggering a RAT failure):

 *   https://github.com/apache/aries/blob/27ef7ecde2bd92b5d798f1374e61a9
f3fd362dff/blueprint/blueprint-cm/src/main/java/
org/apache/aries/blueprint/compendium/cm/ServiceUtil.java


I've just fixed that one, thx for the catch.



 *   All the XSDs in https://github.com/apache/aries/tree/
27ef7ecde2bd92b5d798f1374e61a9f3fd362dff/blueprint/
blueprint-spring-extender/src/main/resources/org.apache.
aries.blueprint.spring.extender


Those are schemas from Spring Source so I was reluctant to add a header to
it.  I can add an ASL2 license header, with a copyright to SpringSource
maybe ?

So these aren’t actually an original contribution? What is the correct 
licensing for these files? To my knowledge we can’t just put an ASL2 header on 
the XSDs if they aren’t already ASL2, and we definitely need something in a 
NOTICES file if we’re including somebody else’s IP. This should definitely 
include where we got the XSDs from and the name of the license we’re consuming 
them under.




Did these not show up in the pre-release checks?


Not really.   I think we should add the rat plugin to the build to avoid
such problems in the future. I've create ARIES-1773
<https://issues.apache.org/jira/browse/ARIES-1773> for that.


I’m not an expert with the rat plugin - can we make sure that this fails the 
build appropriately, and that there are ways to add exclusions?



Regards,

Tim

On 6 Feb 2018, at 06:18, Francois Papon 
<francois.pa...@openobject.fr<mailto:francois.pa...@openobject.fr><
mailto:francois.pa...@openobject.fr>> wrote:

+1 (non-binding)

Thanks Guillaume for the release.

François


Le 05/02/2018 à 19:46, Guillaume Nodet a écrit :
I've staged the following releases:
 Blueprint Parser 1.5.0
 Blueprint Core 1.9.0
 Blueprint CM 1.2.0
 Blueprint Spring 0.6.0
 Blueprint Spring Extender 0.4.0

The staging repo is available at:
https://repository.apache.org/content/repositories/orgapachearies-1124

Please review and vote !

Here's the full log:

9daed4f7a Remove unneeded file

4d3c8d659 [ARIES-1770] Spring schemas can not be validated offline

c76afdc1e [ARIES-1106] Injection to support fluent setter methods

ae4bde3d5 [ARIES-1129] Implement a null proxy element

c9ca94f34 Fix indentation / formatting

f8c5297e4 [ARIES-1138] Fix broken unit test

8088d3832 [ARIES-1098] BeanRecipe.findMatchingMethods does not support
"varargs"

ba817a73b [ARIES-1116] Blueprint loses bounds for 
constructors

29fd4c8c4 [ARIES-1138] Disable Blueprint Schema Validation via System
Property

77128d7de Add constants to the BlueprintConstants interface

610c3b965 [ARIES-1282] BeanRecipe.findMatchingMethods is not able to filter
out overridden method signatures

b42d19d5c [ARIES-1248] Add test for threadpool creation with generics

06d3a60b9 [ARIES-1436] cm:managed-component destroy-method will only be
called when it has a single integer argument

1ddc6292f [ARIES-1544] Blueprint property resolution fails for setters with
derived type

01182e980 [ARIES-1607] Add a flag to enable raw conversion when using
generics

e8c6217d5 [ARIES-960] Improve generics support to support type inference

d1b7347e2 Simplify ExtNamespaceHandler

dc3675240 [ARIES-1668] Support null values inside property-placeholders

597e787df [ARIES-1738] BeanProcessor are not removed when a namespace is
restarted

33811d686 [ARIES-1535][ARIES-1536] Implement new policies for reference
lifecycle and damping

f05631bf5 Fix various versions in poms

60803fca7 [ARIES-1717] Untie Aries Blueprint Spring (extender) to specific
Spring version

81693822a [ARIES-1768] BlueprintDomainCombiner should not be holding a
reference to BundleContext

1d1574030 Use generics for the ServiceTracker in BlueprintEventDispatcher

1f2ba7a65 EventAdmin events should be posted synchronously


Cheers,
Guillaume Nodet






--

Guillaume Nodet

Re: [VOTE] Release Blueprint bundles

[Timothy Ward]

I have run the normal verification checks and found a few problems:

These source files have no licence headers (triggering a RAT failure):

  *   
https://github.com/apache/aries/blob/27ef7ecde2bd92b5d798f1374e61a9f3fd362dff/blueprint/blueprint-cm/src/main/java/org/apache/aries/blueprint/compendium/cm/ServiceUtil.java
  *   All the XSDs in 
https://github.com/apache/aries/tree/27ef7ecde2bd92b5d798f1374e61a9f3fd362dff/blueprint/blueprint-spring-extender/src/main/resources/org.apache.aries.blueprint.spring.extender

Did these not show up in the pre-release checks?

Regards,

Tim

On 6 Feb 2018, at 06:18, Francois Papon 
> wrote:

+1 (non-binding)

Thanks Guillaume for the release.

François


Le 05/02/2018 à 19:46, Guillaume Nodet a écrit :
I've staged the following releases:
  Blueprint Parser 1.5.0
  Blueprint Core 1.9.0
  Blueprint CM 1.2.0
  Blueprint Spring 0.6.0
  Blueprint Spring Extender 0.4.0

The staging repo is available at:
 https://repository.apache.org/content/repositories/orgapachearies-1124

Please review and vote !

Here's the full log:

9daed4f7a Remove unneeded file

4d3c8d659 [ARIES-1770] Spring schemas can not be validated offline

c76afdc1e [ARIES-1106] Injection to support fluent setter methods

ae4bde3d5 [ARIES-1129] Implement a null proxy element

c9ca94f34 Fix indentation / formatting

f8c5297e4 [ARIES-1138] Fix broken unit test

8088d3832 [ARIES-1098] BeanRecipe.findMatchingMethods does not support
"varargs"

ba817a73b [ARIES-1116] Blueprint loses bounds for 
constructors

29fd4c8c4 [ARIES-1138] Disable Blueprint Schema Validation via System
Property

77128d7de Add constants to the BlueprintConstants interface

610c3b965 [ARIES-1282] BeanRecipe.findMatchingMethods is not able to filter
out overridden method signatures

b42d19d5c [ARIES-1248] Add test for threadpool creation with generics

06d3a60b9 [ARIES-1436] cm:managed-component destroy-method will only be
called when it has a single integer argument

1ddc6292f [ARIES-1544] Blueprint property resolution fails for setters with
derived type

01182e980 [ARIES-1607] Add a flag to enable raw conversion when using
generics

e8c6217d5 [ARIES-960] Improve generics support to support type inference

d1b7347e2 Simplify ExtNamespaceHandler

dc3675240 [ARIES-1668] Support null values inside property-placeholders

597e787df [ARIES-1738] BeanProcessor are not removed when a namespace is
restarted

33811d686 [ARIES-1535][ARIES-1536] Implement new policies for reference
lifecycle and damping

f05631bf5 Fix various versions in poms

60803fca7 [ARIES-1717] Untie Aries Blueprint Spring (extender) to specific
Spring version

81693822a [ARIES-1768] BlueprintDomainCombiner should not be holding a
reference to BundleContext

1d1574030 Use generics for the ServiceTracker in BlueprintEventDispatcher

1f2ba7a65 EventAdmin events should be posted synchronously


Cheers,
Guillaume Nodet

Re: Board report

[Timothy Ward]

Aries Transaction Control is moving to its own git repository right now. I’m 
not sure whether that’s something that we track?

Best Regards,

Tim

> On 10 Jan 2018, at 10:50, Jeremy Hughes  wrote:
> 
> Hi all,
> 
> I'll be submitting the January board report today. Please reply with
> anything particular that you feel needs to be included.
> 
> Thanks,
> Jeremy

Re: Aries Spec Jars

[Timothy Ward]

 bundles be updated to make them
usable?


Most of the ServiceMix jars violate the terms of the original license of
the specification artifacts they touch. They also violate the Apache
guidelines for repackaging such artifacts.

I personally didn't have the stomach to repair the ones we needed in that
project so opted to fix them in Aries.

If we could get them fixed then that might be a solution.


Submit a patch!   I can get them applied there easily enough.I’m
completely against having yet another bundle here when the other bundles
are the ones that will be be used by all the other projects.

Dan






- Ray



I really would prefer not getting into a situation where we have a bunch
of project that are commonly used together starting to pull in multiple
versions or implementations of the same bundles.   For example:  CXF uses
and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
which would obviously result in multiple bundles exporting the same
package/versions.

Dan



On Dec 21, 2017, at 9:28 AM, Raymond Auge 
<raymond.a...@liferay.com<mailto:raymond.a...@liferay.com><
mailto:raymond.a...@liferay.com>>
wrote:

Hi Tim,

I was thinking of proposing this very thing over the last few weeks.

I had already deliberately pushed the CDI related spec jars and also the
spec jar for JAX-RS into an aries sub-group in maven in order to better
accommodate and reflect this very thing.

So, I would be a big +1 for having these in a specific sub-project.

- Ray

On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org><
mailto:timothyjw...@apache.org>>
wrote:

Hi all,

I’ve noticed that an increasing number of Aries projects are producing
wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
is a
good thing, as few other Open Source projects package the jars with OSGi
contract metadata.

I do wonder, however, if these spec jars should be provided by a
separate
Aries project, rather than scattered across multiple other projects. I
have
two main reasons for this.

1. It makes the code for packaging the spec jars harder to find in
source
control

2. It creates some non-obvious links between projects. It’s clear why
tx-control depends on JPA, but not why JAX-RS depends on CDI!

The spec jars are mostly being put into a separate Maven group already.
I
would simply see this as a formalisation of that earlier decision.

Thoughts?

Tim

Sent from my iPhone




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)

--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org><mailto:dk...@apache.org> - 
http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)

--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org><mailto:dk...@apache.org> - 
http://dankulp.com/blog
Talend Community Coder - http://coders.talend.comhttp://coders.talend.com/>>


--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>

[jira] [Comment Edited] (ARIES-1767) TransactionControl and transaction isolation among threads

[Timothy Ward (JIRA)]

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

Timothy Ward edited comment on ARIES-1767 at 1/2/18 1:39 PM:
-

In order for your data access to be transactional you need your database 
connection to be a transactional resource. At the moment your database 
connections aren't participating in the transaction at all, hence you see no 
isolation.

To have your database connections participate in the transaction you need to 
inject a JdbcConnectionProvider or JdbcConnectionProviderFactory and use it to 
create a transactional connection. There is an example of this in the [Aries Tx 
Control 
documentation|http://aries.apache.org/modules/tx-control/localJDBC.html#declarative-services-example].




was (Author: timothyjward):
In order for your data access to be transactional you need your database 
connection to be a transactional resource. At the moment your database 
connections aren't participating in the transaction at all, hence you see no 
isolation.

To have your database connections participate in the transaction you need to 
inject a JdbcResourceProvider or JdbcResourceProviderFactory and use it to 
create a transactional connection. There is an example of this in the [Aries Tx 
Control 
documentation|http://aries.apache.org/modules/tx-control/localJDBC.html#declarative-services-example].



> TransactionControl and transaction isolation among threads
> --
>
> Key: ARIES-1767
> URL: https://issues.apache.org/jira/browse/ARIES-1767
> Project: Aries
>  Issue Type: Bug
>  Components: tx-control
>Affects Versions: tx-control-0.0.3
> Environment: Karaf 4.2.0.M1, MySql Community Server 5.6.19, Windows 10
>Reporter: Piergiuseppe Spinelli
> Attachments: TestTXCommand.java
>
>
> Hi,
> I'm evaluating the usage of some enterprise features with Karaf.
> I wrote a test shell command (attached) in order to check the behavior of 
> TransactionControl in a multi-threaded environment. 
> I read tx-control is Thread Safe, so I wrote the command code for check 
> isolation of new transactions created for different threads starting by the 
> same injected TransactionControl service.
> Now, it is not working as it was intended to. Maybe for my misunderstanding 
> about its usage.
> However:
> - I use this simple table:
> CREATE TABLE `long_term_stata` (
>   `ID` bigint(20) NOT NULL AUTO_INCREMENT,
>   `VERSION` bigint(20) DEFAULT NULL,
>   `STATUS` varchar(255) NOT NULL,
>   `PROCESSO` varchar(255) NOT NULL,
>   `TARGET` varchar(255) NOT NULL,
>   `NOTE` varchar(255) DEFAULT NULL,
>   `EXTRA_INFO` longblob,
>   PRIMARY KEY (`ID`),
>   UNIQUE KEY `PROCESSO_UNIQUE` (`PROCESSO`)
> ) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;
> The command runs N thread performing in a new transaction a "select ... for 
> update" on the same row, a read of a status, its increment and at the and an 
> updateRow.
> I believed the first Thread kept a row write lock and the other ones waited 
> each one to acquire the row lock until the end of their own transaction. So 
> at the end the counter in the STATUS field of the table should have been 
> equals to N (the number of threads).
> Instead the threads seem to be executed in parallel randomically so that the 
> order of read & write operations is not respected, ending with a STATUS < N.
> If I set the ROW LOCK from another client is seems to work as waited. In 
> MySqlWorkbench:
> start transaction;
> SELECT * FROM long_term_stata where id=19 for update;
> The command waits trying to acquire the row lock until I type a COMMIT in the 
> workbench.
> So, my conclusion (but easily I made some mistake) is that the transaction 
> isolation does not work properly among threads starting transactions from the 
> same instance of injected TransactionControl.
> Could you help me confirming if it is a strange behavior or advising for the 
> right way to write the test?
> Thanks in advance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (ARIES-1767) TransactionControl and transaction isolation among threads

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1767.
-
Resolution: Invalid

In order for your data access to be transactional you need your database 
connection to be a transactional resource. At the moment your database 
connections aren't participating in the transaction at all, hence you see no 
isolation.

To have your database connections participate in the transaction you need to 
inject a JdbcResourceProvider or JdbcResourceProviderFactory and use it to 
create a transactional connection. There is an example of this in the [Aries Tx 
Control 
documentation|http://aries.apache.org/modules/tx-control/localJDBC.html#declarative-services-example].



> TransactionControl and transaction isolation among threads
> --
>
> Key: ARIES-1767
> URL: https://issues.apache.org/jira/browse/ARIES-1767
> Project: Aries
>  Issue Type: Bug
>  Components: tx-control
>Affects Versions: tx-control-0.0.3
> Environment: Karaf 4.2.0.M1, MySql Community Server 5.6.19, Windows 10
>Reporter: Piergiuseppe Spinelli
> Attachments: TestTXCommand.java
>
>
> Hi,
> I'm evaluating the usage of some enterprise features with Karaf.
> I wrote a test shell command (attached) in order to check the behavior of 
> TransactionControl in a multi-threaded environment. 
> I read tx-control is Thread Safe, so I wrote the command code for check 
> isolation of new transactions created for different threads starting by the 
> same injected TransactionControl service.
> Now, it is not working as it was intended to. Maybe for my misunderstanding 
> about its usage.
> However:
> - I use this simple table:
> CREATE TABLE `long_term_stata` (
>   `ID` bigint(20) NOT NULL AUTO_INCREMENT,
>   `VERSION` bigint(20) DEFAULT NULL,
>   `STATUS` varchar(255) NOT NULL,
>   `PROCESSO` varchar(255) NOT NULL,
>   `TARGET` varchar(255) NOT NULL,
>   `NOTE` varchar(255) DEFAULT NULL,
>   `EXTRA_INFO` longblob,
>   PRIMARY KEY (`ID`),
>   UNIQUE KEY `PROCESSO_UNIQUE` (`PROCESSO`)
> ) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;
> The command runs N thread performing in a new transaction a "select ... for 
> update" on the same row, a read of a status, its increment and at the and an 
> updateRow.
> I believed the first Thread kept a row write lock and the other ones waited 
> each one to acquire the row lock until the end of their own transaction. So 
> at the end the counter in the STATUS field of the table should have been 
> equals to N (the number of threads).
> Instead the threads seem to be executed in parallel randomically so that the 
> order of read & write operations is not respected, ending with a STATUS < N.
> If I set the ROW LOCK from another client is seems to work as waited. In 
> MySqlWorkbench:
> start transaction;
> SELECT * FROM long_term_stata where id=19 for update;
> The command waits trying to acquire the row lock until I type a COMMIT in the 
> workbench.
> So, my conclusion (but easily I made some mistake) is that the transaction 
> isolation does not work properly among threads starting transactions from the 
> same instance of injected TransactionControl.
> Could you help me confirming if it is a strange behavior or advising for the 
> right way to write the test?
> Thanks in advance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Aries Spec Jars

[Timothy Ward]

My mail client appears to have messed up the indenting, sorry about that. I 
hope that people can still make sense of the previous mail.

Tim

> On 22 Dec 2017, at 09:14, Timothy Ward <timothyjw...@apache.org> wrote:
> 
> I’m completely against having yet another bundle here when the other bundles 
> are the ones that will be be used by all the other projects.
> 
> Well we already do have working spec bundles here at Aries (and have had for 
> quite some time), so is your proposal to remove them?
> 
> That’s fine as a proposal, but there are a *lot* of fixes needed in 
> ServiceMix before the bundles are usable. None of the bundles offer (as far 
> as I can tell) offer the correct contract capability (or even any contract at 
> all), and they all seem to include a custom locator which isn’t part of the 
> original specification jar. This locator will have unknown effects on 
> specification implementations and may need to be removed. Are the ServiceMix 
> team really going to be ok with changes that radical, particularly when they 
> affect existing released artifacts?
> 
> As Ray points out the licensing also needs to be fixed before any of the 
> bundles can be used in an OSGi reference implementation (which affects at 
> least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The 
> reference implementations also need to be ready for the R7 release in the 
> next month or so. My original suggestion was a simple movement of the 
> existing bundles, do we have a different solution that’s workable in that 
> time-frame?
> 
> Regards,
> 
> Tim
> 
> On 21 Dec 2017, at 18:16, Daniel Kulp 
> <dk...@apache.org<mailto:dk...@apache.org>> wrote:
> 
> 
> 
> On Dec 21, 2017, at 1:00 PM, Raymond Auge 
> <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote:
> 
> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp 
> <dk...@apache.org<mailto:dk...@apache.org>> wrote:
> 
> Can I ask why the spec/api bundles that are provided by ServiceMix are not
> usable?   Could the ServiceMix api bundles be updated to make them usable?
> 
> 
> Most of the ServiceMix jars violate the terms of the original license of
> the specification artifacts they touch. They also violate the Apache
> guidelines for repackaging such artifacts.
> 
> I personally didn't have the stomach to repair the ones we needed in that
> project so opted to fix them in Aries.
> 
> If we could get them fixed then that might be a solution.
> 
> 
> Submit a patch!   I can get them applied there easily enough.I’m 
> completely against having yet another bundle here when the other bundles are 
> the ones that will be be used by all the other projects.
> 
> Dan
> 
> 
> 
> 
> 
> 
> - Ray
> 
> 
> 
> I really would prefer not getting into a situation where we have a bunch
> of project that are commonly used together starting to pull in multiple
> versions or implementations of the same bundles.   For example:  CXF uses
> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> which would obviously result in multiple bundles exporting the same
> package/versions.
> 
> Dan
> 
> 
> 
> On Dec 21, 2017, at 9:28 AM, Raymond Auge 
> <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>>
> wrote:
> 
> Hi Tim,
> 
> I was thinking of proposing this very thing over the last few weeks.
> 
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
> 
> So, I would be a big +1 for having these in a specific sub-project.
> 
> - Ray
> 
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward 
> <timothyjw...@apache.org<mailto:timothyjw...@apache.org>>
> wrote:
> 
> Hi all,
> 
> I’ve noticed that an increasing number of Aries projects are producing
> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> is a
> good thing, as few other Open Source projects package the jars with OSGi
> contract metadata.
> 
> I do wonder, however, if these spec jars should be provided by a
> separate
> Aries project, rather than scattered across multiple other projects. I
> have
> two main reasons for this.
> 
> 1. It makes the code for packaging the spec jars harder to find in
> source
> control
> 
> 2. It creates some non-obvious links between projects. It’s clear why
> tx-control depends on JPA, but not why JAX-RS depends on CDI!
> 
> The spec jars are mostly being put into a separate Maven group already.
> I
> would simply see this as a formalisation of that earlier decisi

Re: Aries Spec Jars

[Timothy Ward]

I’m completely against having yet another bundle here when the other bundles 
are the ones that will be be used by all the other projects.

Well we already do have working spec bundles here at Aries (and have had for 
quite some time), so is your proposal to remove them?

That’s fine as a proposal, but there are a *lot* of fixes needed in ServiceMix 
before the bundles are usable. None of the bundles offer (as far as I can tell) 
offer the correct contract capability (or even any contract at all), and they 
all seem to include a custom locator which isn’t part of the original 
specification jar. This locator will have unknown effects on specification 
implementations and may need to be removed. Are the ServiceMix team really 
going to be ok with changes that radical, particularly when they affect 
existing released artifacts?

As Ray points out the licensing also needs to be fixed before any of the 
bundles can be used in an OSGi reference implementation (which affects at least 
Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The 
reference implementations also need to be ready for the R7 release in the next 
month or so. My original suggestion was a simple movement of the existing 
bundles, do we have a different solution that’s workable in that time-frame?

Regards,

Tim

On 21 Dec 2017, at 18:16, Daniel Kulp 
<dk...@apache.org<mailto:dk...@apache.org>> wrote:



On Dec 21, 2017, at 1:00 PM, Raymond Auge 
<raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote:

On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp 
<dk...@apache.org<mailto:dk...@apache.org>> wrote:

Can I ask why the spec/api bundles that are provided by ServiceMix are not
usable?   Could the ServiceMix api bundles be updated to make them usable?


Most of the ServiceMix jars violate the terms of the original license of
the specification artifacts they touch. They also violate the Apache
guidelines for repackaging such artifacts.

I personally didn't have the stomach to repair the ones we needed in that
project so opted to fix them in Aries.

If we could get them fixed then that might be a solution.


Submit a patch!   I can get them applied there easily enough.I’m completely 
against having yet another bundle here when the other bundles are the ones that 
will be be used by all the other projects.

Dan






- Ray



I really would prefer not getting into a situation where we have a bunch
of project that are commonly used together starting to pull in multiple
versions or implementations of the same bundles.   For example:  CXF uses
and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
which would obviously result in multiple bundles exporting the same
package/versions.

Dan



On Dec 21, 2017, at 9:28 AM, Raymond Auge 
<raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>>
wrote:

Hi Tim,

I was thinking of proposing this very thing over the last few weeks.

I had already deliberately pushed the CDI related spec jars and also the
spec jar for JAX-RS into an aries sub-group in maven in order to better
accommodate and reflect this very thing.

So, I would be a big +1 for having these in a specific sub-project.

- Ray

On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>>
wrote:

Hi all,

I’ve noticed that an increasing number of Aries projects are producing
wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
is a
good thing, as few other Open Source projects package the jars with OSGi
contract metadata.

I do wonder, however, if these spec jars should be provided by a
separate
Aries project, rather than scattered across multiple other projects. I
have
two main reasons for this.

1. It makes the code for packaging the spec jars harder to find in
source
control

2. It creates some non-obvious links between projects. It’s clear why
tx-control depends on JPA, but not why JAX-RS depends on CDI!

The spec jars are mostly being put into a separate Maven group already.
I
would simply see this as a formalisation of that earlier decision.

Thoughts?

Tim

Sent from my iPhone




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)

--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com




--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

--
Daniel Kulp
dk...@apache.org<mailto:dk...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>

Aries Spec Jars

[Timothy Ward]

Hi all,

I’ve noticed that an increasing number of Aries projects are producing wrapped 
spec jars (JPA, JAX-RS, CDI...). In general I think that this is a good thing, 
as few other Open Source projects package the jars with OSGi contract metadata.

I do wonder, however, if these spec jars should be provided by a separate Aries 
project, rather than scattered across multiple other projects. I have two main 
reasons for this.

1. It makes the code for packaging the spec jars harder to find in source 
control

2. It creates some non-obvious links between projects. It’s clear why 
tx-control depends on JPA, but not why JAX-RS depends on CDI!

The spec jars are mostly being put into a separate Maven group already. I would 
simply see this as a formalisation of that earlier decision. 

Thoughts?

Tim

Sent from my iPhone

Re: Moving Transaction Control into Git

[Timothy Ward]

I think I’ve left long enough for any objectors to see this. The response has 
been 100% positive so I’ll get going with the move today. Thanks all!

Tim 

Sent from my iPhone

> On 18 Dec 2017, at 16:15, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> +1
> 
> Christian
> 
> Am 18.12.2017 13:03 schrieb "Timothy Ward" <timothyjw...@hotmail.com>:
> 
>> Hi all,
>> 
>> The Aries Transaction Control implementation has quite a few pieces, and
>> is already substantially separated from the rest of the Aries build. This
>> is for two main reasons:
>> 
>> 
>>  1.  The Transaction Control implementation makes heavy use of Java 8,
>> which is much newer than required by the rest of Aries
>>  2.  The Transaction Control project has been implemented using maven
>> plugins from the bnd team, not Felix, so the parent pom is more or less
>> totally separate from the rest of the Aries build
>> 
>> Given the existing separation, and the general goodness of git (as
>> compared to svn) I would like to move Aries Transaction Control into its
>> own Git repo. This has already been done for Aries RSA, Aries JPA and Aries
>> JAX-RS whiteboard, and I was just going to go ahead with it, but I then
>> realised that I should probably sound out the rest of Aries dev, even if
>> it’s just a check that nobody else is actively working on it at the moment!
>> 
>> The proposed git repository name would be aries-tx-control.git (to fit in
>> line with other Aries projects in git).
>> 
>> Tim
>> 

Moving Transaction Control into Git

[Timothy Ward]

Hi all,

The Aries Transaction Control implementation has quite a few pieces, and is 
already substantially separated from the rest of the Aries build. This is for 
two main reasons:


  1.  The Transaction Control implementation makes heavy use of Java 8, which 
is much newer than required by the rest of Aries
  2.  The Transaction Control project has been implemented using maven plugins 
from the bnd team, not Felix, so the parent pom is more or less totally 
separate from the rest of the Aries build

Given the existing separation, and the general goodness of git (as compared to 
svn) I would like to move Aries Transaction Control into its own Git repo. This 
has already been done for Aries RSA, Aries JPA and Aries JAX-RS whiteboard, and 
I was just going to go ahead with it, but I then realised that I should 
probably sound out the rest of Aries dev, even if it’s just a check that nobody 
else is actively working on it at the moment!

The proposed git repository name would be aries-tx-control.git (to fit in line 
with other Aries projects in git).

Tim

Re: Promises and executors

[Timothy Ward]

Hi Ray,

The Deferred is a public type defined by the OSGi specification - it would be a 
very bad thing for Aries to add new public API to it, and it would mean that 
Aries Promises would fail the OSGi CT. If you do want a new method on Deferred 
that requires a change to the specification. Otherwise if you want the Aries 
behaviour then the correct way to do this is to use the Aries PromiseImpl 
(which is an exported API type).

Regards,

Tim


> On 11 Aug 2017, at 16:51, Raymond Auge  wrote:
> 
> Aries async has a PromiseImpl which allows an executor as argument.
> 
> Should it also implement a Deferred which can do the same?
> 
> And finally, should this DeferredImpl also provide the functions of the
> static Promises class, but using the configured executor
> 
> I guess my main concern is that using Promises.all has no way to appoint an
> executor for it's own promise which is created from a Deferred.
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [VOTE] Release Apache Aries Remote Service Admin 1.11.0 ... take 3

[Timothy Ward]

Everything looks to be in the right place, and the verification script seems 
happy.

+1

> On 6 Jul 2017, at 08:27, Guillaume Nodet  wrote:
> 
> +1
> 
> 2017-07-01 14:32 GMT+02:00 Christian Schneider :
> 
>> I had to redo the release as the source zip was missing ...
>> 
>> This release now contains the source zip at https://repository.apache.org/
>> content/repositories/orgapachearies-1113/org/apache/aries/
>> rsa/org.apache.aries.rsa.main/1.11.0/org.apache.aries.rsa.
>> main-1.11.0-source-release.zip
>> 
>> I've staged the release at
>> 
>> https://repository.apache.org/content/repositories/orgapachearies-1113/
>> 
>> For a list of issues resolved see:
>> 
>> https://issues.apache.org/jira/projects/ARIES/versions/12339614
>> 
>> 
>> Release Notes - Aries - Version rsa-1.11.0
>> 
>> ** Bug
>>* [ARIES-1713] - TopologyManagerExport fails for multiple interfaces
>>* [ARIES-1714] - fastbin long running (future) calls sometimes fail
>> 
>> ** Improvement
>>* [ARIES-1684] - Upgrade ZooKeeper to 3.4.10
>> 
>> Please review and vote
>> 
>> Here is my
>> +1
>> 
>> Christian
>> 
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> http://www.talend.com
>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet

Re: [VOTE] Release Apache Aries Remote Service Admin 1.11.0 ... take 2

[Timothy Ward]

Unless I’m mistaken this isn’t a release for one or two modules, it’s for the 
entire RSA reactor? I’m not sure how to verify this release if I can’t build 
it, which is a requirement for a +1 vote 
(https://www.apache.org/legal/release-policy.html#release-approval and 
https://www.apache.org/legal/release-policy.html#source-packages).

I’m somewhat concerned that this hasn’t been picked up before in previous 
releases, and I really do think that it needs to be fixed. Past mistakes aren’t 
a good justification for doing things incorrectly now.

Tim

On 30 Jun 2017, at 14:59, Christian Schneider 
<ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote:

You are right but we also did not have this for any of the older releases or 
Aries RSA.

Christian

On 30.06.2017 15:37, Timothy Ward wrote:
Hi Christian,

I’m still not seeing source for any of the reactor projects. I would expect to 
see a source release zip that people can download and build. For example, if 
you look at the recently released Tx Control 0.0.3 
http://central.maven.org/maven2/org/apache/aries/tx-control/tx-control/0.0.3/ 
then you can see there is a source zip generated which lets you build/test the 
whole reactor in one go. I’m pretty sure that this is supposed to be generated 
automatically by the Apache release process - are you releasing using the 
correct profile?

Regards,

Tim

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Release Apache Aries Remote Service Admin 1.11.0 ... take 2

[Timothy Ward]

Hi Christian,

I’m still not seeing source for any of the reactor projects. I would expect to 
see a source release zip that people can download and build. For example, if 
you look at the recently released Tx Control 0.0.3 
http://central.maven.org/maven2/org/apache/aries/tx-control/tx-control/0.0.3/ 
then you can see there is a source zip generated which lets you build/test the 
whole reactor in one go. I’m pretty sure that this is supposed to be generated 
automatically by the Apache release process - are you releasing using the 
correct profile?

Regards,

Tim



On 30 Jun 2017, at 08:54, David Bosschaert 
> wrote:

+1

David

On 29 June 2017 at 13:19, Christian Schneider 
>
wrote:

I had to redo the release as the sources were missing ...

I've staged the release at

https://repository.apache.org/content/repositories/orgapachearies-1112/

For a list of issues resolved see:

https://issues.apache.org/jira/projects/ARIES/versions/12339614


Release Notes - Aries - Version rsa-1.11.0

** Bug
   * [ARIES-1713] - TopologyManagerExport fails for multiple interfaces
   * [ARIES-1714] - fastbin long running (future) calls sometimes fail

** Improvement
   * [ARIES-1684] - Upgrade ZooKeeper to 3.4.10

Please review and vote

Here is my
+1

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Prototype for reactive streams and a messaging component abstraction

[Timothy Ward]

Hi Christian,

PushStreams are a fundamentally different take on the way streams are 
controlled, mostly in an effort to make them simpler. They do not implement the 
reactive streams API, although it is possible to adapt between them. You 
mentions that you want to be independent of a stream DSL, but also that you 
specifically want to use the reactor DSL. These two things seem to be at odds 
with one another…

With Push Streams you have a Push Event Source, which can be implemented 
directly (it’s lambda friendly) or you can use a SimplePushEventSource.

From the producing side you simply publish events as they arrive. A consumer 
can directly connect to a source, or you can make a PushStream from it using a 
PushStreamProvider. A PushStream is assembled just like a Java 8 Stream, and 
gets you answers at the end.

Push Streams are available in the sonatype OSGi repository, and are in the 
latest R7 draft spec. I do suggest taking a look as I think it will save a lot 
of code.

Regards,

Tim


> On 29 Jun 2017, at 12:04, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> Hi Tim,
> 
> I did not look into Pushstreams in detail. Does Pushstreams also support the 
> reactive streams API?
> My goal was to create a component API that is independent of a specific 
> stream DSL.
> 
> You mentioned that push streams are simpler to use. How would a component 
> look like for push streams. Can such a component then also be run with the 
> reactor DSL?
> 
> For my experiments with the DSL I chose reactor as it will get a lot of 
> attention as the core of spring 5.
> 
> Christian
> 
> On 29.06.2017 11:10, Timothy Ward wrote:
>> Hi Christian,
>> 
>> Did you also take a look at the OSGi produced reactive libraries? 
>> PushStreams seem to be a much more elegant solution for what you’re trying 
>> to do, and would let you simplify the connectors quite a lot. I think the 
>> client examples would also be quite a lot simpler. There’s also an OSGi RFC 
>> for messaging that might be helpful to look at 
>> https://github.com/osgi/design/blob/36a3ee74db246c5a73f8d043c7172494fefee948/rfcs/rfc0229/RFC0229-MQTT.pdf.
>> 
>> Regards,
>> 
>> Tim
>> 
>> 
>> 
>> On 26 Jun 2017, at 17:12, Christian Schneider 
>> <ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote:
>> 
>> I recently looked into ways to combine messaging and streaming on OSGi.
>> 
>> Interestingly the best streaming solution I found for my case was Reactor 
>> (by Pivotal) which is the core of spring 5. It works out of the box on OSGi 
>> and only has a single dependency.
>> 
>> The next thing was how to combine this with messaging in a loosely coupled 
>> way. I really like Apache Camel but I think it is not up to date any more 
>> and also acquired a lot of weight over time (especially in camel-core). So I 
>> was looking into providing a light weight component API and combine it with 
>> Reactor.
>> 
>> The result is this project:
>> 
>> https://github.com/cschneider/streaming-osgi/tree/master/reactortest
>> 
>> This is the Component API: 
>> https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/component/api/MComponent.java
>> Actually I am unsure if the converter must be part of the API but this is 
>> the current state.
>> 
>> I created some POC components for Mqtt, EventAdmin and Mail.
>> 
>> and finally two examples:
>> 
>> Listen on eventadmin topic, log and forward to other topic:
>> https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/ExampleEventAdmin.java
>> 
>> Listen to mqtt, compute average over sliding window and forward to other 
>> topic:
>> https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/MqttExampleComponent.java
>> 
>> 
>> I think there is a lot of potential in Reactor and also in messaging 
>> components that do not couple your code to the technology.
>> 
>> I would be happy about any feedback on the prototype. Beware the code is not 
>> yet split into bundles but I hope the intention is still visible.
>> 
>> Best
>> 
>> Christian
>> 
>> 
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> http://www.talend.com
>> 
>> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Re: [DISCUSS] Release Aries RSA 1.11.0 tomorrow?

[Timothy Ward]

Hi Christian,

I am unable to find any sources in the release repository - where are they? 
These are the most important part of the release (from an Apache perspective), 
and are what I need to validate before I can +1. If they aren’t in the release 
repository then I’m afraid that I will have to -1 the release.

Regards,

Tim


> On 26 Jun 2017, at 16:57, Christian Schneider  wrote:
> 
> The last Aries RSA release was in February. In the mean time not much 
> happened but there are 3 issues solved and I think we should push out a new 
> release for them.
> 
> https://issues.apache.org/jira/projects/ARIES/versions/12339614
> 
> Best
> 
> Christian
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Re: Prototype for reactive streams and a messaging component abstraction

[Timothy Ward]

Hi Christian,

Did you also take a look at the OSGi produced reactive libraries? PushStreams 
seem to be a much more elegant solution for what you’re trying to do, and would 
let you simplify the connectors quite a lot. I think the client examples would 
also be quite a lot simpler. There’s also an OSGi RFC for messaging that might 
be helpful to look at 
https://github.com/osgi/design/blob/36a3ee74db246c5a73f8d043c7172494fefee948/rfcs/rfc0229/RFC0229-MQTT.pdf.

Regards,

Tim



On 26 Jun 2017, at 17:12, Christian Schneider 
> wrote:

I recently looked into ways to combine messaging and streaming on OSGi.

Interestingly the best streaming solution I found for my case was Reactor (by 
Pivotal) which is the core of spring 5. It works out of the box on OSGi and 
only has a single dependency.

The next thing was how to combine this with messaging in a loosely coupled way. 
I really like Apache Camel but I think it is not up to date any more and also 
acquired a lot of weight over time (especially in camel-core). So I was looking 
into providing a light weight component API and combine it with Reactor.

The result is this project:

https://github.com/cschneider/streaming-osgi/tree/master/reactortest

This is the Component API: 
https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/component/api/MComponent.java
Actually I am unsure if the converter must be part of the API but this is the 
current state.

I created some POC components for Mqtt, EventAdmin and Mail.

and finally two examples:

Listen on eventadmin topic, log and forward to other topic:
https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/ExampleEventAdmin.java

Listen to mqtt, compute average over sliding window and forward to other topic:
https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/MqttExampleComponent.java


I think there is a lot of potential in Reactor and also in messaging components 
that do not couple your code to the technology.

I would be happy about any feedback on the prototype. Beware the code is not 
yet split into bundles but I hope the intention is still visible.

Best

Christian


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache Aries Tx Control Release candidate 0.0.3

[Timothy Ward]

This vote has been running for more than 72 hours and has 5 +1 votes. I am 
closing it now and will complete the release.

Thanks everyone,

Regards,

Tim


> On 23 Jun 2017, at 22:36, Dominik Przybysz <alien11...@gmail.com> wrote:
> 
> +1
> 
> 2017-06-23 23:12 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> 
>> +1
>> 
>> Christian
>> 
>> 2017-06-23 16:01 GMT+02:00 Timothy Ward <timothyjw...@apache.org>:
>> 
>>> Hi all,
>>> 
>>> There have been a few updates and improvements to the Aries Transaction
>>> Control implementation since its 0.0.2 release last October. This
>> includes
>>> support for programmatically created resource providers being discarded,
>>> and also support for XA transactions on Hibernate 5.2.x. This release is
>>> also intended to be the final 0.x release before a 1.0.0 release
>> coinciding
>>> with the OSGi R7 specification later this year.
>>> 
>>> The staged release is available at https://repository.apache.org/
>>> content/repositories/orgapachearies-1109/ and instructions for verifying
>>> the release are available at http://aries.apache.org/
>>> development/verifyingrelease.html
>>> 
>>> 
>>> I have run the RAT and IANAL build checks. The .gitignore and packageinfo
>>> files in the projects are reported incorrectly as RAT failures, however
>> all
>>> other source and build files pass the checks.
>>> 
>>> The vote will be open for 72 hours.
>>> 
>>> [ ] +1
>>> [ ]  0
>>> [ ] -1
>>> 
>>> Regards,
>>> 
>>> Tim Ward
>>> 
>> 
>> 
>> 
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
>> 46=http%3a%2f%2fwww.liquid-reality.de>
>> 
>> Open Source Architect
>> http://www.talend.com
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
>> 46=http%3a%2f%2fwww.talend.com>
>> 
> 
> 
> 
> -- 
> Pozdrawiam / Regards,
> Dominik Przybysz

[DISCUSS] Apache Aries Tx Control Release candidate 0.0.3

[Timothy Ward]

This thread is available for any non-voting discussion regarding the 0.0.3 
release of Aries Transaction Control.

Regards,

Tim Ward

[VOTE] Apache Aries Tx Control Release candidate 0.0.3

[Timothy Ward]

Hi all,

There have been a few updates and improvements to the Aries Transaction Control 
implementation since its 0.0.2 release last October. This includes support for 
programmatically created resource providers being discarded, and also support 
for XA transactions on Hibernate 5.2.x. This release is also intended to be the 
final 0.x release before a 1.0.0 release coinciding with the OSGi R7 
specification later this year.

The staged release is available at 
https://repository.apache.org/content/repositories/orgapachearies-1109/ and 
instructions for verifying the release are available at 
http://aries.apache.org/development/verifyingrelease.html


I have run the RAT and IANAL build checks. The .gitignore and packageinfo files 
in the projects are reported incorrectly as RAT failures, however all other 
source and build files pass the checks.

The vote will be open for 72 hours.

[ ] +1
[ ]  0
[ ] -1

Regards,

Tim Ward

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

On 20 Jun 2017, at 15:28, Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>> wrote:

2017-06-20 12:53 GMT+02:00 Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>>:

Hi Guillaume,

The OSGi Alliance is an open organisation, and a number of OPS4j
developers are already members via their companies. There is absolutely
nothing preventing them from getting involved with the Alliance, nor
preventing any non-members from joining.

On the other hand to maintain the openness of its standards the OSGi
Alliance must have a strict IP policy, one that prevents it from consuming
arbitrary code or IP from external sources. If OPS4j are able to get to a
compatible place contribution-wise then I'm sure you'd see a flow of work
in the other direction too.

As for Aries Tx Control - a Narayana based XA implementation would be a
great addition, as would JMS support.


I agree, I may look at it in the future, but that would be easily based on
what I'm proposing here.  Aries tx-control does not necessarily have to
host the pooling code, but rather the rfc 220 integration code imho.



Wrapping the Geronimo transaction manager is deliberate for three reasons:

* the javax.transaction package is toxic due to its split package in the
JRE. Hiding all of the JTA code allows the impl to work without system
packages being declared when launching the OSGi framework.


That’s not specific to the Geronimo TM afaik.

This is not specific to the Geronimo TM, but it is a reason that wrapping a TM 
is preferable to consuming one from another bundle. Wrapping lets the JTA 
package usage be purely internal, and avoids the toxic class space issues.




* by being Geronimo specific the implementation can offer last participant
support


I don't think that's true either.  Geronimo TM itself offers no support for
enlisting local resources.  What tx-control does is wrap local resources
with the  LocalXAResourceImpl and just expect everything will be ok.   The
TM should at list make sure that such wrapped local resources should be
called last in the prepare phase.  Afaik, that's not the case with the
Geronimo TM.  I think the current code should work as is with other TM, or
better of some can offer real support for this use case.
I think Narayana simply requires the XAResource to implement a specific
interface Last in order to be called last in the prepare phase and lessen
the possibilities of something bad happening.


The Aries TX control implementation wraps the resource and adds it to the last 
place in the resource list. It does this safe in the knowledge that Geronimo 
calls resources in a FIFO order when preparing. This is not required to be true 
for other implementations (which may optimise their calls in different ways), 
and so requires knowledge of the specific implementation logic. Similarly, 
implementing a Narayana interface requires you to know that the implementation 
will pay attention to the interface, and cannot be done speculatively.



* by being Geronimo specific the implementation can support XA recovery


Yes, it's really unfortunate that the JTA spec has not covered this part.
I'm wondering if we there's a place for a small project which would offer
an api and wrappers around existing TM so that they could be switched if
needed, and more importantly, so that code can access those non standard
features without dealing with the specifics.
I may try working on this part next, then maybe integrate both into
tx-control.

I think that this would need to be custom per-provider, but a Narayana 
implementation would definitely be useful.



This model gives a great level of functionality in an easy to access way
for users, and I would be keen to keep this option. A pluggable model is
possible, but would need to be done carefully to ensure that scopes could
cope with external parties "messing with" the transaction. It would also
lose the benefits described above, although neither of these things mean
that it would not be worth adding as an alternative implementation.

Finally - I am not sure why tx Control would have a dependency on pax jdbc
(other than as a source of DataSourceFactory services)? This sounds like it
would make the Aries project harder to configure and deploy, and I can't
immediately see what additional benefits it would provide. Can you clarify?


From a high level, pax-jdbc aims at providing DataSourceFactory while
tx-control aims at integrating those into the transaction api. So it could
make sense to layer them.  I haven’t looked at the specifics though...

I think that this layering already exists. Right now the Tx Control JDBC and 
JPA providers expect to find and make use of a standard DataSourceFactory 
service.

Regards,

Tim


Guillaume



Regards,

Tim

Sent from my iPhone

On 20 Jun 2017, at 11:00, Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>> wrote:

2017-06-16 11:16 GMT+02:00 Richard Nicholson 
<puppy_w

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

Hi Achim,

I am certain that that this is a conversation that has been had before, and 
that it would be better for any revisit of this discussion to be held between 
OPS4j and the Alliance rather than on the Karaf/Aries dev lists. I am also not 
an OSGi board representative, nor am I corporate officer of the OSGi Alliance, 
so I can’t speak on their behalf. Finally, I wasn’t part of any previous 
discussion between OPS4j and the OSGi Alliance about accepting implementations 
from OPS4j, so I do not know what any specific sticking points might have been.

I do know that in order for an “external” community to contribute reference 
implementations to the OSGi Alliance (which seems to be what we’re talking 
about here) there are rules about acceptable Open Source licences, levels of 
community diversity, legal IP governance and guarantees of originality for the 
code. There are probably other important requirements that I am not aware of. I 
know that Apache and Eclipse are examples of acceptable external communities 
which are regularly used to provide reference implementations, and that OPS4j 
is currently not on that list.

There may be very little for OPS4j to do to become another such community, or 
there may be some thornier problems that would need to be solved before that 
could be the case. If you want anything more specific I strongly recommend 
contacting the OSGi Alliance, either through a board member or the CTO. See 
https://www.osgi.org/about-us/board-officers/ for contact details.

Best Regards,

Tim


On 20 Jun 2017, at 12:12, Achim Nierbeck 
<bcanh...@googlemail.com<mailto:bcanh...@googlemail.com>> wrote:

Hi Tim,

could you please elaborate on this a bit more?

On the other hand to maintain the openness of its standards the OSGi
Alliance must have a strict IP policy, one that prevents it from consuming
arbitrary code or IP from external sources. If OPS4j are able to get to a
compatible place contribution-wise then I'm sure you'd see a flow of work
in the other direction too.


especially the "If OPS4j are able to get to a compatible place
contribution-wise"

what in your view is missing for the OPS4j community to be regarded a
compatible place?

regards, Achim



2017-06-20 12:53 GMT+02:00 Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>>:

Hi Guillaume,

The OSGi Alliance is an open organisation, and a number of OPS4j
developers are already members via their companies. There is absolutely
nothing preventing them from getting involved with the Alliance, nor
preventing any non-members from joining.

On the other hand to maintain the openness of its standards the OSGi
Alliance must have a strict IP policy, one that prevents it from consuming
arbitrary code or IP from external sources. If OPS4j are able to get to a
compatible place contribution-wise then I'm sure you'd see a flow of work
in the other direction too.

As for Aries Tx Control - a Narayana based XA implementation would be a
great addition, as would JMS support.

Wrapping the Geronimo transaction manager is deliberate for three reasons:

* the javax.transaction package is toxic due to its split package in the
JRE. Hiding all of the JTA code allows the impl to work without system
packages being declared when launching the OSGi framework.

* by being Geronimo specific the implementation can offer last participant
support

* by being Geronimo specific the implementation can support XA recovery

This model gives a great level of functionality in an easy to access way
for users, and I would be keen to keep this option. A pluggable model is
possible, but would need to be done carefully to ensure that scopes could
cope with external parties "messing with" the transaction. It would also
lose the benefits described above, although neither of these things mean
that it would not be worth adding as an alternative implementation.

Finally - I am not sure why tx Control would have a dependency on pax jdbc
(other than as a source of DataSourceFactory services)? This sounds like it
would make the Aries project harder to configure and deploy, and I can't
immediately see what additional benefits it would provide. Can you clarify?

Regards,

Tim

Sent from my iPhone

On 20 Jun 2017, at 11:00, Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>> wrote:

2017-06-16 11:16 GMT+02:00 Richard Nicholson 
<puppy_wants_a_...@me.com<mailto:puppy_wants_a_...@me.com>>:


Doesn’t this directly clash with OSGi Alliance Transaction Control
Specification work going on in Aries?

If so, wouldn’t it make more sense for this community to input into that
work rather than cause needless confusion / fragmentation?


Just a thought.


Yeah, I'm a bit skeptic about the relationship between the OPS4j
community
and the OSGi Alliance work.  It seems to always go in the same
direction...
i.e. the guys working at OPS4j should help working on the project defined
by the gu

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

Hi Christian

The Transaction Control API has no OSGi framework dependency, so a Java SE mode 
of operation would be possible (just like Aries blueprint no osgi). Possibly 
something worth exploring?

Tim

Sent from my iPhone

> On 20 Jun 2017, at 11:35, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> Aries transaction control has a lot of good parts. Unfortunately though it is 
> an all or nothing solution.
> It works well if you directly depend on Aries transaction control in your 
> user code. Unfortunately this makes the code OSGi only. So this is not an 
> option for many projects like CXF or Camel.
> 
> The benefit of pax-jdbc-config and pax-jdbc-pool* ist that it provides a XA 
> ready DataSource that can be leveraged by code that is OSGi agnostic.
> 
> So I think there is a need for the same in the JMS space. So why not focus on 
> jms only and call the project pax-jms? In fact there already is such a 
> project that we could build on and extend for XA features.
> 
> Christian
> 
> 
>> On 16.06.2017 11:29, Timothy Ward wrote:
>> The Transaction Control project in Aries does have a pretty complete overlap 
>> with what’s being proposed here. There are already resource providers for 
>> JPA and JDBC which provide connection pooling, resource local transactions 
>> and XA transactions. It would be great to get some input into a JMS resource 
>> provider to extend the set of supported resource types.
>> 
>> The Aries TX control code already includes a base resource project for 
>> adding Resource providers which should help to ensure correct lifecycle 
>> management - I’d be happy to talk through that code in more detail. 
>> Contributing JMS support should therefore be a (relatively) simple process 
>> of providing the necessary JMS customisation much like with JDBC.
>> 
>> Happy to help,
>> 
>> Tim
>> 
>> 
>>> On 16 Jun 2017, at 10:20, Grzegorz Grzybek <gr.grzy...@gmail.com> wrote:
>>> 
>>> +1
>>> 
>>> Great about forking tranql - finally ;)
>>> 
>>> regards
>>> Grzegorz
>>> 
>>> 2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_...@me.com>:
>>> 
>>>> Doesn’t this directly clash with OSGi Alliance Transaction Control
>>>> Specification work going on in Aries?
>>>> 
>>>> If so, wouldn’t it make more sense for this community to input into that
>>>> work rather than cause needless confusion / fragmentation?
>>>> 
>>>> Just a thought.
>>>> 
>>>> 
>>>>> On 15 Jun 2017, at 13:55, Toni Menzel <toni.men...@rebaze.com> wrote:
>>>>> 
>>>>> Sounds interesting!
>>>>> Two comments:
>>>>> 
>>>>>  - i find the whole space of "pooling resources" a not confusing and
>>>> hard
>>>>>  to find out what you actually really need. So, say once you know you
>>>> want
>>>>>  takaricp, which other bridges and matching configs do you need so that
>>>> the
>>>>>  DataSource proxy (for JDBC) appears in your Service Registry. Maybe
>>>> it's
>>>>>  just me not following bridge provider-projects like Aries too closely.
>>>>>  Anything that makes setup simpler and offers a wider range of options
>>>> is
>>>>>  highly welcome. (particularly in the OPS4J community, or how Bndtools
>>>>>  people say "P A X" ;)
>>>>>  - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the
>>>>>  Transx a bit alien. just an idea.
>>>>> 
>>>>> Thanks for your heads up, JB about karaf-boot. Was wondering what
>>>> happened
>>>>> to it.
>>>>> 
>>>>> Toni
>>>>> 
>>>>> 
>>>>> On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck <bcanh...@googlemail.com
>>>>> 
>>>>> wrote:
>>>>> 
>>>>>> Hi Guillaume,
>>>>>> 
>>>>>> sounds like a good idea to me, and the pax space like the perfect eco
>>>>>> system :)
>>>>>> 
>>>>>> regards, Achim
>>>>>> 
>>>>>> 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>> It sounds like a good idea and definitely a good candidate for PAX.
>>>>>>> 

Re: tx-control-service-local Source binary mismatch

[Timothy Ward]

Hi Arvind,

The Transaction Control project is built and released as a single unit, 
containing a number of sub-modules. The binary that you’re looking at is a 
single module (not the whole project). This module aggregates code from a 
number of other transaction control modules to make an easy to consume binary 
for runtime use (rather than having to install several bundles to make anything 
work). In this case the sources for the common code come from the 
tx-control-service-common project and the Transaction Control API from the 
tx-control-api module. It is relatively common for open source libraries to 
provide aggregate binaries in this way for ease of use.

If you want to have all of the sources available in a single release that you 
can build yourself then the correct artifact to download is 
http://central.maven.org/maven2/org/apache/aries/tx-control/tx-control/0.0.2/tx-control-0.0.2-source-release.zip
 

 - this is the formal Apache release artifact that contains all of the source 
code for the 0.0.2 release of Apache Aries Transaction Control. The other 
binaries released to maven central are all generated by this build, and are 
provided for user convenience (i.e. so you don’t have to build everything 
yourself).

The individual project sources (such as the one you downloaded) are also 
buildable, but obviously rely on you being able to download the other released 
modules on which they depend. I hope this answers your question.

Regards,

Tim


> On 12 Apr 2017, at 20:49, Arvind Nadendla  wrote:
> 
> Hey,
> 
> I see that the source and binary available in maven for
> tx-control-service-local 0.0.2 components do not match.
> 
> The binary contains files for which sources are not available in the
> maven repo at 
> http://central.maven.org/maven2/org/apache/aries/tx-control/tx-control-service-local/0.0.2/tx-control-service-local-0.0.2-sources.jar
> 
> What is the right forum to report this issue?
> -- 
> Arvind Nadendla
> 

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

[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

[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
> 

Re: Build failed in Jenkins: Aries-JPA-Trunk-JDK7 #127

[Timothy Ward]

The latest snapshots of the JPA container component now use the publicly 
published OSGi snapshot API. These are built using JDK 8, but I have added the 
retrolambda plugin to ensure the built binary is still JDK 1.6 compatible. The 
build, however, must now use JDK 1.8 because otherwise retrolambda cannot run. 
I trust that this is an acceptable compromise (i.e. not requiring JDK 8 at 
runtime for JPA).

Regards,

Tim

> On 3 Mar 2017, at 12:58, Apache Jenkins Server  
> wrote:
> 
> See 
> 
> 
> Changes:
> 
> [timothyjward] [jpa] Add support for the standard JPA service extender 
> capability
> 
> Fixes ARIES-1671
> 
> [timothyjward] [jpa] Update to use OSGi API snapshots for the JPA Service
> 
> Fixes ARIES-1698
> 
> --
> [...truncated 8.31 KB...]
> [INFO] --- maven-remote-resources-plugin:1.5:process (default) @ 
> org.apache.aries.jpa.api ---
> [INFO] 
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
> org.apache.aries.jpa.api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.2.0:cleanVersions (cleanVersions) @ 
> org.apache.aries.jpa.api ---
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ 
> org.apache.aries.jpa.api ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 5 source files to 
> 
> [INFO] 
> [INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @ 
> org.apache.aries.jpa.api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ 
> org.apache.aries.jpa.api ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
> org.apache.aries.jpa.api ---
> [JENKINS] Recording test results[INFO] 
> [INFO] --- maven-bundle-plugin:3.2.0:bundle (default-bundle) @ 
> org.apache.aries.jpa.api ---
> 
> [INFO] 
> [INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
> org.apache.aries.jpa.api ---
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.2.0:baseline (baseline) @ 
> org.apache.aries.jpa.api ---
> [INFO] Downloading: 
> https://repo.maven.apache.org/maven2/org/apache/aries/jpa/org.apache.aries.jpa.api/2.3.0/org.apache.aries.jpa.api-2.3.0.jar
> [INFO] Downloaded: 
> https://repo.maven.apache.org/maven2/org/apache/aries/jpa/org.apache.aries.jpa.api/2.3.0/org.apache.aries.jpa.api-2.3.0.jar
>  (12 KB at 535.1 KB/sec)
> [INFO] Baseline Report - Generated by Apache Felix Maven Bundle Plugin on 
> 2017-03-03T12:58Z based on Bnd - see http://www.aqute.biz/Bnd/Bnd
> [INFO] Comparing bundle org.apache.aries.jpa.api version 2.7.0-SNAPSHOT to 
> version 2.3.0
> [INFO] 
> [INFO]   PACKAGE_NAME   DELTA  
> CUR_VERBASE_VER   REC_VERWARNINGS  
> [INFO] = == == 
> == == == ==
> [INFO]   org.apache.aries.jpa.supplier  unchanged  1.0.0  
> 1.0.0  1.0.0  - 
> [INFO] 
> ---
> [INFO]   org.apache.aries.jpa.template  unchanged  1.0.0  
> 1.0.0  1.0.0  - 
> [INFO] 
> ---
> [INFO] Baseline analysis complete, 0 error(s), 0 warning(s)
> [INFO] 
> [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
> org.apache.aries.jpa.api ---
> [INFO] Checking legal files in: org.apache.aries.jpa.api-2.7.0-SNAPSHOT.jar
> [INFO] 
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> org.apache.aries.jpa.api ---
> [INFO] Installing 
> 
>  to 
> /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/aries/jpa/org.apache.aries.jpa.api/2.7.0-SNAPSHOT/org.apache.aries.jpa.api-2.7.0-SNAPSHOT.jar
> [INFO] Installing 
>  to 
> /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/aries/jpa/org.apache.aries.jpa.api/2.7.0-SNAPSHOT/org.apache.aries.jpa.api-2.7.0-SNAPSHOT.pom
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.2.0:install (default-install) @ 
> 

[jira] [Resolved] (ARIES-1671) Adding a standard JPA extender capability

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward resolved ARIES-1671.
-
Resolution: Fixed

> Adding a standard JPA extender capability
> -
>
> Key: ARIES-1671
> URL: https://issues.apache.org/jira/browse/ARIES-1671
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Timothy Ward
>
> OSGi JPA Service 1.1 compatibility
> The JPA Service extender is required to advertise the following:
> Provide-Capability: osgi.extender;
> osgi.extender="osgi.jpa";
> version:Version="1.1";
> uses:="org.osgi.service.jpa,javax.persistence"



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

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

[Timothy Ward (JIRA)]

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

Timothy Ward resolved ARIES-1698.
-
Resolution: Fixed

> 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
> 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] [Updated] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot

[Timothy Ward (JIRA)]

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

Timothy Ward updated ARIES-1698:

Fix Version/s: jpa-2.7.0

> 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
> 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] [Updated] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot

[Timothy Ward (JIRA)]

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

Timothy Ward updated ARIES-1698:

Affects Version/s: jpa-2.6.0

> 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
> 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] [Created] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1698:
---

 Summary: 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
Reporter: Timothy Ward


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] [Assigned] (ARIES-1692) Add functionality to be able to supply a test query for use in checking pooled connections

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward reassigned ARIES-1692:
---

Assignee: Timothy Ward

> Add functionality to be able to supply a test query for use in checking 
> pooled connections
> --
>
> Key: ARIES-1692
> URL: https://issues.apache.org/jira/browse/ARIES-1692
> Project: Aries
>  Issue Type: Improvement
>  Components: tx-control
>Affects Versions: tx-control-0.0.3
>Reporter: Tim
>Assignee: Timothy Ward
>Priority: Minor
> Fix For: tx-control-0.0.3
>
> Attachments: org.apache.aries.tx-control-itests.patch, 
> tx-control-provider-jdbc-local.patch, tx-control-provider-jdbc-xa.patch, 
> tx-control-provider-jpa-common.patch
>
>
> A common feature of pooling libraries is to be able to supply a test query 
> for use in checking pooled connections. Many of the later JDBC drivers do not 
> need this option as the driver implements Connection.isValid(), however some 
> older drivers don't implement this method correctly.
> Add functionality to be able to supply a test query for use in checking 
> pooled connections.



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

Re: [Heads up] Aries JPA 2.6.0 release in two days

[Timothy Ward]

I looked only into the issues that have fix version 2.6.0.

Surely as the project area lead you should be looking at the issues that have 
affects version 2.6.0 and setting the fix version appropriately?

If you intend to implement any of these issues for 2.6.0 then please set the 
fix version. This allows me to see if a release is complete feature wise.

These issues were assigned to you, as requested, when they were created as part 
of preparing Aries JPA to be the reference implementation for the next version 
of the OSGi Spec.

Btw. I just found that we got a big issue with Aries JPA and Karaf 4.1.0. It 
seems that at least Aries JPA 2.5.0 and hibernate 5 features do not work 
together as both
jpa 2.0 and 2.1 apis are installed.

This is why we need to start using the JavaJPA contract so that this sort of 
thing works better!

Tim

On 21 Feb 2017, at 16:02, Christian Schneider 
<ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote:

I looked only into the issues that have fix version 2.6.0.
If you intend to implement any of these issues for 2.6.0 then please set the 
fix version. This allows me to see if a release is complete feature wise.

We should only pick the low hanging fruits for this release though as at least 
Giuseppe is waiting for the fix of the threading issue.

Btw. I just found that we got a big issue with Aries JPA and Karaf 4.1.0. It 
seems that at least Aries JPA 2.5.0 and hibernate 5 features do not work 
together as both
jpa 2.0 and 2.1 apis are installed.

Christian

On 21.02.2017 16:50, Timothy Ward wrote:
Hi Christian,

I see a lot more than one issue left, and several of them are easy to fix.

https://issues.apache.org/jira/browse/ARIES-1642
https://issues.apache.org/jira/browse/ARIES-1670
https://issues.apache.org/jira/browse/ARIES-1671
https://issues.apache.org/jira/browse/ARIES-1672


I can understand if you choose not to release a fix for 1671 until the OSGi JPA 
Service 1.1 specification is final, but I think that the others should be fixed 
for 2.7.

Tim

On 21 Feb 2017, at 11:19, Christian Schneider 
<ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote:

We did some bug fixes and improvements in providing the correct capapbilities.
Especially because of the threading issue found by Giuseppe I would like to do 
a release quite soon.

See here for the full list of issues fixed:

https://issues.apache.org/jira/browse/ARIES/fixforversion/12338632

There is one open issue left:
https://issues.apache.org/jira/browse/ARIES-1674
but I think we can move it to 2.7.0 if I can not get a fix in until the release.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[jira] [Closed] (ARIES-1648) Aries JPA does not advertise EntityManagerFactoryBuilder or EntityManagerFactory services

[Timothy Ward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Ward closed ARIES-1648.
---

> Aries JPA does not advertise EntityManagerFactoryBuilder or 
> EntityManagerFactory services
> -
>
> Key: ARIES-1648
> URL: https://issues.apache.org/jira/browse/ARIES-1648
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>    Reporter: Timothy Ward
>Assignee: Christian Schneider
> Fix For: jpa-2.6.0
>
>
> The Aries JPA container provides an extender for persistence bundles. This 
> extender results in the registration of EntityManagerFactory and/or 
> EntityManagerFactoryBuilder services. These services are then used by clients 
> to make use of JPA.
> The problem is that there are no capabilities advertising this feature. 
> Ideally there would be a Provide-Capability added automatically to every 
> persistence bundle, but this is true for few, if any, persistence bundles, 
> and also most persistence bundles do not make use of the org.osgi.service.jpa 
> package, making the uses constraint impossible to apply.
> Therefore the Provide Capability header should go on the Aries JPA container:
> Provide-Capability: 
> osgi.service;objectClass=javax.persistence.EntityManagerFactory;effective:=active;uses:=javax.persistence,osgi.service;objectClass=org.osgi.service.jpa.EntityManagerFactoryBuilder;effective:=active";uses:=org.osgi.service.jpa



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

Re: [Heads up] Aries JPA 2.6.0 release in two days

[Timothy Ward]

Hi Christian,

I see a lot more than one issue left, and several of them are easy to fix.

https://issues.apache.org/jira/browse/ARIES-1642
https://issues.apache.org/jira/browse/ARIES-1670
https://issues.apache.org/jira/browse/ARIES-1671
https://issues.apache.org/jira/browse/ARIES-1672


I can understand if you choose not to release a fix for 1671 until the OSGi JPA 
Service 1.1 specification is final, but I think that the others should be fixed 
for 2.7.

Tim

On 21 Feb 2017, at 11:19, Christian Schneider 
> wrote:

We did some bug fixes and improvements in providing the correct capapbilities.
Especially because of the threading issue found by Giuseppe I would like to do 
a release quite soon.

See here for the full list of issues fixed:

https://issues.apache.org/jira/browse/ARIES/fixforversion/12338632

There is one open issue left:
https://issues.apache.org/jira/browse/ARIES-1674
but I think we can move it to 2.7.0 if I can not get a fix in until the release.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com