[JBoss JIRA] (WFLY-559) Support Bundle deploy/undeploy from management operation
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-559?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-559.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Support Bundle deploy/undeploy from management operation
> --------------------------------------------------------
>
> Key: WFLY-559
> URL: https://issues.jboss.org/browse/WFLY-559
> Project: WildFly
> Issue Type: Sub-task
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 9.0.0.CR1
>
>
> There is a requirement that a bundle can install/uninstall other bundles during start/stop. We support auto start/stop for bundle deployments and explicit start/stop as management operations.
> In both cases this would trigger a management operation (i.e. deploy/undeploy) from within the another management operation, which currently not supported.
--
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
9 years, 8 months
[JBoss JIRA] (WFLY-1504) Unusable wiring metadata for Apache-CXF
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1504?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1504.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Unusable wiring metadata for Apache-CXF
> ---------------------------------------
>
> Key: WFLY-1504
> URL: https://issues.jboss.org/browse/WFLY-1504
> Project: WildFly
> Issue Type: Bug
> Components: OSGi, Web Services
> 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
9 years, 8 months
[JBoss JIRA] (WFLY-992) Cannot restart ejb3 bundle after activation failure
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-992?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-992.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Cannot restart ejb3 bundle after activation failure
> ---------------------------------------------------
>
> Key: WFLY-992
> URL: https://issues.jboss.org/browse/WFLY-992
> Project: WildFly
> Issue Type: Bug
> Components: EJB, OSGi
> Reporter: Thomas Diesler
> Assignee: Bartosz Baranowski
>
> {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
9 years, 8 months
[JBoss JIRA] (WFLY-1382) OSGi: "Export-EJB" header is not supported to install/start EJB3 bundle from repository
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1382?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1382.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> OSGi: "Export-EJB" header is not supported to install/start EJB3 bundle from repository
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-1382
> URL: https://issues.jboss.org/browse/WFLY-1382
> Project: WildFly
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 8.0.0.Alpha2
> Reporter: Igor Shulika
>
> I am using the latest WildFly 8.0.0.Alpha2-SNAPSHOT server to install/start all of my OSGi bundles from Maven repository. The EJB 3 MDB is not starting if I am just declare capability in the standalone-osgi.xml file.
>
> Here is my capability configuration.
> <capability name="org.test.ejb3.mdb:ejb-high-velocity-queue-mdb:1.0" startlevel="4"/>
>
> Note: When I just simply drop my EJB 3 MDB JAR file inside "deployments" directory the message driven bean starting successfully (see below).
> INFO [org.jboss.as.ejb3] (MSC service thread 1-2) JBAS014142: Started message driven bean 'HighVelocityQueueMessageBean' with 'hornetq-ra' resource adapter.
--
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
9 years, 8 months
[JBoss JIRA] (WFLY-1226) Populate repository with metadata from system modules/bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1226?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1226.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Populate repository with metadata from system modules/bundles
> -------------------------------------------------------------
>
> Key: WFLY-1226
> URL: https://issues.jboss.org/browse/WFLY-1226
> Project: WildFly
> Issue Type: Task
> Components: OSGi, Server
> 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
9 years, 8 months