[JBoss JIRA] (JBOSGI-672) DuplicateServiceException on undertow deployment replace
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-672?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-672:
----------------------------------
Comment: was deleted
(was: Won't Fix - OSGi is going to get removed)
> DuplicateServiceException on undertow deployment replace
> --------------------------------------------------------
>
> Key: JBOSGI-672
> URL: https://issues.jboss.org/browse/JBOSGI-672
> Project: JBoss OSGi
> Issue Type: Bug
> Components: WebApp
> Reporter: Thomas Diesler
>
> {code}
> 07:21:52,095 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "webapp-v101.wab" (runtime-name: "webapp-v101.wab")
> 07:21:52,119 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: webapp-v101.wab:1.0.1
> 07:21:52,119 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS018224: Unregister web context: /simple-bundle
> 07:21:52,119 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011003: Bundle stopped: webapp-v100.wab:1.0.0
> 07:21:52,124 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."webapp-v101.wab".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v101.wab".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "webapp-v101.wab"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.undertow.deployment.default-host./simple-bundle.UndertowDeploymentInfoService is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2382) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2382) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentProcessor.processDeployment(UndertowDeploymentProcessor.java:235)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentProcessor.deploy(UndertowDeploymentProcessor.java:102)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> {code}
> http://teamcity.cafe-babe.org/viewLog.html?buildId=5380&tab=buildResultsD...
--
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
[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 resolved JBOSGI-680.
-----------------------------------
Resolution: Won't Fix
> 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"/>
> <!-- Insert resources here -->
> </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
[JBoss JIRA] (JBOSGI-666) Cannot lookup owner context using standard naming API
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-666?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated JBOSGI-666:
----------------------------------
Assignee: (was: Thomas Diesler)
> Cannot lookup owner context using standard naming API
> -----------------------------------------------------
>
> Key: JBOSGI-666
> URL: https://issues.jboss.org/browse/JBOSGI-666
> Project: JBoss OSGi
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JNDI
> Affects Versions: JBossOSGi 2.0.0
> Reporter: Thomas Diesler
>
> {code}
> Context initialContext = new InitialContext();
> BundleContext context = (BundleContext) initialContext.lookup("osgi:framework/bundleContext");
> {code}
> fails with
> {code}
> testTraditionalAPIOwnerContext(org.jboss.test.osgi.example.jndi.NamingStandaloneTestCase) Time elapsed: 0.062 sec <<< FAILURE!
> java.lang.AssertionError: expected:<BundleContext[jndi-tests:0.0.0]> but was:<BundleContext[arquillian-osgi-bundle:2.0.0.CR4]>
> {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
[JBoss JIRA] (JBOSGI-732) Populate repository with metadata from system modules/bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-732?page=com.atlassian.jira.plugin... ]
Thomas Diesler moved WFLY-1226 to JBOSGI-732:
---------------------------------------------
Project: JBoss OSGi (was: WildFly)
Key: JBOSGI-732 (was: WFLY-1226)
Workflow: jira (was: GIT Pull Request workflow )
Component/s: (was: OSGi)
(was: Server)
> Populate repository with metadata from system modules/bundles
> -------------------------------------------------------------
>
> Key: JBOSGI-732
> URL: https://issues.jboss.org/browse/JBOSGI-732
> Project: JBoss OSGi
> Issue Type: Task
> Reporter: Thomas Diesler
>
> The OSGi configuration supports ModuleIdentifiers. So for example
> {code}
> <capability name="javax.transaction.api"/>
> {code}
> references the JTA API module. This actually delegates to the repository implementations which in turn delegates to the ModuleIdentityArtifactProvider.
> If the AppServer supports the notion of multiple directories where modules can get loaded from, the ServerEnvironment should reflect that properly. I cannot just load a module on trial/error basis because we use the Repository for impact ananlysis. i.e. Find the modules/bundles that provide the transitive set of capabilities for a given set of requirements (without modifying the runtime).
--
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