[JBoss JIRA] (AS7-6477) /host=* has something called "server" that is neither child nor attribute
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/AS7-6477?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber resolved AS7-6477.
--------------------------------------
Resolution: Done
server is now listed as child.
> /host=* has something called "server" that is neither child nor attribute
> -------------------------------------------------------------------------
>
> Key: AS7-6477
> URL: https://issues.jboss.org/browse/AS7-6477
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Stan Silvert
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Alpha1
>
>
> Start a domain with a host called "master". In CLI, do /host=master/:read-resource. In the result, you will see a resource called "server".
> However, if you do /host=master/:read-children-types it will not show up as a child type.
> If you do /host=master/:read-resource-description it will not show up as an attribute either.
> So what is "server"? It's not a child and it's not an attribute. Is it something that should not show up in read-resource?
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6754) add blocking option to start/stop/restart/reload commands for server groups
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/AS7-6754?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber resolved AS7-6754.
--------------------------------------
Fix Version/s: 8.0.0.Alpha1
(was: Awaiting Volunteers)
Resolution: Done
The basic functionality is there. As a future improvement we should make this work with domain rollout plans, however that requires some substantial changes.
> add blocking option to start/stop/restart/reload commands for server groups
> ---------------------------------------------------------------------------
>
> Key: AS7-6754
> URL: https://issues.jboss.org/browse/AS7-6754
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Brad Maxwell
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Alpha1
>
>
> In domain mode, it is possible to block when restarting individual servers, this would be a useful enhancement to add the blocking option to the start/stop/restart of server groups. This option would be useful when writing management scripts to know when the servers have complete the operation.
> /host=master/server-config=example-server1:restart(blocking=true)
> /host=master/server-config=example-server1:stop(blocking=true)
> /host=master/server-config=example-server1:start(blocking=true)
> domain mode
> These would benefit from a blocking option
> /:restart-servers
> /:stop-servers
> /:start-servers
> As well as these
> /server-group=main-server-group:restart-servers()
> /server-group=main-server-group:stop-servers()
> /server-group=main-server-group:start-servers()
> standalone mode:
> In standalone mode, there is shutdown with a restart option, this would also benefit from adding a blocking argument when restarting or shutting down
> :shutdown(restart=true)
> It looks like :reload() does not have a blocking option either, reload essentially is restarting the server, from a scripting perspective there is not a nice way to call reload then then perform some other commands, currently you have to do a sleep and then try to invoke a command catch an exception and try again later. So :reload(blocking=true) would also be useful.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-947) Managed domain server :reload() operation
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/AS7-947?page=com.atlassian.jira.plugin.sy... ]
Emanuel Muckenhuber resolved AS7-947.
-------------------------------------
Resolution: Done
server-config now has a :reload operation
> Managed domain server :reload() operation
> -----------------------------------------
>
> Key: AS7-947
> URL: https://issues.jboss.org/browse/AS7-947
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Alpha1
>
>
> Reloading yields an exception:
> /host=local/server=server-one:reload
> {noformat}
> [Host Controller] 12:32:50,188 ERROR [org.jboss.as.host.controller] (pool-1-thread-24) Could not start server Server:server-one: java.lang.IllegalArgumentException: A node is already registered at '(server => server-one)'
> [Host Controller] at org.jboss.as.controller.registry.NodeSubregistry.registerProxyController(NodeSubregistry.java:89) [jboss-as-controller-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
> {noformat}
> A second operation request results in "broken pipe":
> {noformat}
> [Host Controller] 12:33:03,025 ERROR [org.jboss.as.protocol] (ModelControllerClient-thread - 1) Failed to close resource org.jboss.as.protocol.SimpleByteDataOutput@37c398e: java.net.SocketException: Broken pipe
> {noformat}
--
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
13 years, 3 months
[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5970?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5970:
----------------------------------------------
Boleslaw Dawidowicz <bdawidow(a)redhat.com> made a comment on [bug 877560|https://bugzilla.redhat.com/show_bug.cgi?id=877560]
According to JIRA/BZ this is resolved in EAP 6.1 Alpha
> RichFaces Showcase portlet is unable to switch skins
> ----------------------------------------------------
>
> Key: AS7-5970
> URL: https://issues.jboss.org/browse/AS7-5970
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Ken Finnigan
> Assignee: Stan Silvert
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time:
> {noformat}
> Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444
> at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1]
> {noformat}
> This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request.
> This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6882) missing requirement XPackageRequirement[atts={osgi.wiring.package=org.osgi.framework.startlevel
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6882?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-6882:
-------------------------------------
This is not a bug. If you want org.osgi.jmx functionality you need to install a bundle that provides it (e.g. Aries JMX). The jbosgi umbrella test suite has coverage for that.
> missing requirement XPackageRequirement[atts={osgi.wiring.package=org.osgi.framework.startlevel
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-6882
> URL: https://issues.jboss.org/browse/AS7-6882
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Aaron Whiteside
> Assignee: Thomas Diesler
>
> What version of OSGi does JBoss as 7.2.0 support? And can we get it upgraded to at least 4.3?
> Cannot deploy gemini management bundle, because:
> {code}
> 11:50:01,847 INFO [org.jboss.as.osgi] (HttpManagementService-threads - 7) JBAS011916: Activate deferred module phase for: org.eclipse.gemini.management:1.0.5.RELEASE
> 11:50:01,847 ERROR [org.jboss.as.osgi] (HttpManagementService-threads - 7) JBAS011909: Management operation 'start' failed: org.osgi.framework.BundleException: JBOSGI011250: Cannot resolve bundle: org.eclipse.gemini.management:1.0.5.RELEASE
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:299)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.start(BundleLifecycleIntegration.java:229)
> at org.jboss.osgi.framework.internal.AbstractBundleState.startWithOptions(AbstractBundleState.java:537)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:525)
> at org.jboss.as.osgi.management.BundleResourceHandler.handleOperation(BundleResourceHandler.java:106)
> at org.jboss.as.osgi.management.BundleResourceHandler.executeRuntimeStep(BundleResourceHandler.java:58)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl$2.execute(ModelControllerImpl.java:338) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl$2.execute(ModelControllerImpl.java:328) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320)
> at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226)
> at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233)
> 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:47)
> at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45)
> 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.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]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.osgi.service.resolver.ResolutionException: Unable to resolve HostBundleRevision[org.eclipse.gemini.management:1.0.5.RELEASE]: missing requirement XPackageRequirement[atts={osgi.wiring.package=org.osgi.framework.startlevel, version=1.0.0},[org.eclipse.gemini.management:1.0.5.RELEASE]]
> at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:285)
> at org.apache.felix.resolver.Candidates.populate(Candidates.java:153)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:96)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverImpl.resolveAndApply(ResolverImpl.java:137)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:296)
> ... 31 more
> {code}
> When I try to install the osgi-core-4.3 bundle I get the following error:
> {code}
> 11:48:50,887 INFO [org.jboss.as.osgi] (HttpManagementService-threads - 6) JBAS011916: Activate deferred module phase for: osgi.core:4.3.0.201102171602
> 11:48:50,891 ERROR [org.jboss.as.osgi] (HttpManagementService-threads - 6) JBAS011909: Management operation 'start' failed: org.osgi.framework.BundleException: JBOSGI011250: Cannot resolve bundle: osgi.core:4.3.0.201102171602
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:299)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.start(BundleLifecycleIntegration.java:229)
> at org.jboss.osgi.framework.internal.AbstractBundleState.startWithOptions(AbstractBundleState.java:537)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:525)
> at org.jboss.as.osgi.management.BundleResourceHandler.handleOperation(BundleResourceHandler.java:106)
> at org.jboss.as.osgi.management.BundleResourceHandler.executeRuntimeStep(BundleResourceHandler.java:58)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl$2.execute(ModelControllerImpl.java:338) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.controller.ModelControllerImpl$2.execute(ModelControllerImpl.java:328) [jboss-as-controller-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320)
> at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226)
> at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233)
> 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:47)
> at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45)
> 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.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]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.gemini.management [HostBundleRevision[org.eclipse.gemini.management:1.0.5.RELEASE]] because it is exposed to package 'org.osgi.framework' from resources osgi.core [HostBundleRevision[osgi.core:4.3.0.201102171602]] and system.bundle [SystemBundleRevision[system.bundle:0.0.0]] via two dependency chains.
> Chain 1:
> org.eclipse.gemini.management [HostBundleRevision[org.eclipse.gemini.management:1.0.5.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.osgi.framework
> osgi.core [HostBundleRevision[osgi.core:4.3.0.201102171602]]
> Chain 2:
> org.eclipse.gemini.management [HostBundleRevision[org.eclipse.gemini.management:1.0.5.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.osgi.service.cm; uses:=org.osgi.framework
> org.apache.felix.configadmin [HostBundleRevision[org.apache.felix.configadmin:1.2.8]]
> import: null
> |
> export: osgi.wiring.package=org.osgi.framework
> system.bundle [SystemBundleRevision[system.bundle:0.0.0]]
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverImpl.resolveAndApply(ResolverImpl.java:137)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:296)
> ... 31 more
> 11:49:39,856 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011005: Bundle uninstalled: osgi.core:4.3.0.201102171602
> 11:49:39,857 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment core-4.3.0.jar (runtime-name: core-4.3.0.jar) in 3ms
> 11:49:39,956 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "core-4.3.0.jar" (runtime-name: "core-4.3.0.jar")
> {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
13 years, 3 months
[JBoss JIRA] (AS7-4324) Batch deployment of bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4324?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-4324:
-------------------------------------
An OSGi Framework does not auto refresh/resolve A when bundle B gets installed/resolved/started. Even if A has a requirement that could potentially be wired to a capability provided by B.
You need to make sure that you install stuff together that you want to resolve together or deal with ordering in some other way.
> Batch deployment of bundles
> ---------------------------
>
> Key: AS7-4324
> URL: https://issues.jboss.org/browse/AS7-4324
> Project: Application Server 7
> Issue Type: Feature Request
> Components: OSGi
> Affects Versions: 7.1.1.Final
> Environment: Mac OS X 10.7.3
> Reporter: Tim Diekmann
> Assignee: Thomas Diesler
> Fix For: 7.1.2.Final (EAP)
>
>
> It has to be possible to deploy a large set of bundles at the same time without triggering the resolution of each bundle individually.
> Currently, if you deploy multiple bundles either through CLI or via the hot deployment folder the deployer processes each bundle individually. If you try to deploy 287 bundles with interdependencies, this would mean you have to install them in the absolute correct order or else the deployer finds missing dependencies and undeploys the bundle again.
> The OSGi framework API allows for installation of multiple bundles before calling a single refresh call to trigger the re-wiring. The deployer needs to support a mechanism similar to this as well.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6924) Cannot resolve package requirement on javax.xml.stream.events
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6924?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6924:
--------------------------------
Summary: Cannot resolve package requirement on javax.xml.stream.events (was: Cannot resolve against javax.xml.stream.events package capability)
> Cannot resolve package requirement on javax.xml.stream.events
> -------------------------------------------------------------
>
> Key: AS7-6924
> URL: https://issues.jboss.org/browse/AS7-6924
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi, XML Frameworks
> Affects Versions: 8.0.0.Alpha1
> Reporter: Aaron Whiteside
> Assignee: Thomas Diesler
>
> {code}
> 12:53:16,935 WARN [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011910: Cannot resolve requirements: [XPackageRequirement[dirs={filter=(&(osgi.wiring.package=javax.xml.stream.events)(version>=0.0.0))},[org.springframework.core:3.2.2.RELEASE]]]
> 12:53:16,940 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015970: Defer FIRST_MODULE_USE for org.springframework.core-3.2.2.RELEASE.jar making it NEVER
> {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
13 years, 3 months