[jira] [Resolved] (ARIES-1900) Release Transaction Control 1.0.1
[ 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)
[jira] [Created] (ARIES-1900) Release Transaction Control 1.0.1
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)
[jira] [Commented] (ARIES-1897) Update to HikariCP 3.3.0
[ https://issues.apache.org/jira/browse/ARIES-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ https://issues.apache.org/jira/browse/ARIES-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ 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 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
[ https://issues.apache.org/jira/browse/ARIES-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/ARIES-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Created] (ARIES-1895) Add tests for OpenJPA 3.0
Timothy Ward created ARIES-1895: --- Summary: 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 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-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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(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(Abstract
[jira] [Created] (ARIES-1856) Issue with redeployment in Bndtools
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) at or
[jira] [Closed] (ARIES-1848) jaxrs whiteboard jar contains SseEventSource.Builder but not the impl
[ 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)
[jira] [Commented] (ARIES-1824) Add missing `osgi.jaxrs.media.type` properties to extensions
[ https://issues.apache.org/jira/browse/ARIES-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
https://issues.apache.org/jira/browse/ARIES-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Created] (ARIES-1825) NullPointerException in the JAX-RS Whiteboard
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)
[jira] [Updated] (ARIES-1777) need to add aries-blueprint as a dependency to jpa feature
[ 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)
[jira] [Commented] (ARIES-1789) ClientBuilder and SSE
[
https://issues.apache.org/jira/browse/ARIES-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Comment Edited] (ARIES-1767) TransactionControl and transaction isolation among threads
[ https://issues.apache.org/jira/browse/ARIES-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)
[jira] [Resolved] (ARIES-1711) Mapping files in persistence.xml not used
[
https://issues.apache.org/jira/browse/ARIES-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Ward resolved ARIES-1711.
-
Resolution: Fixed
Fix Version/s: jpa-2.7.0
Resolved in the latest snapshots. Thanks for the patches. A more extensive set
of tests has been included in the main build.
> Mapping files in persistence.xml not used
> -
>
> Key: ARIES-1711
> URL: https://issues.apache.org/jira/browse/ARIES-1711
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.7.0, jpa-2.6.1
> Environment: Apache Aries 2.6.1
> Hibernate 5.0.7.Final
> Felix 5.6.1
> JPA 2.1
>Reporter: Alexander Liepold
> Fix For: jpa-2.7.0
>
> Attachments: aries-itest-mapping-files.zip, JPAHandler.patch,
> PersistenceUnit.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The mapping files in a PeristenceUnit are not used by Apache Aries.
>
> The same issue was noticed at this thread:
> http://karaf.922171.n3.nabble.com/Aries-JPA-2-3-0-mapping-file-not-used-td4047501.html
> I have the same problem and I found out that the use of a mapping file in a
> persistence.xml works only on particular circumstances.
> For example if I use the following declaration of a persistence.xml :
>
> {code:xml}
>
>version="2.1">
> transaction-type="RESOURCE_LOCAL">
>
> org.hibernate.jpa.HibernatePersistenceProvider
>
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/testDB)
> META-INF/developer-orm.xml
>
> META-INF/orm.xml
>
> test.Customer
> ...
>
> ...
>
>
>
> {code}
> On deployment of this persistence-unit the class {{test.Customer}} gets
> bootstrapped from Hibernate. The mapping file {{META-INF/orm.xml}} is
> detected automatically from the persistence provider.
> But the mapping file {{META-INF/developer-orm.xml}} is never detected.
>
> If I fixed the particular code in the module Aries JPA Container locally.
> After building and testing the Apache Aries Project I could deploy a
> persistence.xml with multiple mapping files.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARIES-1698) Aries JPA should update to the latest OSGi API snapshot
[ https://issues.apache.org/jira/browse/ARIES-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Resolved] (ARIES-1671) Adding a standard JPA extender capability
[ 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
[ 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
[ 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
[ 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 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] [Resolved] (ARIES-1692) Add functionality to be able to supply a test query for use in checking pooled connections
[ https://issues.apache.org/jira/browse/ARIES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1692. - Resolution: Fixed Fixed via r1784160 > 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)
[jira] [Assigned] (ARIES-1692) Add functionality to be able to supply a test query for use in checking pooled connections
[ 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)
[jira] [Closed] (ARIES-1648) Aries JPA does not advertise EntityManagerFactoryBuilder or EntityManagerFactory services
[ 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)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[
https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842891#comment-15842891
]
Timothy Ward commented on ARIES-1613:
-
As mentioned earlier in this JIRA thread:
{quote}
Discovery providers should not be changing the properties defined by an
EndpointDescription. The Topology Manager is responsible for adding extra
properties when making the export from RemoteServiceAdmin. Changing the
properties in the Discovery layer is a good way to break other RSA
implementations.
{quote}
The DiscoveryPlugin should not be used to modify the endpoint properties.
> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
> Issue Type: Bug
> Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0)
> which makes it impossible to implement 3rd party discovery plugins.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1672) JPA API contract is required
[
https://issues.apache.org/jira/browse/ARIES-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842542#comment-15842542
]
Timothy Ward commented on ARIES-1672:
-
{quote} Shouldn't the capability be provided by the implementation bundle
rather than the API ? I mean, it's like the extender capability to some degree,
you just don't want it to be available by simply deploying the API bundle, but
the whole RI.
{quote}
In general it is correct that capabilities should be provided by
implementations, not by the API, but the contract namespace is a special one
designed to cope with "non semantically versioned" APIs (e.g. Java EE specs).
You can see a description of it here:
https://www.osgi.org/portable-java-contract-definitions/
The contract definition is provided so that users of the API can import it
reliably without using a version range. That way the Java EE specs which make
"major" version bumps can still be used safely (JPA, JAX-RS, Servlet...). The
contract definitely applies to the API, and therefore should go on the API
bundle, not the implementation (unless the implementation also exports the
API).
> JPA API contract is required
>
>
> Key: ARIES-1672
> URL: https://issues.apache.org/jira/browse/ARIES-1672
> Project: Aries
> Issue Type: Bug
>Reporter: Timothy Ward
>Assignee: Christian Schneider
>
> The OSGi JPA service spec requires the presence of an OSGi contract for the
> JPA API. This will probably require Aries JPA to package up its own version
> of the JPA API. Note that this will only be necessary to function as the
> official RI, and we can still support using other public API bundles.
> Provide-Capability: osgi.contract;osgi.contract=JavaJPA;
> version:List="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi"
> We could optionally choose not to support versions 2 or 1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1672) JPA API contract is required
[ https://issues.apache.org/jira/browse/ARIES-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842511#comment-15842511 ] Timothy Ward commented on ARIES-1672: - The spec bundles do not provide the JPA contract capability. In order to comply with the specification the reference implementation must provide this capability. This is why I expect that Aries will need to either: a) Convince the Geronimo team to add the capability to their spec jars or b) Repackage the Geronimo Jars with the capability. The "Reference Implementation" of Aries JPA would then be the spec API jar (including the capability) the Aries JPA container, and a JPA provider (probably EclipseLink). Other users are obviously free to use Aries JPA in other ways, for example with another JPA provider, or with a different spec API jar that doesn't provide the capability. > JPA API contract is required > > > Key: ARIES-1672 > URL: https://issues.apache.org/jira/browse/ARIES-1672 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The OSGi JPA service spec requires the presence of an OSGi contract for the > JPA API. This will probably require Aries JPA to package up its own version > of the JPA API. Note that this will only be necessary to function as the > official RI, and we can still support using other public API bundles. > Provide-Capability: osgi.contract;osgi.contract=JavaJPA; > version:List="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi" > We could optionally choose not to support versions 2 or 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1672) JPA API contract is required
[ https://issues.apache.org/jira/browse/ARIES-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842490#comment-15842490 ] Timothy Ward commented on ARIES-1672: - > I don't think embedding the jpa spec packages makes sense. I wasn't suggesting embedding the JPA API into the container bundle, just stating that the specification requires a bundle which provides the JPA API contract. My expectation is that Aries JPA will create a new bundle which does just that, rather than changing the container. The Aries JPA container bundle can choose to use the contract, or not, when importing the API if that is what the community wants. > The jpa container is open to be used with spec version 2.0 or 2.1 This is fine, but only 2.1 is required by the specification. It's therefore up to you whether you choose to create one or two spec api bundles > JPA API contract is required > > > Key: ARIES-1672 > URL: https://issues.apache.org/jira/browse/ARIES-1672 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The OSGi JPA service spec requires the presence of an OSGi contract for the > JPA API. This will probably require Aries JPA to package up its own version > of the JPA API. Note that this will only be necessary to function as the > official RI, and we can still support using other public API bundles. > Provide-Capability: osgi.contract;osgi.contract=JavaJPA; > version:List="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi" > We could optionally choose not to support versions 2 or 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1672) JPA API contract is required
[ https://issues.apache.org/jira/browse/ARIES-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1672: Assignee: Christian Schneider > JPA API contract is required > > > Key: ARIES-1672 > URL: https://issues.apache.org/jira/browse/ARIES-1672 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The OSGi JPA service spec requires the presence of an OSGi contract for the > JPA API. This will probably require Aries JPA to package up its own version > of the JPA API. Note that this will only be necessary to function as the > official RI, and we can still support using other public API bundles. > Provide-Capability: osgi.contract;osgi.contract=JavaJPA; > version:List="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi" > We could optionally choose not to support versions 2 or 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1671) Adding a standard JPA extender capability
[ https://issues.apache.org/jira/browse/ARIES-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838711#comment-15838711 ] Timothy Ward commented on ARIES-1671: - Also, the extender capability must be taken into account when deciding which bundle(s) to extend. "The JPA extender must only process a persistence bundle's persistence units if the following is true: • The bundle's wiring has a required wire for at least one osgi.extender capability with the name osgi.jpa and the first of these required wires is wired to the JPA extender. • The bundle's wiring has no required wire for an osgi.extender capability with the name osgi.jpa. Otherwise, the JPA Service extender must not process the persistence bundle" > 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.4#6332)
[jira] [Updated] (ARIES-1671) Adding a standard JPA extender capability
[ https://issues.apache.org/jira/browse/ARIES-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1671: Assignee: Christian Schneider > 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 >Assignee: Christian Schneider > > 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.4#6332)
[jira] [Created] (ARIES-1672) JPA API contract is required
Timothy Ward created ARIES-1672: --- Summary: JPA API contract is required Key: ARIES-1672 URL: https://issues.apache.org/jira/browse/ARIES-1672 Project: Aries Issue Type: Bug Reporter: Timothy Ward The OSGi JPA service spec requires the presence of an OSGi contract for the JPA API. This will probably require Aries JPA to package up its own version of the JPA API. Note that this will only be necessary to function as the official RI, and we can still support using other public API bundles. Provide-Capability: osgi.contract;osgi.contract=JavaJPA; version:List="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi" We could optionally choose not to support versions 2 or 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1671) Adding a standard JPA extender capability
Timothy Ward created ARIES-1671: --- Summary: 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.4#6332)
[jira] [Created] (ARIES-1670) Aries JPA should register EntityManagerFactory services after use of the EntityManagerFactory Builder
Timothy Ward created ARIES-1670: --- Summary: Aries JPA should register EntityManagerFactory services after use of the EntityManagerFactory Builder Key: ARIES-1670 URL: https://issues.apache.org/jira/browse/ARIES-1670 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.6.0 Reporter: Timothy Ward Assignee: Christian Schneider Support for version 1.1 of the OSGi JPA Service. Ensuring that the EMF becomes visible as a service with the relevant service properties, and that it is re-registered after rebinding configuration. "In the case of an incomplete Persistence Unit no Entity Manager Factory can be initially registered, however once configured using an Entity Manager Factory Builder service the JPA Service must register the created Entity Manager Factory as a service. The registered service must include any sup- plied configuration properties that match the recommended OSGi service property types as service properties. The javax.persistence.jdbc.password property must be omitted from these service properties. If the Entity Manager Factory Builder service is later used to change the configuration being used by the Entity Manager Factory Service then the registered Entity Manager Factory service must be unregistered and the new object registered." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1642) Aries JPA container cannot be used without Configuration Admin
[ https://issues.apache.org/jira/browse/ARIES-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15811922#comment-15811922 ] Timothy Ward commented on ARIES-1642: - > I also think we should rather not make config admin optional I don't want to make the package dependency optional, but if no configuration admin service implementation is present then Aries JPA should still work. > So the only solution is to call createAndPublishEMF on start with default > properties and then destroy EMF and call another time createAndPublishEMF > with custom properties. I'm not sure if this behaviour is right one. That behaviour sounds right to me. It's exactly what would happen if Configuration Admin were present, and someone created a configuration for an EMF that was previously unconfigured. > Aries JPA container cannot be used without Configuration Admin > -- > > Key: ARIES-1642 > URL: https://issues.apache.org/jira/browse/ARIES-1642 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.5.0 >Reporter: Timothy Ward > > The Aries JPA ManagedEMF registers a managed service factory for each > "complete" EntityManagerFactory service. This isn't part of the JPA service > specification, but does provide a nice way to fix up clients which don't use > the EMFBuilder. > The problem is that if no Config Admin is available in the framework then no > EMF service is ever registered! > The only call to createAndPublishEMF is from the updated method, and the > updated method is only called if Config Admin is running! > https://github.com/apache/aries/blob/d85be2b8f8a026cb1959c83ceb4ed812cd9d1279/jpa/jpa-container/src/main/java/org/apache/aries/jpa/container/impl/ManagedEMF.java#L128 > Having a running Configuration Admin should not be a hard requirement for > Aries JPA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1649) Aries EclipseLink Adapter packaging issues
[ https://issues.apache.org/jira/browse/ARIES-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800868#comment-15800868 ] Timothy Ward commented on ARIES-1649: - Actually it looks to be defined in the jpa-parent project at version 3.0.1. It would be pretty easy to change it there as part of this issue. > Aries EclipseLink Adapter packaging issues > -- > > Key: ARIES-1649 > URL: https://issues.apache.org/jira/browse/ARIES-1649 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The Aries EclipseLink Adapter has two main problems: > 1. The package import ranges for the EclipseLink API are overly specific. The > latest release of the adapter only works with EclipseLink 2.6, even though > all of the APIs it uses were defined long before. This bundle should be built > against an older EclipseLink to ensure that Aries JPA doesn't force users to > upgrade EclipseLink unnecessarily. > 2. The Aries EclipseLink Adapter has no dependency on the EclipseLink JPA > bundle. All of the API that it uses comes from EclipseLink Core, and > therefore when doing a provisioning resolve operation EclipseLink JPA is not > added! This needs to be fixed with a Require-Capability for EclipseLink JPA. > Require-Capability: > osgi.identity;filter:='(osgi.identity=org.eclipse.persistence.jpa)';effective:=active -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1649) Aries EclipseLink Adapter packaging issues
[ https://issues.apache.org/jira/browse/ARIES-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800823#comment-15800823 ] Timothy Ward commented on ARIES-1649: - > I receive the following error during compilation [ERROR] Bundle org.apache.aries.jpa:org.apache.aries.jpa.eclipselink.adapter:bundle:2.6.0-SNAPSHOT : osgi.wiring.* namespaces must not be specified with generic requirements/capabilitie It looks like you're using an old version of bnd to build with. This was fixed back in https://github.com/bndtools/bnd/pull/1311 You should update to a newer version of the maven plugin that you're using. > Aries EclipseLink Adapter packaging issues > -- > > Key: ARIES-1649 > URL: https://issues.apache.org/jira/browse/ARIES-1649 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The Aries EclipseLink Adapter has two main problems: > 1. The package import ranges for the EclipseLink API are overly specific. The > latest release of the adapter only works with EclipseLink 2.6, even though > all of the APIs it uses were defined long before. This bundle should be built > against an older EclipseLink to ensure that Aries JPA doesn't force users to > upgrade EclipseLink unnecessarily. > 2. The Aries EclipseLink Adapter has no dependency on the EclipseLink JPA > bundle. All of the API that it uses comes from EclipseLink Core, and > therefore when doing a provisioning resolve operation EclipseLink JPA is not > added! This needs to be fixed with a Require-Capability for EclipseLink JPA. > Require-Capability: > osgi.identity;filter:='(osgi.identity=org.eclipse.persistence.jpa)';effective:=active -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1649) Aries EclipseLink Adapter packaging issues
[ https://issues.apache.org/jira/browse/ARIES-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800799#comment-15800799 ] Timothy Ward commented on ARIES-1649: - > If I well understand, you mean that in the pom file the dependency from > org.eclipse.persistence.jpa should have the following version [2.1,3) No - this is definitely not a good idea. Using version ranges for a maven dependency does not work well, and is highly discouraged by the maven developers. The pom should pick a base supported version of EclipseLink and use that. The version of EclipseLink used should then *not* be upgraded over time unless explicitly necessary. > (it seems that it is not possible to use osgi.identity with > Require-Capability statement) This usage is explicitly allowed by the OSGi core specification (R6) in chapter 8 subsection 6. > Aries EclipseLink Adapter packaging issues > -- > > Key: ARIES-1649 > URL: https://issues.apache.org/jira/browse/ARIES-1649 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The Aries EclipseLink Adapter has two main problems: > 1. The package import ranges for the EclipseLink API are overly specific. The > latest release of the adapter only works with EclipseLink 2.6, even though > all of the APIs it uses were defined long before. This bundle should be built > against an older EclipseLink to ensure that Aries JPA doesn't force users to > upgrade EclipseLink unnecessarily. > 2. The Aries EclipseLink Adapter has no dependency on the EclipseLink JPA > bundle. All of the API that it uses comes from EclipseLink Core, and > therefore when doing a provisioning resolve operation EclipseLink JPA is not > added! This needs to be fixed with a Require-Capability for EclipseLink JPA. > Require-Capability: > osgi.identity;filter:='(osgi.identity=org.eclipse.persistence.jpa)';effective:=active -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1648) Aries JPA does not advertise EntityManagerFactoryBuilder or EntityManagerFactory services
[ https://issues.apache.org/jira/browse/ARIES-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15797996#comment-15797996 ] Timothy Ward commented on ARIES-1648: - The uses attributes are necessary for the resolver to do the correct wiring, even outside the framework uses constraints can ensure useful things. For example they can make sure that you don't end up with a second Aries JPA container which isn't in the same class space as the JPA provider! > 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.4#6332)
[jira] [Updated] (ARIES-1649) Aries EclipseLink Adapter packaging issues
[ https://issues.apache.org/jira/browse/ARIES-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1649: Assignee: Christian Schneider > Aries EclipseLink Adapter packaging issues > -- > > Key: ARIES-1649 > URL: https://issues.apache.org/jira/browse/ARIES-1649 > Project: Aries > Issue Type: Bug >Reporter: Timothy Ward >Assignee: Christian Schneider > > The Aries EclipseLink Adapter has two main problems: > 1. The package import ranges for the EclipseLink API are overly specific. The > latest release of the adapter only works with EclipseLink 2.6, even though > all of the APIs it uses were defined long before. This bundle should be built > against an older EclipseLink to ensure that Aries JPA doesn't force users to > upgrade EclipseLink unnecessarily. > 2. The Aries EclipseLink Adapter has no dependency on the EclipseLink JPA > bundle. All of the API that it uses comes from EclipseLink Core, and > therefore when doing a provisioning resolve operation EclipseLink JPA is not > added! This needs to be fixed with a Require-Capability for EclipseLink JPA. > Require-Capability: > osgi.identity;filter:='(osgi.identity=org.eclipse.persistence.jpa)';effective:=active -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1649) Aries EclipseLink Adapter packaging issues
Timothy Ward created ARIES-1649: --- Summary: Aries EclipseLink Adapter packaging issues Key: ARIES-1649 URL: https://issues.apache.org/jira/browse/ARIES-1649 Project: Aries Issue Type: Bug Reporter: Timothy Ward The Aries EclipseLink Adapter has two main problems: 1. The package import ranges for the EclipseLink API are overly specific. The latest release of the adapter only works with EclipseLink 2.6, even though all of the APIs it uses were defined long before. This bundle should be built against an older EclipseLink to ensure that Aries JPA doesn't force users to upgrade EclipseLink unnecessarily. 2. The Aries EclipseLink Adapter has no dependency on the EclipseLink JPA bundle. All of the API that it uses comes from EclipseLink Core, and therefore when doing a provisioning resolve operation EclipseLink JPA is not added! This needs to be fixed with a Require-Capability for EclipseLink JPA. Require-Capability: osgi.identity;filter:='(osgi.identity=org.eclipse.persistence.jpa)';effective:=active -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1648) Aries JPA does not advertise EntityManagerFactoryBuilder or EntityManagerFactory services
[ https://issues.apache.org/jira/browse/ARIES-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1648: Assignee: Christian Schneider > 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.4#6332)
[jira] [Created] (ARIES-1648) Aries JPA does not advertise EntityManagerFactoryBuilder or EntityManagerFactory services
Timothy Ward created ARIES-1648: --- Summary: 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 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.4#6332)
[jira] [Resolved] (ARIES-1647) Aries Local Tx Control bundle does not advertise the TransactionControl Service
[ https://issues.apache.org/jira/browse/ARIES-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1647. - Resolution: Fixed > Aries Local Tx Control bundle does not advertise the TransactionControl > Service > --- > > Key: ARIES-1647 > URL: https://issues.apache.org/jira/browse/ARIES-1647 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.2 >Reporter: Timothy Ward > Fix For: tx-control-0.0.3 > > > The Aries transaction control (local) implementation is missing a > Provide-Capability for the TransactionControl service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1647) Aries Local Tx Control bundle does not advertise the TransactionControl Service
Timothy Ward created ARIES-1647: --- Summary: Aries Local Tx Control bundle does not advertise the TransactionControl Service Key: ARIES-1647 URL: https://issues.apache.org/jira/browse/ARIES-1647 Project: Aries Issue Type: Bug Components: tx-control Affects Versions: tx-control-0.0.2 Reporter: Timothy Ward Fix For: tx-control-0.0.3 The Aries transaction control (local) implementation is missing a Provide-Capability for the TransactionControl service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed ARIES-1616. --- > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARIES-1617) Hikari pools are not closed by the JPA Resource Providers
[ https://issues.apache.org/jira/browse/ARIES-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed ARIES-1617. --- > Hikari pools are not closed by the JPA Resource Providers > - > > Key: ARIES-1617 > URL: https://issues.apache.org/jira/browse/ARIES-1617 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward > Fix For: tx-control-0.0.2 > > > When shutting down the Aries JPA Resource Provider (both XA and non XA) the > Hikari pool (if created) does not get closed. This leads to Hikari > maintenance threads being left running, which leaks class loaders and may > prevent framework shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARIES-1585) Transaction Control Connection Pool lifecycle issues
[ https://issues.apache.org/jira/browse/ARIES-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed ARIES-1585. --- > Transaction Control Connection Pool lifecycle issues > > > Key: ARIES-1585 > URL: https://issues.apache.org/jira/browse/ARIES-1585 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > The transaction control project creates numerous objects which consume > resources. Database Connection pools are a particular concern. > These must be cleaned up if/when: > 1. The resource factory service is unregistered/released by the bundle > 2. A configured resource provider configuration changes > 3. The Transaction control service is unregistered -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1585) Transaction Control Connection Pool lifecycle issues
[ https://issues.apache.org/jira/browse/ARIES-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1585. - Resolution: Fixed > Transaction Control Connection Pool lifecycle issues > > > Key: ARIES-1585 > URL: https://issues.apache.org/jira/browse/ARIES-1585 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > The transaction control project creates numerous objects which consume > resources. Database Connection pools are a particular concern. > These must be cleaned up if/when: > 1. The resource factory service is unregistered/released by the bundle > 2. A configured resource provider configuration changes > 3. The Transaction control service is unregistered -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1642) Aries JPA container cannot be used without Configuration Admin
Timothy Ward created ARIES-1642: --- Summary: Aries JPA container cannot be used without Configuration Admin Key: ARIES-1642 URL: https://issues.apache.org/jira/browse/ARIES-1642 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.5.0 Reporter: Timothy Ward The Aries JPA ManagedEMF registers a managed service factory for each "complete" EntityManagerFactory service. This isn't part of the JPA service specification, but does provide a nice way to fix up clients which don't use the EMFBuilder. The problem is that if no Config Admin is available in the framework then no EMF service is ever registered! The only call to createAndPublishEMF is from the updated method, and the updated method is only called if Config Admin is running! https://github.com/apache/aries/blob/d85be2b8f8a026cb1959c83ceb4ed812cd9d1279/jpa/jpa-container/src/main/java/org/apache/aries/jpa/container/impl/ManagedEMF.java#L128 Having a running Configuration Admin should not be a hard requirement for Aries JPA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1631) Aries JPA does not honour the javax.persistence.dataSource property
Timothy Ward created ARIES-1631: --- Summary: Aries JPA does not honour the javax.persistence.dataSource property Key: ARIES-1631 URL: https://issues.apache.org/jira/browse/ARIES-1631 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.4.0 Reporter: Timothy Ward Fix For: jpa-2.5.0 Section 9.7 of the JPA 2.1 specification defines properties that should be supported by the JPA provider. One of them is javax.persistence.dataSource The Aries EntityManagerFactoryBuilder implementation provides help for Persistence Providers, but does not pay attention to this property. It should be used to provide the non-jta datasource in the Persistence Unit info if no other non jta DataSource is provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1575) Aries JPA should use the persistence bundle's context to obtain the Persistence Provider service
[ https://issues.apache.org/jira/browse/ARIES-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601627#comment-15601627 ] Timothy Ward commented on ARIES-1575: - It's the tests in XAHibernate_5_0_9_Test in the Tx Control JPA integration test project. The tests would fail about 50% of the time, so a few runs should be sufficient to check. > Aries JPA should use the persistence bundle's context to obtain the > Persistence Provider service > > > Key: ARIES-1575 > URL: https://issues.apache.org/jira/browse/ARIES-1575 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.4.0 >Reporter: Timothy Ward >Assignee: Christian Schneider > Fix For: jpa-2.5.0 > > > Some JPA implementations (Hibernate) register a service factory for their > Persistence Provider and cache bundle-level data in the service. > Aries JPA always uses its own Bundle Context to do the service "get" which > confuses Hibernate into doing the wrong thing. This causes problems such as: > https://hibernate.atlassian.net/browse/HHH-10855 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1575) Aries JPA should use the persistence bundle's context to obtain the Persistence Provider service
[ https://issues.apache.org/jira/browse/ARIES-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595758#comment-15595758 ] Timothy Ward commented on ARIES-1575: - As long as it doesn't break the tests in Aries Transaction Control! > Aries JPA should use the persistence bundle's context to obtain the > Persistence Provider service > > > Key: ARIES-1575 > URL: https://issues.apache.org/jira/browse/ARIES-1575 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.4.0 >Reporter: Timothy Ward >Assignee: Christian Schneider > Fix For: jpa-2.5.0 > > > Some JPA implementations (Hibernate) register a service factory for their > Persistence Provider and cache bundle-level data in the service. > Aries JPA always uses its own Bundle Context to do the service "get" which > confuses Hibernate into doing the wrong thing. This causes problems such as: > https://hibernate.atlassian.net/browse/HHH-10855 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1617) Hikari pools are not closed by the JPA Resource Providers
[ https://issues.apache.org/jira/browse/ARIES-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1617. - Resolution: Fixed A range of fixes applied: revisions: 1764108, 1764109, 1764110, 1764111, 1764120 Together these common up much of the resource provider code to make it easier to do lifecycle tracking and prevent further leaks in the future. > Hikari pools are not closed by the JPA Resource Providers > - > > Key: ARIES-1617 > URL: https://issues.apache.org/jira/browse/ARIES-1617 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward > Fix For: tx-control-0.0.2 > > > When shutting down the Aries JPA Resource Provider (both XA and non XA) the > Hikari pool (if created) does not get closed. This leads to Hikari > maintenance threads being left running, which leaks class loaders and may > prevent framework shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562573#comment-15562573 ] Timothy Ward commented on ARIES-1616: - More mislabelled commits... ARIES-1617 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562575#comment-15562575 ] Timothy Ward commented on ARIES-1616: - More mislabelled commits... ARIES-1617 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562578#comment-15562578 ] Timothy Ward commented on ARIES-1616: - More mislabelled commits... ARIES-1617 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562572#comment-15562572 ] Timothy Ward commented on ARIES-1616: - More mislabelled commits... ARIES-1617 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1624) Aries JPA should tell provider tonot scan classes by default
[ https://issues.apache.org/jira/browse/ARIES-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15551343#comment-15551343 ] Timothy Ward commented on ARIES-1624: - This needs to be thought about carefully as it does represent a significant change in behaviour. Specifically, Aries JPA can only scan for the standard JPA annotations. JPA providers (e.g. Hibernate) may define their own additional annotations which Aries JPA will not know about. Currently Hibernate can scan to find those types, but the proposed change will break that behaviour. I'm not wild about "lying" to the Persistence Provider, but scanning is usually done pretty naively by JPA providers (i.e. expecting file: or jar: URL schemes) so we probably do need to do something like this. At the very least there should be a property that can be used to override this behaviour in the EntityManagerFactoryBuilder though. > Aries JPA should tell provider tonot scan classes by default > > > Key: ARIES-1624 > URL: https://issues.apache.org/jira/browse/ARIES-1624 > Project: Aries > Issue Type: Improvement > Components: JPA >Affects Versions: jpa-2.4.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.5.0 > > > As Aries JPA does the scanning itself it should always tell the > PersistenceProvider to not scan. > So it should set when calling it > true > https://github.com/apache/aries/blob/trunk/jpa/jpa-container/src/main/java/org/apache/aries/jpa/container/parser/impl/PersistenceUnit.java#L217 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1624) Aries JPA should tell provider tonot scan classes by default
[ https://issues.apache.org/jira/browse/ARIES-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15551342#comment-15551342 ] Timothy Ward commented on ARIES-1624: - This needs to be thought about carefully as it does represent a significant change in behaviour. Specifically, Aries JPA can only scan for the standard JPA annotations. JPA providers (e.g. Hibernate) may define their own additional annotations which Aries JPA will not know about. Currently Hibernate can scan to find those types, but the proposed change will break that behaviour. I'm not wild about "lying" to the Persistence Provider, but scanning is usually done pretty naively by JPA providers (i.e. expecting file: or jar: URL schemes) so we probably do need to do something like this. At the very least there should be a property that can be used to override this behaviour in the EntityManagerFactoryBuilder though. > Aries JPA should tell provider tonot scan classes by default > > > Key: ARIES-1624 > URL: https://issues.apache.org/jira/browse/ARIES-1624 > Project: Aries > Issue Type: Improvement > Components: JPA >Affects Versions: jpa-2.4.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.5.0 > > > As Aries JPA does the scanning itself it should always tell the > PersistenceProvider to not scan. > So it should set when calling it > true > https://github.com/apache/aries/blob/trunk/jpa/jpa-container/src/main/java/org/apache/aries/jpa/container/parser/impl/PersistenceUnit.java#L217 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed ARIES-1603. --- > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > Fix For: async-1.1.0 > > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1603. - Resolution: Fixed > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > Fix For: async-1.1.0 > > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1603: Fix Version/s: async-1.1.0 > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > Fix For: async-1.1.0 > > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1625) JPA inheritence Eclipselink - classloader issue ?!
[
https://issues.apache.org/jira/browse/ARIES-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15551321#comment-15551321
]
Timothy Ward commented on ARIES-1625:
-
{quote}
Generally I recommend to put all entities into the same bundle. Splitting them
typically leads to classloading problems.
{quote}
The OSGi JPA service specification also states this as a requirement.
Persistence bundles should contain the persistence descriptor and all of the
entity types. The data model and persistence unit are necessarily tightly
coupled to one another, and so shouldn't span module boundaries. If you do span
the persistence unit across multiple bundles then it is not required to work by
the spec. Some use cases do still work with Aries JPA and "split" persistence
units, but others do not.
> JPA inheritence Eclipselink - classloader issue ?!
> --
>
> Key: ARIES-1625
> URL: https://issues.apache.org/jira/browse/ARIES-1625
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Environment: Karaf 4.0.7 with Eclipselink:
> 330 | Active | 80 | 3.2.0.v201302191141 | EclipseLink ANTLR
> 331 | Active | 80 | 5.0.1.v201405080102 | EclipseLink ASM
> 332 | Active | 80 | 2.6.1.v20150916-55dc7c3 | EclipseLink Core
> 333 | Active | 80 | 2.6.1.v20150916-55dc7c3 | EclipseLink JPA
> 334 | Active | 80 | 2.6.1.v20150916-55dc7c3 | EclipseLink Hermes Parser
> and JPA support:
> 162 | Active | 80 | 2.3.0 | Apache Aries JPA Container API
> 163 | Active | 80 | 2.3.0 | Apache Aries JPA blueprint
> 164 | Active | 80 | 2.3.0 | Apache Aries JPA container
> 165 | Active | 80 | 2.3.0 | Apache Aries JPA support
> Java:
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> OS:
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.4 LTS
> Release: 14.04
> Codename: trusty
>Reporter: maciek
>Assignee: Christian Schneider
>
> I have jar with packaged entities in it.
> I have package *org.test.base* where I have class like:
> {code:title=BaseParameter.java|borderStyle=solid}
> package org.test.base;
> @Entity
> @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
> @DiscriminatorColumn(name = "TYPE")
> @Table(name = "PARAMETER")
> public abstract class BaseParameter implements Serializable {...
> @Id
> @SequenceGenerator(name = "ParameterIdGenerator", allocationSize = 1,
> sequenceName = "SEQ_PARAMETER_ID")
> @GeneratedValue(generator = "ParameterIdGenerator", strategy =
> GenerationType.SEQUENCE)
> @Column(name = "ID", nullable = false, precision = 20)
> protected Long id;
> {code}
> and another package *org.test.operation* in which I have concrete parameter
> for example:
> {code:title=SubscriptionParameter.java|borderStyle=solid}
> package org.test.operation
> @Entity
> @DiscriminatorValue("SUBSCRIPTION")
> public class SubscriptionParameter extends BaseParameter { .
> {code}
> I am using example from
> https://github.com/apache/aries/tree/trunk/jpa/examples
> to get to my entities using DS module but of course I modified it to fit my
> model.
> Commands I do are:
> install -s mvn:pl.orange.isep/my-model/0.1-SNAPSHOT -> OK
> install -s
> mvn:org.apache.aries.jpa.example/org.apache.aries.jpa.example.tasklist.model/3.0.0-SNAPSHOT
> and then the exception arises:
> {code:title=Exception|borderStyle=solid}
> org.apache.aries.jpa/org.apache.aries.jpa.container/2.3.0]: Unexpected
> problem updating configuration org.apache.aries.jpa.tasklist
> javax.persistence.PersistenceException: Exception [EclipseLink-28018]
> (Eclipse Persistence Services - 2.6.1.v20150916-55dc7c3):
> org.eclipse.persistence.exceptions.EntityManagerSetupException
> Exception Description: Predeployment of PersistenceUnit [tasklist] failed.
> Internal Exception: Exception [EclipseLink-7161] (Eclipse Persistence
> Services - 2.6.1.v20150916-55dc7c3):
> org.eclipse.persistence.exceptions.ValidationException
> Exception Description: Entity class [class
> org.test.operation.SubscriptionParameter] has no primary key specified. It
> should define either an @Id, @EmbeddedId or an @IdClass. If you have defined
> PK using any of these annotations then make sure that you do not have mixed
> access-type (both fields and properties annotated) in your entity class
> hierarchy.
> at
> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.createPredeployFailedPersistenceException(EntityManagerSetupImpl.java:2035)[333:org.eclipse.persistence.jpa:2.6.1.v20150916-55dc7c3]
> at
> org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:2026)[333:org.eclipse.persistence.jpa:2.6.1.v20150916-55dc7c3]
> at
> org.eclipse.persistence.jpa.Pers
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[
https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512484#comment-15512484
]
Timothy Ward commented on ARIES-1613:
-
{quote}
The people responsible for security often like to avoid connections that are
initiated from the outside or dmz and have a target in the intranet.
{quote}
Any request made to the front end that requires information from the back end
must initiate a connection from DMZ to the intranet. I agree that the number of
connections should be minimised and the firewall as strict as possible, but it
can't be avoided entirely.
{quote}
The feeding mechanism could either be driven by the individual intranet servers
that host the services or by a separate bridge software that only talks with
the two zookeeper instances. I think it makes sense for us to at least design
both scenarios. I personally do not currently plan to implement any scenario
but maybe someone can jump in there.
For me the important part is that we provide the hooks in Aries RSA so such an
implementation can be plugged in at any time.
{quote}
This model is already provided by the RSA specification. If you want to have
two separate discovery providers configured then you can! Simply do the
following:
1. Have the Exporting Remote Service Admin generate two Endpoint Descriptions,
one which is "secure" (i.e. uses the proxy) and one which is not
2. Have two configured discovery providers, one which is for the dmz, and has a
"(secure=true)" (or equivalent) filter on its EndpointEventListener, and
another discovery for the internal zookeeper
3. Configure the "internal" Topology managers to prefer the internal endpoint
to the secure endpoint
In this model the internal servers have the choice of what they use and the DMZ
servers never discover anything other than the "secure" endpoint.
I'm not sure that I agree that this is more secure than the model where the DMZ
topology manager chooses to ignore the internal endpoints, as you have a much
bigger DMZ attack surface (an extra zookeeper which is trusted by the internal
network), but it does what you're asking. Importantly, Aries doesn't need (and
shouldn't have) special hooks to solve this, otherwise you end up with Aries
RSA not interoperating with other implementations.
> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
> Issue Type: Bug
> Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0)
> which makes it impossible to implement 3rd party discovery plugins.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512454#comment-15512454 ] Timothy Ward commented on ARIES-1616: - Mislabelled - this should point at ARIES-1617 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1617) Hikari pools are not closed by the JPA Resource Providers
[ https://issues.apache.org/jira/browse/ARIES-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512453#comment-15512453 ] Timothy Ward commented on ARIES-1617: - A Mislabeled commit was attached to the wrong JIRA Commit 1761786 from Timothy Ward in branch 'aries/trunk' [ https://svn.apache.org/r1761786 ] ARIES-1616 Clean up Local JPA resources properly > Hikari pools are not closed by the JPA Resource Providers > - > > Key: ARIES-1617 > URL: https://issues.apache.org/jira/browse/ARIES-1617 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward > Fix For: tx-control-0.0.2 > > > When shutting down the Aries JPA Resource Provider (both XA and non XA) the > Hikari pool (if created) does not get closed. This leads to Hikari > maintenance threads being left running, which leaks class loaders and may > prevent framework shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512415#comment-15512415 ] Timothy Ward commented on ARIES-1613: - A lot of this depends on how you define the boundary of the private network. The back end servers are obviously in the private network, and the front end servers are obviously publicly accessible, but in order for the front end to talk to the back end the front end must also be in the private network. This would typically be called a DMZ. It is not possible to avoid using private addresses in the DMZ (it's the only way for the front end to talk to the back end) - so does this really constitute internal addresses being exposed outside the private network? I assume that the ZooKeeper server is inside the private network and not the DMZ? If so then the front end systems must be configured with the internal address of the ZooKeeper to contact it, and you already have an internal address used in the DMZ (a pretty normal state of affairs). The firewall would need to allow this access and I assume that there is some security set up for the ZooKeeper. At this point the only way for private addresses from discovery to escape is for someone to break into the DMZ and either: * Hack the ZooKeeper * Exfiltrate information from the running JVM Both of these are relatively hard to do (assuming you have decent credential management) and rely on the fact that you've already been hacked (they have access to your DMZ). If the ZooKeeper is inside the DMZ then it needs to be more highly secured, and probably should not be used for your back-end discovery at all because it is at risk of direct hacking. This would have a much greater risk of address leakage and puts you into the "two ZooKeeper" model if you want to be safe. > DiscoveryPlugin interface not exported > -- > > Key: ARIES-1613 > URL: https://issues.apache.org/jira/browse/ARIES-1613 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1617) Hikari pools are not closed by the JPA Resource Providers
Timothy Ward created ARIES-1617: --- Summary: Hikari pools are not closed by the JPA Resource Providers Key: ARIES-1617 URL: https://issues.apache.org/jira/browse/ARIES-1617 Project: Aries Issue Type: Bug Components: tx-control Affects Versions: tx-control-0.0.1 Reporter: Timothy Ward Fix For: tx-control-0.0.2 When shutting down the Aries JPA Resource Provider (both XA and non XA) the Hikari pool (if created) does not get closed. This leads to Hikari maintenance threads being left running, which leaks class loaders and may prevent framework shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509671#comment-15509671 ] Timothy Ward commented on ARIES-1613: - The topology manager has the ability to override service properties, see https://osgi.org/javadoc/r6/enterprise/org/osgi/service/remoteserviceadmin/RemoteServiceAdmin.html#exportService(org.osgi.framework.ServiceReference,%20java.util.Map) You are correct that the Topology Manager cannot override properties created by the Distribution provider (which don't exist) but that is correct. The Distribution provider understands its own properties better than the Topology Manager ever can. In the case where a different URL is available it needs to be the Distribution Provider which indicates that by providing an extra ExportRegistration in the returned list. > DiscoveryPlugin interface not exported > -- > > Key: ARIES-1613 > URL: https://issues.apache.org/jira/browse/ARIES-1613 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509511#comment-15509511 ] Timothy Ward commented on ARIES-1613: - > From a security standpoint I think the only good solution for your case is to > have two separate zookeeper instances and a bridge between them that does the > filtering and proxy setup. With one zookeeper it would be very difficult to > hide some of the information. I honestly believe that this is overkill - firewalls and filters which check origin IP addresses can protect the raw endpoint, which should really be on a private network anyway. The Endpoint information in zookeeper should be "private" to the discovery layer and used correctly by the client Topology Manager. > DiscoveryPlugin interface not exported > -- > > Key: ARIES-1613 > URL: https://issues.apache.org/jira/browse/ARIES-1613 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509504#comment-15509504 ] Timothy Ward commented on ARIES-1613: - > If I understood correctly, "remote Topology Manager" is the one running on > the remote client, right? There are two topology managers installed, one on the "server" side and one on the "client" side. The "server" topology manager is the one who can add extra properties when exporting the service, and who gets to decide the following things: 1. Which distribution providers should be used for export 2. What extra properties should be exported alongside the service properties 3. Which endpoint descriptions should be sent to the local Endpoint Event Listeners in the framework 4. What to do on endpoint faliure The "client" topology manager receives endpoint notifications from discovery, which should be passing the Endpoints unadulterated and can: 1. Decide to import, ignore or save an endpoint description for later 2. Decide which distribution provider(s) to try importing the service with 3. What to do on endpoint failure > it would be nice (at least from security, or hardening, perspective) that > they did not know anything about (i.e. they do not see) the "raw" > EndpointDescription. The correct place to do the security check here is in a firewall and/or filter on the "raw" servlet, to check access is not from outside, otherwise someone could simply guess the URL. Also, by choosing to ignore the raw URL it remains invisible as a service (i.e. no imported OSGi service exists). If you really want to partition your discovery space then what you need are two discovery providers (or two configurations of the same discovery provider) which have different discovery domains. Again, these would not change the endpoint properties, but the server topology can determine which EndpointEventListener is called for which EndpointDescription. > DiscoveryPlugin interface not exported > -- > > Key: ARIES-1613 > URL: https://issues.apache.org/jira/browse/ARIES-1613 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/ARIES-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509427#comment-15509427 ] Timothy Ward commented on ARIES-1613: - Discovery providers should not be changing the properties defined by an EndpointDescription. The Topology Manager is responsible for adding extra properties when making the export from RemoteServiceAdmin. Changing the properties in the Discovery layer is a good way to break other RSA implementations. The sort of behaviour that you're actually asking for (the ability to supply an "external" URL) should really be part of the RSA distribution provider. The provider should create a proxied EndpointDescription and a "raw" EndpointDescription, the remote Topology Manager can then decide which (or both) should be imported. > DiscoveryPlugin interface not exported > -- > > Key: ARIES-1613 > URL: https://issues.apache.org/jira/browse/ARIES-1613 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1616) Transaction Recovery Log does not shut down properly
[ https://issues.apache.org/jira/browse/ARIES-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1616. - Resolution: Fixed Fixed with tests in r1761694 > Transaction Recovery Log does not shut down properly > > > Key: ARIES-1616 > URL: https://issues.apache.org/jira/browse/ARIES-1616 > Project: Aries > Issue Type: Bug > Components: tx-control >Affects Versions: tx-control-0.0.1 >Reporter: Timothy Ward >Assignee: Timothy Ward > Fix For: tx-control-0.0.2 > > > After shutting down or reconfiguring the XA Transaction Control > implementation a daemon thread is left running from the HOWL Flush manager. > This never seems to get closed... > This is likely a bug in HOWL, but that project hasn't been updated in a > decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1616) Transaction Recovery Log does not shut down properly
Timothy Ward created ARIES-1616: --- Summary: Transaction Recovery Log does not shut down properly Key: ARIES-1616 URL: https://issues.apache.org/jira/browse/ARIES-1616 Project: Aries Issue Type: Bug Components: tx-control Affects Versions: tx-control-0.0.1 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: tx-control-0.0.2 After shutting down or reconfiguring the XA Transaction Control implementation a daemon thread is left running from the HOWL Flush manager. This never seems to get closed... This is likely a bug in HOWL, but that project hasn't been updated in a decade so Aries will have to work around it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502955#comment-15502955 ] Timothy Ward commented on ARIES-1603: - The simple answer was that it wasn't - a tidy up before the commit removed the magic line needed. I've fixed that, and added unit tests to prove that the cache is being used, both for interfaces and classes. > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488098#comment-15488098 ] Timothy Ward commented on ARIES-1603: - bq. What is the purpose of the classloader clone? The prevent an execution after a service shutdown? The class loader clone exists for a few reasons: * For consistency with the class type mediation that requires a class loader clone for CGLib * To avoid future issues if/when additional types need to be referenced by the proxy * To avoid lifecycle issues if the async service is uninstalled - using the raw bundle's class loader would leave proxy types defined on it after the Async bundle was removed from the system. Technically the way in which the code is written is not leaking class loaders. A different class loader is used for each mediation, but these will all be eligible for garbage collection as soon as the mediator is garbage collected. Mediators are intended to be cached and reused but if the application code makes a lot of them and holds onto them then that will cause a lot of ClassLoaders to be created. In your application's case I'm not sure where the mediators end up being held, but that's the reason that an OOM occurs. This may indicate a leak in the application, or just a high load of concurrent tasks that should be throttled more carefully. Obviously the application code needs some attention, but having looked more deeply at this the Async service *may* be able to weakly cache the class loader to be used for mediation. This should dramatically reduce the memory overhead for your application (although it won't fix a leak in it if there is one) and help with the scaling. > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1603) Aries async classloader leak
[ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470662#comment-15470662 ] Timothy Ward commented on ARIES-1603: - Could you include a sample of the usage here? I'm very surprised to hear that you're creating so many mediated classes, as you're really supposed to create one and keep using it (it's thread safe). In addition the Async service doesn't hold on to the mediator object except when the async task is executing. Also, what sort of load management are you doing in the application? Is it possible that the memory problem is due to a large and growing queue of asynchronous tasks waiting to execute? > Aries async classloader leak > > > Key: ARIES-1603 > URL: https://issues.apache.org/jira/browse/ARIES-1603 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > Using the async service with repeated tasks during one hour leads to an out > of memory. It's due to the very large amount of class loaded (in 10 min we > get 2 classes loaded). The metaspace is growing indefinitely. > It seems to come from the privMediate method of the AsyncService where the > classloader of the target service is cloned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1604) Aries async Thread leak
[ https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved ARIES-1604. - Resolution: Fixed I believe that this issue should be fixed in the latest 1.1.0-SNAPSHOT > Aries async Thread leak > --- > > Key: ARIES-1604 > URL: https://issues.apache.org/jira/browse/ARIES-1604 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > Fix For: async-1.1.0 > > > The async service with repeated tasks leads to an OutOfMemoryError because > too many threads are created and we achieve the maximum number of threads of > the host (unable to create new native thread). > The leak seems to come from the PromiseImpl. For each Promise instantiated, > we do create a new SingleThreadExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARIES-1604) Aries async Thread leak
[
https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470615#comment-15470615
]
Timothy Ward edited comment on ARIES-1604 at 9/7/16 1:20 PM:
-
{quote}I thought the same when I saw the implementation but they're not
unfortunately. Anyway, you're right I think. It could be more efficient to
reuse the same executor instance for the promises.{quote}
I've checked this, and because Executors.newSingleThreadExecutor() is used then
the Thread *will* be stopped when the Promise is garbage collected. The problem
will show up when the Promise creation rate it too high, which should be much
less of a problem in the latest snapshot.
The snapshot versions of promise.api, async.impl and async are now
1.1.0-SNAPSHOT due to the change in API.
was (Author: timothyjward):
> I thought the same when I saw the implementation but they're not
> unfortunately. Anyway, you're right I think. It could be more efficient to
> reuse the same executor instance for the promises.
I've checked this, and because Executors.newSingleThreadExecutor() is used then
the Thread *will* be stopped when the Promise is garbage collected. The problem
will show up when the Promise creation rate it too high, which should be much
less of a problem in the latest snapshot.
The snapshot versions of promise.api, async.impl and async are now
1.1.0-SNAPSHOT due to the change in API.
> Aries async Thread leak
> ---
>
> Key: ARIES-1604
> URL: https://issues.apache.org/jira/browse/ARIES-1604
> Project: Aries
> Issue Type: Bug
>Affects Versions: async-1.0.2
>Reporter: Paul Thevenot
> Fix For: async-1.1.0
>
>
> The async service with repeated tasks leads to an OutOfMemoryError because
> too many threads are created and we achieve the maximum number of threads of
> the host (unable to create new native thread).
> The leak seems to come from the PromiseImpl. For each Promise instantiated,
> we do create a new SingleThreadExecutor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1604) Aries async Thread leak
[ https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated ARIES-1604: Fix Version/s: async-1.1.0 > Aries async Thread leak > --- > > Key: ARIES-1604 > URL: https://issues.apache.org/jira/browse/ARIES-1604 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > Fix For: async-1.1.0 > > > The async service with repeated tasks leads to an OutOfMemoryError because > too many threads are created and we achieve the maximum number of threads of > the host (unable to create new native thread). > The leak seems to come from the PromiseImpl. For each Promise instantiated, > we do create a new SingleThreadExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1604) Aries async Thread leak
[ https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470615#comment-15470615 ] Timothy Ward commented on ARIES-1604: - > I thought the same when I saw the implementation but they're not > unfortunately. Anyway, you're right I think. It could be more efficient to > reuse the same executor instance for the promises. I've checked this, and because Executors.newSingleThreadExecutor() is used then the Thread *will* be stopped when the Promise is garbage collected. The problem will show up when the Promise creation rate it too high, which should be much less of a problem in the latest snapshot. The snapshot versions of promise.api, async.impl and async are now 1.1.0-SNAPSHOT due to the change in API. > Aries async Thread leak > --- > > Key: ARIES-1604 > URL: https://issues.apache.org/jira/browse/ARIES-1604 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > The async service with repeated tasks leads to an OutOfMemoryError because > too many threads are created and we achieve the maximum number of threads of > the host (unable to create new native thread). > The leak seems to come from the PromiseImpl. For each Promise instantiated, > we do create a new SingleThreadExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1604) Aries async Thread leak
[ https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470604#comment-15470604 ] Timothy Ward commented on ARIES-1604: - A fix has been added in commit r1759531 - this causes chained promises to reuse their parent executor, and allows an executor to be passed instead of creating one per promise. The Async Service has been updated to use its own threadpool for all the promises it creates. This should keep a lid on the thread creation rate. > Aries async Thread leak > --- > > Key: ARIES-1604 > URL: https://issues.apache.org/jira/browse/ARIES-1604 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > The async service with repeated tasks leads to an OutOfMemoryError because > too many threads are created and we achieve the maximum number of threads of > the host (unable to create new native thread). > The leak seems to come from the PromiseImpl. For each Promise instantiated, > we do create a new SingleThreadExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1604) Aries async Thread leak
[ https://issues.apache.org/jira/browse/ARIES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468986#comment-15468986 ] Timothy Ward commented on ARIES-1604: - I would hope that these threads would be terminated when the promise is garbage collected, but we could also be a little more efficient with the executor usage (for example by reusing the executor when chaining). > Aries async Thread leak > --- > > Key: ARIES-1604 > URL: https://issues.apache.org/jira/browse/ARIES-1604 > Project: Aries > Issue Type: Bug >Affects Versions: async-1.0.2 >Reporter: Paul Thevenot > > The async service with repeated tasks leads to an OutOfMemoryError because > too many threads are created and we achieve the maximum number of threads of > the host (unable to create new native thread). > The leak seems to come from the PromiseImpl. For each Promise instantiated, > we do create a new SingleThreadExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
