[JBoss JIRA] (AS7-4321) OSGi management console needs inspector of wiring
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-4321:
--------------------------------
Assignee: David Bosschaert (was: Thomas Diesler)
Component/s: Console
> OSGi management console needs inspector of wiring
> -------------------------------------------------
>
> Key: AS7-4321
> URL: https://issues.jboss.org/browse/AS7-4321
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Console, OSGi
> Affects Versions: 7.1.1.Final
> Environment: Mac OS X 10.7.3
> Reporter: Tim Diekmann
> Assignee: David Bosschaert
>
> 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?
> 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)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4321) OSGi management console needs inspector of wiring
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-4321:
--------------------------------
Description:
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}
was:
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?
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)
> OSGi management console needs inspector of wiring
> -------------------------------------------------
>
> Key: AS7-4321
> URL: https://issues.jboss.org/browse/AS7-4321
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Console, OSGi
> Affects Versions: 7.1.1.Final
> Environment: Mac OS X 10.7.3
> Reporter: Tim Diekmann
> Assignee: David Bosschaert
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4321) OSGi management console needs inspector of wiring
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-539 to AS7-4321:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-4321 (was: JBOSGI-539)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.1.Final
(was: JBossOSGi 1.0.0)
Component/s: OSGi
(was: Core Framework)
Security: (was: Public)
> OSGi management console needs inspector of wiring
> -------------------------------------------------
>
> Key: AS7-4321
> URL: https://issues.jboss.org/browse/AS7-4321
> 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
>
> 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?
> 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)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4251) AS7.1.0.Final makes stale references untill contents inside 'tmp' folder are cleared
by Nagendra Prasad Bhat (JIRA)
Nagendra Prasad Bhat created AS7-4251:
-----------------------------------------
Summary: AS7.1.0.Final makes stale references untill contents inside 'tmp' folder are cleared
Key: AS7-4251
URL: https://issues.jboss.org/browse/AS7-4251
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.0.Final
Environment: Windows 7 enterprise, service pack1 64 bit OS
Reporter: Nagendra Prasad Bhat
Assignee: David Lloyd
Jboss AS 7.1.0.Final often makes stale references. Deployment of Jars/Wars in standalone 'deployments' directory takes stale references and outputs unexpected log messages like 'unresolved compilation', 'It is indirectly referenced from required .class files
'etc. Same set of artifacts work fine when contents of tmp>vfs and tmp>work>jboss.web are deleted and server is bounced. Here is the trace for this issue. This was never encountered in previous AS7.1 and AS7.0 releases.
17:47:19,549 DEBUG [org.jboss.resteasy.core.SynchronousDispatcher] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) PathInfo: phone/products/callrequest
17:47:19,565 INFO [com.mycompany.xyz.so.comm.service.PCommuServiceImpl] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) End of Comm cService method - schedulePCallRequest(). Time taken by the service is [4]ms
17:47:19,577 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/comm].[Resteasy]] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.Error: Unresolved compilation problems:
The type com.mycompany.xyz.comm.responses.CResponse cannot be resolved. It is indirectly referenced from required .class files
The import com.mycompany.xyz.comm.constants cannot be resolved
The import com.mycompany.xyz.comm.errorcodes cannot be resolved
The import com.mycompany.xyz.comm.exception cannot be resolved
The import com.mycompany.xyz.comm.exception cannot be resolved
The import com.mycompany.xyz.comm.exception cannot be resolved
The import com.mycompany.xyz.comm.responses.CResponse cannot be resolved
The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
The import com.mycompany.xyz.sl cannot be resolved
The import com.mycompany.xyz.sl cannot be resolved
The import com.mycompany.xyz.sl cannot be resolved
The import com.mycompany.xyz.sl cannot be resolved
CResponse cannot be resolved to a type
The method createMyCase(Map<String,String>) from the type PCommuImpl refers to the missing type Exception
The type com.mycompany.xyz.comm.exception.SOperationException cannot be resolved. It is indirectly referenced from required .class files
The method getPControlOperationException(PCommuErrors, String, String) from the type CommExceptionHandler refers to the missing type SOperationException
SException cannot be resolved to a type
SResponse cannot be resolved
SSystemException cannot be resolved to a type
The type com.mycompany.xyz.comm.exception.SSystemException cannot be resolved. It is indirectly referenced from required .class files
The method getSystemException() from the type PCommHelper refers to the missing type SSystemException
CResponse cannot be resolved to a type
SResponse cannot be resolved
SException cannot be resolved to a type
SResponse cannot be resolved to a type
PControlService cannot be resolved to a type
PControlServiceImpl cannot be resolved to a type
SResponse cannot be resolved to a type
CErrors cannot be resolved to a variable
SConstants cannot be resolved to a variable
SSystemException cannot be resolved to a type
CErrors cannot be resolved to a variable
SConstants cannot be resolved to a variable
SException cannot be resolved to a type
SResponse cannot be resolved
SErrorResponse cannot be resolved to a type
SSystemException cannot be resolved to a type
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:340) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:540) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:502) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.1.GA.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.10.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.10.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.10.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.10.Final.jar:]
at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_20]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4316) CLONE - HornetQ listens on ::ffff:127.0.0.1 when bound to ::1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4316?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-4316:
---------------------------------------
Problem is the messaging subsystem is passing InetSocketAddress.getHostName() instead of InetSocketAddress.getAddress().getHostAddress() into the HQ configuration object map.
> CLONE - HornetQ listens on ::ffff:127.0.0.1 when bound to ::1
> -------------------------------------------------------------
>
> Key: AS7-4316
> URL: https://issues.jboss.org/browse/AS7-4316
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JMS
> Affects Versions: 7.0.0.Final, 7.0.1.Final, 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Fix For: 7.1.2.Final
>
>
> When server is bound to ipv6 loop-back address ::1 then HornetQ listens on ::ffff:127.0.0.1.
> {code}
> netstat -npl | grep java
> (Not all processes could be identified, non-owned process info
> will not be shown, you would have to be root to see it all.)
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 1438/java
> tcp 0 0 ::1:9999 :::* LISTEN 1438/java
> tcp 0 0 ::1:8080 :::* LISTEN 1438/java
> tcp 0 0 ::1:4447 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 1438/java
> tcp 0 0 ::1:9990 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 1438/java
> udp 0 5048 :::45329 :::* 1438/java
> udp 0 0 :::9875 :::* 1438/java
> udp 0 0 ::ffff:224.0.1.105:23364 :::* 1438/java
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4317) CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4317?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4317:
----------------------------------
Comment: was deleted
(was: Problem is the jacorb subsystem is passing InetSocketAddress.getHostName() instead of InetSocketAddress.getAddress().getHostAddress() into the jacorb properties map.)
> CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
> ---------------------------------------------------------------------
>
> Key: AS7-4317
> URL: https://issues.jboss.org/browse/AS7-4317
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, IIOP
> Affects Versions: 7.1.0.Final, 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 7.1.2.Final
>
>
> When server is bound to ipv6 loop-back address ::1 then Jacorb listens on ::ffff:127.0.0.1.
> {code}
> netstat -npl | grep java
> (Not all processes could be identified, non-owned process info
> will not be shown, you would have to be root to see it all.)
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 1438/java
> tcp 0 0 ::1:9999 :::* LISTEN 1438/java
> tcp 0 0 ::1:8080 :::* LISTEN 1438/java
> tcp 0 0 ::1:4447 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 1438/java
> tcp 0 0 ::1:9990 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 1438/java
> udp 0 5048 :::45329 :::* 1438/java
> udp 0 0 :::9875 :::* 1438/java
> udp 0 0 ::ffff:224.0.1.105:23364 :::* 1438/java
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4317) CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4317?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-4317:
---------------------------------------
Problem is the jacorb subsystem is passing InetSocketAddress.getHostName() instead of InetSocketAddress.getAddress().getHostAddress() into the jacorb properties map.
> CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
> ---------------------------------------------------------------------
>
> Key: AS7-4317
> URL: https://issues.jboss.org/browse/AS7-4317
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, IIOP
> Affects Versions: 7.1.0.Final, 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 7.1.2.Final
>
>
> When server is bound to ipv6 loop-back address ::1 then Jacorb listens on ::ffff:127.0.0.1.
> {code}
> netstat -npl | grep java
> (Not all processes could be identified, non-owned process info
> will not be shown, you would have to be root to see it all.)
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 1438/java
> tcp 0 0 ::1:9999 :::* LISTEN 1438/java
> tcp 0 0 ::1:8080 :::* LISTEN 1438/java
> tcp 0 0 ::1:4447 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 1438/java
> tcp 0 0 ::1:9990 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 1438/java
> udp 0 5048 :::45329 :::* 1438/java
> udp 0 0 :::9875 :::* 1438/java
> udp 0 0 ::ffff:224.0.1.105:23364 :::* 1438/java
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4317) CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4317?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-4317:
---------------------------------------
Problem is the jacorb subsystem is passing InetSocketAddress.getHostName() instead of InetSocketAddress.getAddress().getHostAddress() into the jacorb properties map.
> CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
> ---------------------------------------------------------------------
>
> Key: AS7-4317
> URL: https://issues.jboss.org/browse/AS7-4317
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, IIOP
> Affects Versions: 7.1.0.Final, 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 7.1.2.Final
>
>
> When server is bound to ipv6 loop-back address ::1 then Jacorb listens on ::ffff:127.0.0.1.
> {code}
> netstat -npl | grep java
> (Not all processes could be identified, non-owned process info
> will not be shown, you would have to be root to see it all.)
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 1438/java
> tcp 0 0 ::1:9999 :::* LISTEN 1438/java
> tcp 0 0 ::1:8080 :::* LISTEN 1438/java
> tcp 0 0 ::1:4447 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 1438/java
> tcp 0 0 ::1:9990 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 1438/java
> udp 0 5048 :::45329 :::* 1438/java
> udp 0 0 :::9875 :::* 1438/java
> udp 0 0 ::ffff:224.0.1.105:23364 :::* 1438/java
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4317) CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4317?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4317:
----------------------------------
Priority: Critical (was: Blocker)
> CLONE - Jacorb listens on ::ffff:127.0.0.1 even is should bind to ::1
> ---------------------------------------------------------------------
>
> Key: AS7-4317
> URL: https://issues.jboss.org/browse/AS7-4317
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, IIOP
> Affects Versions: 7.1.0.Final, 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 7.1.2.Final
>
>
> When server is bound to ipv6 loop-back address ::1 then Jacorb listens on ::ffff:127.0.0.1.
> {code}
> netstat -npl | grep java
> (Not all processes could be identified, non-owned process info
> will not be shown, you would have to be root to see it all.)
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 1438/java
> tcp 0 0 ::1:9999 :::* LISTEN 1438/java
> tcp 0 0 ::1:8080 :::* LISTEN 1438/java
> tcp 0 0 ::1:4447 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 1438/java
> tcp 0 0 ::1:9990 :::* LISTEN 1438/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 1438/java
> udp 0 5048 :::45329 :::* 1438/java
> udp 0 0 :::9875 :::* 1438/java
> udp 0 0 ::ffff:224.0.1.105:23364 :::* 1438/java
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months