[JBoss JIRA] (AS7-4321) OSGi management console needs inspector of wiring
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-4321?page=com.atlassian.jira.plugin.s... ]
Heiko Braun updated AS7-4321:
-----------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.CR1)
> 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
> Fix For: 7.3.0.Alpha1
>
>
> 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
13 years, 7 months
[JBoss JIRA] (JBRULES-3702) Log message when a rule is fired (RHS is called) when logging level is TRACE
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3702?page=com.atlassian.jira.plug... ]
Geoffrey De Smet commented on JBRULES-3702:
-------------------------------------------
This partially duplicates KnowledgeRuntimeLogger which is clunky to enable.
To enable KnowledgeRuntimeLogger, requires a programmatic change, not a configuration change.
I would argue: every Logger should be able to be enabled through normal logging configuration (= logback.xml, log4j.xml, ...).
Just like in any other framework (hibernate, weld, spring, ...)
So maybe for 6.0, we can replace KnowledgeRuntimeLogger by normal logging?
> Log message when a rule is fired (RHS is called) when logging level is TRACE
> ----------------------------------------------------------------------------
>
> Key: JBRULES-3702
> URL: https://issues.jboss.org/browse/JBRULES-3702
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-core (expert)
> Reporter: Geoffrey De Smet
> Assignee: Mark Proctor
>
> On the user forum, I've often seen questions like this:
> "- Can I trace which rules are executed with what bounded variables and in which order"
> Debugging in the IDE's doesn't cut it (eclipse plugin is borked and intellij/netbeans doesn't support debugging DRL).
> Instead something like this in the code would help:
> {code}
> if (logger.isTraceEnabled() { // returns immediately => NO NOTICEABLE PERFORMANCE DELAY IN NON-TRACE MODE
> List<...> boundedVariables = ...; // Retrieve bounded variables only in TRACE mode
> logger.trace(" Rule fired with name ({}) and boundedVariables ({})", ruleName, boundedVariables)
> }
> {code}
> Then the user just has to do this in his logback.xml (or similar in log4j.xml):
> {code}
> <logger name="org.drools" level="trace"/>
> {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, 7 months