July 2013 - jboss-osgi-issues - Jboss List Archives

[JBoss JIRA] (JBOSGI-695) Complete support for OSGi JDBC

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-695?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1095 to JBOSGI-695: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-695 (was: WFLY-1095) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: JCA) (was: OSGi) > Complete support for OSGi JDBC > ------------------------------ > > Key: JBOSGI-695 > URL: https://issues.jboss.org/browse/JBOSGI-695 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > > R5 TCK compliance for JDBC -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-689) Complete support for OSGi JNDI

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-689?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1100 to JBOSGI-689: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-689 (was: WFLY-1100) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: Naming) (was: OSGi) > Complete support for OSGi JNDI > ------------------------------ > > Key: JBOSGI-689 > URL: https://issues.jboss.org/browse/JBOSGI-689 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > > As expected because of the missing integration with the NamingManger singletons, all tests that go through NamingManager to obtain the InitialContextFactory or the ObjectFactory fail. > {code} > Running org.jboss.test.osgi.example.jndi.JNDITestCase > Tests run: 12, Failures: 1, Errors: 2, Skipped: 2, Time elapsed: 15.574 sec <<< FAILURE! > Results : > Failed tests: testContextManagerReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): expected:<bar> but was:<Reference Class Name: java.lang.String(..) > Tests in error: > testTraditionalAPIValueBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader > testTraditionalAPIReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader > {code} > In reality it means that OSGi Bundles cannot use JNDI with object References and cannot expect the traditional JNDI API to work. These findings generally raise the question how a spec compliant OSGI JNDI Implementation is supposed to work in a container environment. Specifically, in an environment that has already set the NamingManager singletons. > IMHO there is a layer of abstraction missing. Perhaps the container should register a NamingManger service that the JNDI Implementation can use to register its InitialContextFactoryBuilder and ObjectFactoryBuilder. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-683) Failure detection/handling in deployment operation start

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-683?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1089 to JBOSGI-683: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-683 (was: WFLY-1089) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Failure detection/handling in deployment operation start > -------------------------------------------------------- > > Key: JBOSGI-683 > URL: https://issues.jboss.org/browse/JBOSGI-683 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Priority: Minor > -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-674) Cannot restart ejb3 bundle after activation failure

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-674?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-992 to JBOSGI-674: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-674 (was: WFLY-992) Workflow: jira (was: GIT Pull Request workflow ) Component/s: EJB3 (was: EJB) (was: OSGi) > Cannot restart ejb3 bundle after activation failure > --------------------------------------------------- > > Key: JBOSGI-674 > URL: https://issues.jboss.org/browse/JBOSGI-674 > Project: JBoss OSGi > Issue Type: Bug > Components: EJB3 > Reporter: Thomas Diesler > > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component SampleSFSB > at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > ... 5 more > Caused by: java.lang.IllegalArgumentException: JBAS011085: Can't add org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$Factory@6f9e0e7b, priority 0x500 is already taken by org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$Factory@6f9e0e7b > at org.jboss.as.ee.component.interceptors.OrderedItemContainer.add(OrderedItemContainer.java:58) > at org.jboss.as.ee.component.ComponentConfiguration.addComponentInterceptor(ComponentConfiguration.java:181) > at org.jboss.as.ejb3.component.stateful.StatefulComponentDescription$2.configure(StatefulComponentDescription.java:153) > at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80) > {code} -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-675) Cannot replace jar that bundle depends on

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-675?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-116 to JBOSGI-675: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-675 (was: WFLY-116) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Cannot replace jar that bundle depends on > ----------------------------------------- > > Key: JBOSGI-675 > URL: https://issues.jboss.org/browse/JBOSGI-675 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > > With an OSGi webapp that depends on a jar the jar cannot be replaced. > See BundleReplaceTestCase.testDependentJarReplace() -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-680) Unusable wiring metadata for Apache-CXF

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-680?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1504 to JBOSGI-680: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-680 (was: WFLY-1504) Workflow: jira (was: GIT Pull Request workflow ) Component/s: WebServices (was: OSGi) (was: Web Services) > Unusable wiring metadata for Apache-CXF > --------------------------------------- > > Key: JBOSGI-680 > URL: https://issues.jboss.org/browse/JBOSGI-680 > Project: JBoss OSGi > Issue Type: Bug > Components: WebServices > Reporter: Thomas Diesler > > When integrating the [camel-cxf|http://camel.apache.org/cxf.html] component we see a number of package requirements on cxf > {code} > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.binding.soap)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.injection)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.logging)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.common.util)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration.blueprint)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.configuration.spring)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.headers)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.helpers)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.io)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.message)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.service.model)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.transport)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.ws.addressing)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > XPackageRequirement[dirs={filter=(&(osgi.wiring.package=org.apache.cxf.wsdl)(&(version>=2.6.0)(!(version>=2.9.0))))},[org.apache.camel.camel-cxf-transport:2.11.0]] > {code} > most of these are contained in the org.apache.cxf.impl module, which however takes a "one bucket for all approach" that makes it impossible to use the metadata shipped with the individual cxf artefacts > {code} > <resources> > <resource-root path="cxf-rt-bindings-coloc-2.7.5.jar"/> > <resource-root path="cxf-rt-bindings-object-2.7.5.jar"/> > <resource-root path="cxf-rt-bindings-soap-2.7.5.jar"/> > <resource-root path="cxf-rt-bindings-xml-2.7.5.jar"/> > <resource-root path="cxf-rt-core-2.7.5.jar"/> > <resource-root path="cxf-rt-databinding-aegis-2.7.5.jar"/> > <resource-root path="cxf-rt-databinding-jaxb-2.7.5.jar"/> > <resource-root path="cxf-rt-frontend-jaxws-2.7.5.jar"/> > <resource-root path="cxf-rt-frontend-simple-2.7.5.jar"/> > <resource-root path="cxf-rt-management-2.7.5.jar"/> > <resource-root path="cxf-rt-transports-http-2.7.5.jar"/> > <resource-root path="cxf-rt-transports-jms-2.7.5.jar"/> > <resource-root path="cxf-rt-transports-local-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-addr-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-mex-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-policy-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-rm-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-security-2.7.5.jar"/> > <resource-root path="cxf-rt-ws-security-2.7.5-jandex.jar"/> > <resource-root path="cxf-tools-common-2.7.5.jar"/> > <resource-root path="cxf-tools-java2ws-2.7.5.jar"/> > <resource-root path="cxf-tools-validator-2.7.5.jar"/> > <resource-root path="cxf-tools-wsdlto-core-2.7.5.jar"/> > <resource-root path="cxf-tools-wsdlto-databinding-jaxb-2.7.5.jar"/> > <resource-root path="cxf-tools-wsdlto-frontend-jaxws-2.7.5.jar"/> > <resource-root path="cxf-services-sts-core-2.7.5.jar"/> > <resource-root path="cxf-services-ws-discovery-api-2.7.5.jar"/> > <resource-root path="cxf-xjc-boolean-2.6.1.jar"/> > <resource-root path="cxf-xjc-dv-2.6.1.jar"/> > <resource-root path="cxf-xjc-ts-2.6.1.jar"/> >  > </resources> > {code} > A possible fix would be to separate and reexport the modules that camel-cxf integrates with -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-679) Console does not support install/start semantic for bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-679?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-919 to JBOSGI-679: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-679 (was: WFLY-919) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: Domain Management) (was: OSGi) > Console does not support install/start semantic for bundles > ----------------------------------------------------------- > > Key: JBOSGI-679 > URL: https://issues.jboss.org/browse/JBOSGI-679 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > Labels: Console > > Currently, when you deploy a bundle through the console it is started automatically. For a set of bundles it means that you must install them in order otherwise they might not resolve. > Digging up the related issues ... -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-676) OSGi console allows start/stop on system bundle

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-676?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1000 to JBOSGI-676: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-676 (was: WFLY-1000) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > OSGi console allows start/stop on system bundle > ----------------------------------------------- > > Key: JBOSGI-676 > URL: https://issues.jboss.org/browse/JBOSGI-676 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > Labels: Console > > Start/Stop on the system bundle are invalid operations -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-677) Some javax.* bundles show version 0.0.0 in AS7

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-677?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-163 to JBOSGI-677: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-677 (was: WFLY-163) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Some javax.* bundles show version 0.0.0 in AS7 > ---------------------------------------------- > > Key: JBOSGI-677 > URL: https://issues.jboss.org/browse/JBOSGI-677 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > > Some javax bundles that we configure by default do not show valid bundle version info > javax.jws.api:0.0.0 > javax.ws.rs.api:0.0.0 > The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this > {code} > Bundle-SymbolicName: hibernate-jpa-2.0-api > Bundle-Version: 1.0.1.Final > Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0" > {code} > This should be replaced by metadata coming from the artefacts manifest. > Generally, all javax api artefacts should have valid OSGi metadata -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-682) Add ability to provision adapted modules

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-682?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1567 to JBOSGI-682: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-682 (was: WFLY-1567) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Add ability to provision adapted modules > ---------------------------------------- > > Key: JBOSGI-682 > URL: https://issues.jboss.org/browse/JBOSGI-682 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > -- 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

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues July 2013