[jira] [Commented] (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:comment-tabpanel=16655444#comment-16655444 ] Daniel Kulp commented on ARIES-1848: whiteboard really should be split into two versions: 1) What we have today - fully self contained. Easy to install/use. 2) Version that properly uses CXF's packaging and JAX-RS runtime and features. Right now, installing whiteboard can completely break other CXF/JAX-RS applications running in a container. You have to completely move everything over to whiteboard or not use whiteboard. That's kind of a sucky option. (and part of the issue is with the JAX-RS spec itself keeping an implementation in a static in the spec api jar so two implementation cannot co-exist nicely together) > 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] [Resolved] (ARIES-791) Blueprint 0.4 is not backwords compatible in ways that break CXF
[ https://issues.apache.org/jira/browse/ARIES-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-791. --- Resolution: Fixed Enough was fixed to allow CXF to work. CXF uses some reflection to work around the rest, although that is likely irrelevant now as CXF no longer supports the old versions of Karaf that would use the old blueprint versions. Blueprint 0.4 is not backwords compatible in ways that break CXF Key: ARIES-791 URL: https://issues.apache.org/jira/browse/ARIES-791 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Some of the changes in 0.4 of blueprint cause CXF to break. These include: 1) Marking container, di, and util as private. CXF needs these to configure objects. (see ARIES-790) 2) Removal of BundleDelegatingClassLoader 3) Moving of ExtendedBlueprintContainer into services subpackage We really need a version of blueprint that tries to be as backwords compatible as possible (to allow existing users to upgrade without breaking applications), but also provide the new API's (deprecate the old ones) so that projects like CXF can update to new API's. When 0.4.1 is out for a while and most users/dependencies have updated, THEN remove the breaking changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1293) Help custom namespace handlers that would like bean references..
[
https://issues.apache.org/jira/browse/ARIES-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-1293.
Resolution: Fixed
Fix Version/s: blueprint-core-1.4.2
Assignee: Daniel Kulp
Help custom namespace handlers that would like bean references..
Key: ARIES-1293
URL: https://issues.apache.org/jira/browse/ARIES-1293
Project: Aries
Issue Type: Bug
Components: Blueprint
Reporter: Daniel Kulp
Assignee: Daniel Kulp
Fix For: blueprint-core-1.4.2
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other
object to be defined by the user. This works well in Spring/Spring-DM as
you can define an object there via the normal Spring bean element.
However, blueprint.xsd does NOT have a top level bean element that can be
referenced.Thus, with the above schema, you can only use objects that can
be created via custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1293) Help custom namespace handlers that would like bean references..
[
https://issues.apache.org/jira/browse/ARIES-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated ARIES-1293:
---
Description:
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other object
to be defined by the user. This works well in Spring/Spring-DM as you can
define an object there via the normal Spring bean element. However,
blueprint.xsd does NOT have a top level bean element that can be referenced.
Thus, with the above schema, you can only use objects that can be created via
custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
was:
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other object
to be defined by the user. This works well in Spring/Spring-DM as you can
define an object there via the normal Spring bean element. However,
blueprint.xsd does NOT have a top level bean element that can be referenced.
Thus, with the above schema, you can only use objects that can be created via
custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
Help custom namespace handlers that would like bean references..
Key: ARIES-1293
URL: https://issues.apache.org/jira/browse/ARIES-1293
Project: Aries
Issue Type: Bug
Components: Blueprint
Reporter: Daniel Kulp
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other
object to be defined by the user. This works well in Spring/Spring-DM as
you can define an object there via the normal Spring bean element.
However, blueprint.xsd does NOT have a top level bean element that can be
referenced.Thus, with the above schema, you can only use objects that can
be created via custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1203) Build error specifying old snapshot version for versioning.plugin
[ https://issues.apache.org/jira/browse/ARIES-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1203. Resolution: Fixed Assignee: Daniel Kulp Moved to the 0.2.0 release Build error specifying old snapshot version for versioning.plugin - Key: ARIES-1203 URL: https://issues.apache.org/jira/browse/ARIES-1203 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Neil Richards Assignee: Daniel Kulp Attachments: ARIES-1203-blueprint-plugin-version-fix.patch I've been trying to compile the latest code from: https://svn.apache.org/repos/asf/aries/trunk (revision 1599264) following the Just build it - no Eclipse instructions: http://aries.apache.org/development/buildingaries.html The last step (mvn -Dmaven.test.skip=true install) is failing with the following error: [ERROR] Plugin org.apache.aries.versioning:org.apache.aries.versioning.plugin:0.2.0-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.aries.versioning:org.apache.aries.versioning.plugin:jar:0.2.0-SNAPSHOT: Could not find artifact org.apache.aries.versioning:org.apache.aries.versioning.plugin:pom:0.2.0-SNAPSHOT in apache.snapshots (https://repository.apache.org/content/groups/snapshots-group) - [Help 1] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (ARIES-1186) Upgrade proxy-impl to ASM 5 for Java 8 support
[
https://issues.apache.org/jira/browse/ARIES-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-1186.
Resolution: Fixed
Fix Version/s: proxy-impl-1.0.3
Assignee: Daniel Kulp
Pull request pulled
Upgrade proxy-impl to ASM 5 for Java 8 support
--
Key: ARIES-1186
URL: https://issues.apache.org/jira/browse/ARIES-1186
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.2
Reporter: Harald Wellmann
Assignee: Daniel Kulp
Priority: Critical
Fix For: proxy-impl-1.0.3
Aries Proxy does not work under Java 8, since it depends on ASM 4 which does
not support Java 8.
This is currently a blocker for working with Karaf 3.0.1 under Java 8. (Karaf
contains Aries Proxy Impl 1.0.2).
Upgrading to ASM 5.0.2 requires changing a few {{super()}} calls in Aries
subclasses of ASM classes.
I tried a local build of Aries Proxy Impl 1.0.3-SNAPSHOT with these changes,
and the result seems to be ok for Karaf.
The larger part of the issue on Aries side is the dependency on a prehistoric
version of Pax Exam which depends on Pax Runner (with additional
configuration tweaks from Aries) which does not support Java 8 either, so I
haven't been able to run the Proxy integration tests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (ARIES-1186) Upgrade proxy-impl to ASM 5 for Java 8 support
[
https://issues.apache.org/jira/browse/ARIES-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated ARIES-1186:
---
Summary: Upgrade proxy-impl to ASM 5 for Java 8 support (was: Upgrade to
ASM 5 for Java 8 support)
Upgrade proxy-impl to ASM 5 for Java 8 support
--
Key: ARIES-1186
URL: https://issues.apache.org/jira/browse/ARIES-1186
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.2
Reporter: Harald Wellmann
Priority: Critical
Fix For: proxy-impl-1.0.3
Aries Proxy does not work under Java 8, since it depends on ASM 4 which does
not support Java 8.
This is currently a blocker for working with Karaf 3.0.1 under Java 8. (Karaf
contains Aries Proxy Impl 1.0.2).
Upgrading to ASM 5.0.2 requires changing a few {{super()}} calls in Aries
subclasses of ASM classes.
I tried a local build of Aries Proxy Impl 1.0.3-SNAPSHOT with these changes,
and the result seems to be ok for Karaf.
The larger part of the issue on Aries side is the dependency on a prehistoric
version of Pax Exam which depends on Pax Runner (with additional
configuration tweaks from Aries) which does not support Java 8 either, so I
haven't been able to run the Proxy integration tests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (ARIES-915) The CM module for managed-service-factory does not perform the update correct with embedded managed-properties
[
https://issues.apache.org/jira/browse/ARIES-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-915.
---
Resolution: Fixed
Fix Version/s: blueprint-cm-1.0.4
Assignee: Daniel Kulp
Pull request applied.
Note: in future, please make sure all non-aries snapshots are eliminated before
making a pull request.
The CM module for managed-service-factory does not perform the update correct
with embedded managed-properties
--
Key: ARIES-915
URL: https://issues.apache.org/jira/browse/ARIES-915
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: 0.3
Reporter: Christoph Läubrich
Assignee: Daniel Kulp
Fix For: blueprint-cm-1.0.4
Attachments: ManagedServiceFactoryTest.java
I'm using the following test case:
{code:xml}?xml version=1.0 encoding=UTF-8?
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:cm=http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
cm:managed-service-factory id=testfactory
factory-pid=testfactory interface=test.FactoryTest
auto-export=all-classes
cm:managed-component
class=test.FactoryTest
init-method=init
cm:managed-properties persistent-id=
update-strategy=component-managed update-method=update/
/cm:managed-component
/cm:managed-service-factory
/blueprint{code}
The testclass just print out to the log:{code:java}public class FactoryTest {
private static final Logger LOG =
LoggerFactory.getLogger(FactoryTest.class);
public FactoryTest() {
LOG.info({}: FactoryTest.FactoryTest(),
System.identityHashCode(this));
}
public void init() {
// LOG.info({}: FactoryTest.init(), System.identityHashCode(this));
}
public void update(MapString, ? props) {
LOG.info({}: FactoryTest.update() props = {},
System.identityHashCode(this), props);
}
}{code}
The logfile looks like this, I have reodereded the log output so each
instance is one block:{code}karaf@root log:display
2012-09-04 09:36:30,660 | INFO | rint Extender: 2 | FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.FactoryTest()
2012-09-04 09:36:30,675 | INFO | Thread-91| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo4,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-4.cfg,
service.pid=testfactory.8e97399a-940e-49c3-ae75-3e720951774a}
2012-09-04 09:36:30,677 | INFO | Thread-92| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,688 | INFO | Thread-93| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo2,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-2.cfg,
service.pid=testfactory.139e87cd-7f73-4dab-8289-af5e6be91ba5}
2012-09-04 09:36:30,697 | INFO | Thread-94| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo2,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-2.cfg,
service.pid=testfactory.139e87cd-7f73-4dab-8289-af5e6be91ba5}
2012-09-04 09:36:30,699 | INFO | Thread-96| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo1,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-1.cfg,
service.pid=testfactory.c5b988ec-8747-4354-84b4-5613a60b6ab1}
2012-09-04 09:36:30,703 | INFO | Thread-95| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,703 | INFO | Thread-95| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 7131715: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,668 | INFO | rint Extender: 2 |
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847598#comment-13847598
]
Daniel Kulp commented on ARIES-1140:
Actually, I *THINK* this might be doable if we allow the
ext:proxy-method=greedy on the reference element as well as just the
reference-list. Right now, it's only allowed on the reference-list. If the
service is registered with multiple interfaces, if you use a reference-list
and set the proxy-method to greedy, I believe it would create proxies that
implement all the interfaces. I need to double check that, but it looks that
way in the code. I'm not sure why the greedy is not allowed for reference.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847604#comment-13847604
]
Daniel Kulp commented on ARIES-1140:
Oh, right. reference-list allows it cause the list only represents the actual
live services so we can get that information. For reference, the service
might not be there yet. That makes sense.
Yea, I'm thinking adding an element to the ext namespace for adding
additional interfaces onto the reference proxy may be the best/simplest way to
go.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (ARIES-1141) Allow reference to reference (and filter) services with multiple interfaces
Daniel Kulp created ARIES-1141: -- Summary: Allow reference to reference (and filter) services with multiple interfaces Key: ARIES-1141 URL: https://issues.apache.org/jira/browse/ARIES-1141 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Related to ARIES-1140. A service can be registered with multiple classes/interfaces. However, a reference can only use a single interface for the lookup. In some cases, it would be good to provide (via the ext namespace) a way for a reference to no only implement those additional interfaces, but also restrict the reference to services that implement all of the extra interfaces. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847702#comment-13847702
]
Daniel Kulp commented on ARIES-1140:
I've pulled the enhancement request out of this into a new JIRA that can be
tracked as part of the blueprint component since that part is blueprint and not
proxy.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated ARIES-1140:
---
Description:
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing BindingProvider
interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
was:
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846509#comment-13846509
]
Daniel Kulp commented on ARIES-1140:
I *think* the only thing you could do would be to register a second service
reference:
service ref=crmClientBindingProvider
interface=javax.xml.ws.BindingProvider /
and inject that in as well. That would likely be a bit fragile as you could
have many BindingProvider services. You'd probably want to stick a property
on there to identify the other service it's associated with.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (ARIES-1126) Weave hook could NPE
[
https://issues.apache.org/jira/browse/ARIES-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-1126.
Resolution: Fixed
Fix Version/s: proxy-impl-1.0.2
Weave hook could NPE
Key: ARIES-1126
URL: https://issues.apache.org/jira/browse/ARIES-1126
Project: Aries
Issue Type: Bug
Components: Proxy
Reporter: Daniel Kulp
Assignee: Daniel Kulp
Fix For: proxy-impl-1.0.2
In some non-reproducible cases with Equinox (likely during a refresh, but not
really sure), the call at the first line of weave of:
{code:java}
Bundle b = wovenClass.getBundleWiring().getBundle();
{code}
can NPE due to the bundle wiring being null. This will result in bundles not
starting at all. There is no way to work around this.
Two part proposed fix:
1) Check for null there and if null, don't do the bundle check. Note: if
we DO have to weave, we do still need the wiring for the loader later.
2) If the enabled flag is set to none, don't register the hook at all.
We know nothing will be weaved by the hook so don't bother.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (ARIES-1124) Extend blueprint-cm import range for blueprint-core
[ https://issues.apache.org/jira/browse/ARIES-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1124. Resolution: Fixed Assignee: Daniel Kulp Extend blueprint-cm import range for blueprint-core --- Key: ARIES-1124 URL: https://issues.apache.org/jira/browse/ARIES-1124 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp Attachments: ARIES-1124.patch blueprint-cm 1.0.1 is not compatible with the new blueprint-core 1.2.0 bundle. blueprint-cm defines import to org.apache.aries.blueprint with the [1.0, 1.2). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ARIES-1125) Update to blueprint-core 1.2.0 in aries modules
[ https://issues.apache.org/jira/browse/ARIES-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1125. Resolution: Fixed Assignee: Daniel Kulp Update to blueprint-core 1.2.0 in aries modules --- Key: ARIES-1125 URL: https://issues.apache.org/jira/browse/ARIES-1125 Project: Aries Issue Type: Improvement Components: Application, Blueprint, JPA Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp Attachments: ARIES-1125.patch As blueprint-core 1.2.0 has been release, for consistency, we can upgrade the other Aries modules to use this blueprint-core version. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ARIES-1120) getComponentIds returns the context/bundle/etc... even during a reset
Daniel Kulp created ARIES-1120: -- Summary: getComponentIds returns the context/bundle/etc... even during a reset Key: ARIES-1120 URL: https://issues.apache.org/jira/browse/ARIES-1120 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp A bundle refresh will cause the componentDefinitionRegistry to be reset() (which is OK). However, if a call is made to getComponentIds() between the reset call and the call to populate the registry, the returned Set contains entries for blueprintContainer, blueprintBundle, blueprintBundleContext, and blueprintConverter. If you then try to lookup the metadata for those, an exception is thrown. Likely the call to getComponentIds() should not automatically add those. In addition, immediately after reset, we should re-add those to make sure they are available. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ARIES-1120) getComponentIds returns the context/bundle/etc... even during a reset
[ https://issues.apache.org/jira/browse/ARIES-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1120. Resolution: Fixed Fix Version/s: blueprint-core-1.2.1 getComponentIds returns the context/bundle/etc... even during a reset - Key: ARIES-1120 URL: https://issues.apache.org/jira/browse/ARIES-1120 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: blueprint-core-1.2.1 A bundle refresh will cause the componentDefinitionRegistry to be reset() (which is OK). However, if a call is made to getComponentIds() between the reset call and the call to populate the registry, the returned Set contains entries for blueprintContainer, blueprintBundle, blueprintBundleContext, and blueprintConverter. If you then try to lookup the metadata for those, an exception is thrown. Likely the call to getComponentIds() should not automatically add those. In addition, immediately after reset, we should re-add those to make sure they are available. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ARIES-1118) Provide common schema for XML namespace
Daniel Kulp created ARIES-1118: -- Summary: Provide common schema for XML namespace Key: ARIES-1118 URL: https://issues.apache.org/jira/browse/ARIES-1118 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp And schema that uses the xml namespace things (xml:lang, xml:base, etc...) needs to import http://www.w3.org/XML/1998/namespace. Blueprint could provide a Namespace handler for that namespace to avoid having a bunch of different bundles all having to add this to their namespace handlers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ARIES-1118) Provide common schema for XML namespace
[ https://issues.apache.org/jira/browse/ARIES-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1118. Resolution: Fixed Fix Version/s: blueprint-core-1.2.0 Provide common schema for XML namespace --- Key: ARIES-1118 URL: https://issues.apache.org/jira/browse/ARIES-1118 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: blueprint-core-1.2.0 And schema that uses the xml namespace things (xml:lang, xml:base, etc...) needs to import http://www.w3.org/XML/1998/namespace. Blueprint could provide a Namespace handler for that namespace to avoid having a bunch of different bundles all having to add this to their namespace handlers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ARIES-1015) Use version range in imported package
[
https://issues.apache.org/jira/browse/ARIES-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571343#comment-13571343
]
Daniel Kulp commented on ARIES-1015:
This patch has a few:
{code}
-org.osgi.framework;version=[1.5,2),
+org.osgi.framework;version=[1.6,2),
{code}
Is it really intentional to require 1.6? Is everyone OK with updating that?
I'm not sure if we agreed to drop the 1.5 support for the various components.
Thoughts?
Use version range in imported package
-
Key: ARIES-1015
URL: https://issues.apache.org/jira/browse/ARIES-1015
Project: Aries
Issue Type: Improvement
Reporter: Jean-Baptiste Onofré
Attachments: ARIES-1015.patch
As seen in Aries JMX, some other modules should use version range for
imported package in order to be aligned with at least OSGi r4.3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (ARIES-1013) Aries JMX Core should extend its OSGi framework version range
[ https://issues.apache.org/jira/browse/ARIES-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned ARIES-1013: -- Assignee: Daniel Kulp Aries JMX Core should extend its OSGi framework version range - Key: ARIES-1013 URL: https://issues.apache.org/jira/browse/ARIES-1013 Project: Aries Issue Type: Bug Components: JMX Environment: Aries JMX 1.1.0 Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp Attachments: ARIES-1013.patch In order to work with all OSGi frameworks, Aries JMX bundle should extend its org.osgi.framework package version range (to something like [1.6,2)): Bundle org.apache.aries.jmx.core [65] Error starting mvn:org.apache.aries.jmx/org.apache.aries.jmx.core/1.1.0 (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0 org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:662) laERROR: Bundle org.apache.aries.jmx.core [65] Error starting/stopping bundle. (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0 org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1388) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:301) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-1013) Aries JMX Core should extend its OSGi framework version range
[ https://issues.apache.org/jira/browse/ARIES-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1013. Resolution: Fixed Aries JMX Core should extend its OSGi framework version range - Key: ARIES-1013 URL: https://issues.apache.org/jira/browse/ARIES-1013 Project: Aries Issue Type: Bug Components: JMX Environment: Aries JMX 1.1.0 Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp Attachments: ARIES-1013.patch In order to work with all OSGi frameworks, Aries JMX bundle should extend its org.osgi.framework package version range (to something like [1.6,2)): Bundle org.apache.aries.jmx.core [65] Error starting mvn:org.apache.aries.jmx/org.apache.aries.jmx.core/1.1.0 (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0 org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:662) laERROR: Bundle org.apache.aries.jmx.core [65] Error starting/stopping bundle. (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0 org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.aries.jmx.core [65]: Unable to resolve 65.0: missing requirement [65.0] osgi.wiring.package; ((osgi.wiring.package=org.osgi.framework)(version=1.7.0)(!(version=2.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1388) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:301) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-1011) Blueprint Core bundle raises an exception during stop
[ https://issues.apache.org/jira/browse/ARIES-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1011. Resolution: Not A Problem Assignee: Daniel Kulp If Karaf updates to the latest utils, the stacktrace will go away. Blueprint Core bundle raises an exception during stop - Key: ARIES-1011 URL: https://issues.apache.org/jira/browse/ARIES-1011 Project: Aries Issue Type: Bug Components: Blueprint Environment: Karaf 2.3.1-SNAPSHOT Aries Blueprint Core 1.1.0 Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp At Karaf shutdown, when stopping the Aries Blueprint Core bundle, an IllegalStateException is raised: ERROR: Bundle org.apache.aries.blueprint.core [7] Error stopping bundle. (java.lang.IllegalStateException: Service already unregistered.) java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker.close(BundleHookBundleTracker.java:88) at org.apache.aries.util.tracker.RecursiveBundleTracker.close(RecursiveBundleTracker.java:106) at org.apache.aries.blueprint.container.BlueprintExtender.stop(BlueprintExtender.java:160) at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2361) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:662) ERROR: Bundle org.apache.aries.blueprint.core [7] Error stopping mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core/1.1.0 (org.osgi.framework.BundleException: Activator stop error in bundle org.apache.aries.blueprint.core [7].) java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker.close(BundleHookBundleTracker.java:88) at org.apache.aries.util.tracker.RecursiveBundleTracker.close(RecursiveBundleTracker.java:106) at org.apache.aries.blueprint.container.BlueprintExtender.stop(BlueprintExtender.java:160) at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2361) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-946) Update .gitignore to exclude .idea directory
[ https://issues.apache.org/jira/browse/ARIES-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-946. --- Resolution: Fixed Assignee: Daniel Kulp Update .gitignore to exclude .idea directory Key: ARIES-946 URL: https://issues.apache.org/jira/browse/ARIES-946 Project: Aries Issue Type: Improvement Reporter: Jean-Baptiste Onofré Assignee: Daniel Kulp Priority: Minor Attachments: ARIES-946.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13400567#comment-13400567 ] Daniel Kulp commented on ARIES-861: --- Thanks Holly. That's likely the best fix. Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Assignee: Daniel Kulp Fix For: proxy.impl-0.4.1 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-861. --- Resolution: Fixed Vote started. Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Assignee: Daniel Kulp Fix For: proxy.impl-0.4.1 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399527#comment-13399527 ] Daniel Kulp commented on ARIES-861: --- Is it the testFinalConstructor test? I did stick an @Ignore on that on the fixes branches for that exact reason. So yea, disable it. Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Assignee: Daniel Kulp Fix For: proxy.impl-0.4.1 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399076#comment-13399076 ] Daniel Kulp commented on ARIES-861: --- I've staged new versions of 0.3.1 and 0.4.1 to: https://repository.apache.org/content/repositories/orgapachearies-264/ https://repository.apache.org/content/repositories/orgapachearies-265/ I'd appreciate some testing with it to make sure it works. I'll look more tomorrow before calling a vote. Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Fix For: proxy.impl-0.4 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned ARIES-861: - Assignee: Daniel Kulp Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Assignee: Daniel Kulp Fix For: proxy.impl-0.4.1 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-861) Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33
[ https://issues.apache.org/jira/browse/ARIES-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397841#comment-13397841 ] Daniel Kulp commented on ARIES-861: --- Alexander: it's on my todo list to port this back to the 3.x versions. I've been sidetracked with other issues at the moment, but will try to get to it real soon. Error on retrieving constructor for proxy of karaf BlueprintCommand class on jdk 6 update 33 Key: ARIES-861 URL: https://issues.apache.org/jira/browse/ARIES-861 Project: Aries Issue Type: Bug Components: Proxy Reporter: Christian Schneider Fix For: proxy.impl-0.4 When I switch my karaf trunk snapshot from jdk 6 update 31 to update 33 all karaf commands stop working. I was able to track this down to blueprint and the proxy facility or aries. The exception I get is: org.osgi.framework.ServiceException: Service factory exception: (class: org/apache/karaf/shell/console/commands/$BlueprintCommand16496117, method: init signature: (Ljava/lang/reflect/InvocationHandler;)V) Call to wrong initialization method In the log this does not show. There I only get a Nullpointer exception as the service object for the command is returned as null. I have documented more details in the linked karaf issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ARIES-626) Aries blueprint namaspace handler schema with includes
[ https://issues.apache.org/jira/browse/ARIES-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-626. --- Resolution: Fixed Fix Version/s: 1.0 blueprint-core-0.3.2 Aries blueprint namaspace handler schema with includes -- Key: ARIES-626 URL: https://issues.apache.org/jira/browse/ARIES-626 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Edstrom Johan Assignee: Daniel Kulp Fix For: blueprint-core-0.3.2, 1.0 Attachments: relpath-patch2-fixed.txt, relpath-patch2.txt If you have a NamespaceHandler implementation where the schema contains xsd:includes, the schema will fail to resolve if you do not have connectivity. There is also no way to attach a CatalogResolver or xml-resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
