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

[JBoss JIRA] (JBOSGI-717) 128.6.3 Resource Lookup

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-717?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-666 to JBOSGI-717: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-717 (was: WFLY-666) Workflow: jira (was: GIT Pull Request workflow ) > 128.6.3 Resource Lookup > ----------------------- > > Key: JBOSGI-717 > URL: https://issues.jboss.org/browse/JBOSGI-717 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: David Bosschaert > Assignee: 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

[JBoss JIRA] (JBOSGI-722) Remove support for legacy osgi subsystem namespaces

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-722?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1338 to JBOSGI-722: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-722 (was: WFLY-1338) Workflow: jira (was: GIT Pull Request workflow ) Affects Version/s: (was: 8.0.0.Alpha1) Component/s: (was: OSGi) > Remove support for legacy osgi subsystem namespaces > --------------------------------------------------- > > Key: JBOSGI-722 > URL: https://issues.jboss.org/browse/JBOSGI-722 > Project: JBoss OSGi > Issue Type: Task > 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

[JBoss JIRA] (JBOSGI-701) Provide management view for bundle wiring

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-701?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1199 to JBOSGI-701: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-701 (was: WFLY-1199) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Provide management view for bundle wiring > ----------------------------------------- > > Key: JBOSGI-701 > URL: https://issues.jboss.org/browse/JBOSGI-701 > Project: JBoss OSGi > Issue Type: Feature Request > Environment: Mac OS X 10.7.3 > Reporter: Tim Diekmann > Labels: Console > > The OSGi management console for AS 7 needs a viewer of the current wiring. The console log showed the following error on start of the bundle and there is no way to inspect the wiring to see where the problem lies and how to solve it. There is some inconsistency in the deployment, but how to find out what? > {code} > 00:09:14,480 ERROR [org.mortbay.log] (HttpManagementService-threads - 3) Error starting handlers: java.lang.IncompatibleClassChangeError: Class org.eclipse.equinox.http.servlet.HttpServiceServlet does not implement the requested interface javax.servlet.Servlet > at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.init(HttpServerManager.java:294) > at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431) > at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:681) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) > at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) > at org.mortbay.jetty.Server.doStart(Server.java:224) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.eclipse.equinox.http.jetty.internal.HttpServerManager.updated(HttpServerManager.java:109) > at org.eclipse.equinox.http.jetty.internal.Activator.start(Activator.java:60) > at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300) > at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223) > at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:488) > at org.jboss.as.osgi.parser.BundleRuntimeHandler.handleOperation(BundleRuntimeHandler.java:132) > at org.jboss.as.osgi.parser.BundleRuntimeHandler.executeRuntimeStep(BundleRuntimeHandler.java:89) > at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274) > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202) > at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:461) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274) > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) > at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:304) > at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:294) > at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:294) > at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:201) > at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:208) > at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78) > at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81) > at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78) > at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:54) > at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81) > at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_29] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_29] > at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_29] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {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-709) Support deployment of a set of Bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-709?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-560 to JBOSGI-709: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-709 (was: WFLY-560) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Support deployment of a set of Bundles > -------------------------------------- > > Key: JBOSGI-709 > URL: https://issues.jboss.org/browse/JBOSGI-709 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > > In one deploy cycle, bundles must first get installed and then started. > It generally needs to be discussed how multiple phase deployments should be handled. -- 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-707) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-707?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-558 to JBOSGI-707: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-707 (was: WFLY-558) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: Domain Management) (was: OSGi) (was: Server) > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: JBOSGI-707 > URL: https://issues.jboss.org/browse/JBOSGI-707 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- 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-708) Support Bundle deploy/undeploy from management operation

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-708?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-559 to JBOSGI-708: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-708 (was: WFLY-559) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Support Bundle deploy/undeploy from management operation > -------------------------------------------------------- > > Key: JBOSGI-708 > URL: https://issues.jboss.org/browse/JBOSGI-708 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-703) Integration of EventAdmin with AS7 components

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-703?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1133 to JBOSGI-703: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-703 (was: WFLY-1133) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Integration of EventAdmin with AS7 components > --------------------------------------------- > > Key: JBOSGI-703 > URL: https://issues.jboss.org/browse/JBOSGI-703 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > > Non-OSGi components should be able to publish/receive events through EventAdmin > and vice versa of course -- 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-706) Complete support for Bundle update

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-706?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-557 to JBOSGI-706: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-706 (was: WFLY-557) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Complete support for Bundle update > ---------------------------------- > > Key: JBOSGI-706 > URL: https://issues.jboss.org/browse/JBOSGI-706 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > > A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision. There is only ever one current revision (the latest update) associated with a Bundle. Stale revisions continue to exist in the runtime until an explicit refresh of the transitive dependency graph. > Approach #1 - bundle revisions are represented as individual deployments > Each bundle update deploys the revision as a new deployment > The association of revisions to bundle happens in the OSGi layer only > Management sees disconnected deployments with no notion of stale/current or belonging together > Approach #2 - deployment API supports the notion of multiple revisions > deployments, their revisions and respective mapping would be modelled more closely on OSGi requirements > some deployment types might not support revisions -- 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-704) Complete support for Bundle start/stop

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-704?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-555 to JBOSGI-704: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-704 (was: WFLY-555) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Complete support for Bundle start/stop > --------------------------------------- > > Key: JBOSGI-704 > URL: https://issues.jboss.org/browse/JBOSGI-704 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > Labels: roadmap > > A Bundle start/stop operation activates/deactivates the bundle services. The associated class loader and wiring is unaffected. > Approach #1 - start/stop is not mapped to deployment operations > Bundle deploy installs the Bundle to the Framework > Bundle is not resolved/started as part of the deploy operation > No module/classloader is created during deployment > All deployment processing that needs load classes/resources is skipped > No service provided by the bundle deployment is created > Bundle needs to be started/stopped explicitly > Bundle start/stop management operations are specific to bundle deployments > The POST_MODULE processing for OSGi enabled deployments (e.g. webapp) would need to be executed in an OSGi specific processor chain > OSGi enabled POST_MODULE DUPs have their functionality externalised such that it can get reused for start/stop operations > The start/stop processing chain must be traversable in both directions repeatedly > Approach #2 - start/stop is mapped to deployment operations > Bundle deploy installs the Bundle to the Framework and attempts to resolve/start the Bundle > If the Bundle can get resolved, a module/classloader is created as part of the DU processing > In case the Bundle cannot get resolved, DUP processing is deferred and MODULE phase processing is reattempted later based on an external trigger > Has the benefit that any deployment type can also be a Bundle > Bundle stop must reverse work that is done in POST_MODULE DUPs > POST_MODULE DUPs must be traversable in both direction multiple times > Currently, we use approach #2 with limited support from POST_MODULE DUPs (i.e. they are not designed to be executed multiple times for the same deployment). There is also the cleanup phase which breaks multiple executions of POST_MODULE DUPs. -- 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-705) Complete support for Bundle uninstall

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-705?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-556 to JBOSGI-705: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-705 (was: WFLY-556) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Complete support for Bundle uninstall > ------------------------------------- > > Key: JBOSGI-705 > URL: https://issues.jboss.org/browse/JBOSGI-705 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: Thomas Diesler > > Bundle uninstall only removes the BundleRevision from the runtime if it is no longer in use. The classloader associated with an uninstalled bundle that is still in use remains active. > Approach #1 - "in use" semantic specific to Bundle deployments > An undeploy management operation undeploys the bundle revision but holds in the MODULE phase when the revision is still in use > This is similar to deferred MODULE phase for deploy operation > in use is not respected for non-osgi deployments and hence breaks bundle deployments that depend on them > Approach #2 - "in use" semantic applies to all deployment types > Undeploy will only destroy the Module service if the Module is not in use by another deployment > When Module usage drops to zero, undeploy continues and removes the deployment from management > This approach would map cleanly - there is no cascading destroy effect. i.e. when you undeploy a jar that a webapp depends on > Services provided by the undeployed deployment would always go down, only classloader destruction is deferred -- 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