December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3676) drl cann't debuging in Eclipse IDE

by Kevin Kelleher (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3676?page=com.atlassian.jira.plug... ] Kevin Kelleher commented on JBRULES-3676: ----------------------------------------- Hi, Could I get an indication if/when this issue will be addressed please? Is this seen as a priority fix? Again, thanks in advance ... > drl cann't debuging in Eclipse IDE > ---------------------------------- > > Key: JBRULES-3676 > URL: https://issues.jboss.org/browse/JBRULES-3676 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core (expert) > Affects Versions: 5.5.0.CR1 > Environment: Eclipse 4.2，JDK1.7，Drools5.5CR1 > Reporter: hongkun an > Assignee: Mark Proctor > > i follow url content > http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/... > I want debug drl example（HelloWord）in eclipse ide，but，only debug java file，cann't debug drl，why？ -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6107) Adding a capability takes effect without subsystem restart

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6107?page=com.atlassian.jira.plugin.s... ] SBS JIRA Integration updated AS7-6107: -------------------------------------- Forum Reference: https://community.jboss.org/message/780175#780175 > Adding a capability takes effect without subsystem restart > ---------------------------------------------------------- > > Key: AS7-6107 > URL: https://issues.jboss.org/browse/AS7-6107 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Reporter: Thomas Diesler > Assignee: David Bosschaert > Fix For: 7.2.0.Alpha1 > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4610) Interface not found when deploying an EJB of class A that extends B and B implements an Interface

by Christoph Gutmann (JIRA)

[ https://issues.jboss.org/browse/AS7-4610?page=com.atlassian.jira.plugin.s... ] Christoph Gutmann commented on AS7-4610: ---------------------------------------- OK, thanks for checking. Strange thing, this means in class A has to redeclarate that it implements the interface. This seems to be a fundamental difference between SE and EE. > Interface not found when deploying an EJB of class A that extends B and B implements an Interface > ------------------------------------------------------------------------------------------------- > > Key: AS7-4610 > URL: https://issues.jboss.org/browse/AS7-4610 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.1.Final > Reporter: Christoph Gutmann > Assignee: jaikiran pai > > The class hierarchy is as follows: > -class EJBClient extends class Client (POJO) > -class Client implements interface MyInterface (POJO) > When deploying EJB 'EJBClient', JBoss does not resolve indirectly implemented interface by an EJB via a superclass. This did work in JBoss5. When deploying such an EJB you get the error message > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Bean class org.foo.EJBClient specifies @Local annotation, but does not implement 1 interface > {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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6107) Adding a capability takes effect without subsystem restart

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-6107: ----------------------------------- Summary: Adding a capability takes effect without subsystem restart Key: AS7-6107 URL: https://issues.jboss.org/browse/AS7-6107 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: David Bosschaert Fix For: 7.2.0.Alpha1 -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6035) Improper use of OperationContext.restartRequired()

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/AS7-6035?page=com.atlassian.jira.plugin.s... ] Ivo Studensky updated AS7-6035: ------------------------------- Fix Version/s: 7.1.4.Final (EAP) > Improper use of OperationContext.restartRequired() > -------------------------------------------------- > > Key: AS7-6035 > URL: https://issues.jboss.org/browse/AS7-6035 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Brian Stansberry > Assignee: Ivo Studensky > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > > Look or an fix uses of OperationContext.restartRequired() that should be using reloadRequired(). There are very few reasons why a full process restart should be needed for a configuration model change to take effect. Typically a full process restart would only be needed for a domain mode server whose JVM configuration settings have been changed in the host model. > Running "git grep restartRequired()" shows the following suspicious uses: > logging/src/main/java/org/jboss/as/logging/HandlerOperations.java: context.restartRequired(); > logging/src/main/java/org/jboss/as/logging/HandlerOperations.java: context.restartRequired(); > server/src/main/java/org/jboss/as/server/operations/ServerRestartRequiredHandler.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/ClientConfigAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/ClientConfigRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/EndpointConfigAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/EndpointConfigRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerChainAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerChainRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/PropertyAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/PropertyRemove.java: context.restartRequired(); -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6106) Improper use of OperationContext.restartRequired() on 7.1 branch

by Ivo Studensky (JIRA)

Ivo Studensky created AS7-6106: ---------------------------------- Summary: Improper use of OperationContext.restartRequired() on 7.1 branch Key: AS7-6106 URL: https://issues.jboss.org/browse/AS7-6106 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.3.Final (EAP) Reporter: Ivo Studensky Fix For: 7.1.4.Final (EAP) This actually is a subtask of AS7-6035 for additional changes in the 7.1 branch. In particular for two remaining occurrences of OperationContext.restartRequired() at: {noformat} org.jboss.as.logging.handlers.file.HandlerFileChange org.jboss.as.connector.subsystems.datasources.DataSourceDisable {noformat} Here is description of the original jira: {quote} Look or an fix uses of OperationContext.restartRequired() that should be using reloadRequired(). There are very few reasons why a full process restart should be needed for a configuration model change to take effect. Typically a full process restart would only be needed for a domain mode server whose JVM configuration settings have been changed in the host model. {quote} -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6035) Improper use of OperationContext.restartRequired()

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/AS7-6035?page=com.atlassian.jira.plugin.s... ] Ivo Studensky updated AS7-6035: ------------------------------- Fix Version/s: (was: 7.1.4.Final (EAP)) > Improper use of OperationContext.restartRequired() > -------------------------------------------------- > > Key: AS7-6035 > URL: https://issues.jboss.org/browse/AS7-6035 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Brian Stansberry > Assignee: Ivo Studensky > Fix For: 7.2.0.Alpha1 > > > Look or an fix uses of OperationContext.restartRequired() that should be using reloadRequired(). There are very few reasons why a full process restart should be needed for a configuration model change to take effect. Typically a full process restart would only be needed for a domain mode server whose JVM configuration settings have been changed in the host model. > Running "git grep restartRequired()" shows the following suspicious uses: > logging/src/main/java/org/jboss/as/logging/HandlerOperations.java: context.restartRequired(); > logging/src/main/java/org/jboss/as/logging/HandlerOperations.java: context.restartRequired(); > server/src/main/java/org/jboss/as/server/operations/ServerRestartRequiredHandler.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/ClientConfigAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/ClientConfigRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/EndpointConfigAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/EndpointConfigRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerChainAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerChainRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/HandlerRemove.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/PropertyAdd.java: context.restartRequired(); > webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/PropertyRemove.java: context.restartRequired(); -- 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, 1 month

1
0
0 / 0

[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 updated JBRULES-3702: -------------------------------------- Description: 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} was: 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} > 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBRULES-3702) Log message when a rule is fired (RHS is called) when logging level is TRACE

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3702: ----------------------------------------- Summary: 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6105) Shutdown process hangs using thread pool executor

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ] SBS JIRA Integration updated AS7-6105: -------------------------------------- Forum Reference: https://community.jboss.org/message/766336#766336 > Shutdown process hangs using thread pool executor > ------------------------------------------------- > > Key: AS7-6105 > URL: https://issues.jboss.org/browse/AS7-6105 > Project: Application Server 7 > Issue Type: Bug > Components: Web > Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP) > Reporter: Eiichi Nagai > Assignee: Remy Maucherat > > When AJP connecotr uses thread pool executor configuration[1], AJP's worker thread is waited by AjpProcessor.read()[2]. QueueExecuter recognizes it as active thread. Therefor, unless httpd server shut down, EAP server shutdown process does not finish forever. > [1] standalone.xml > <subsystem xmlns="urn:jboss:domain:threads:1.1"> > <bounded-queue-thread-pool name="http-executor"> > <queue-length count="1"/> > <max-threads count="1"/> > </bounded-queue-thread-pool> > </subsystem> > --- snip --- > <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" executor="http-executor"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > </subsystem> > [2] > "http-executor-threads - 1" prio=6 tid=0x55515000 nid=0x20c0 runnable [0x5590f000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1131) > at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1213) > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:451) > at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:519) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821) > at java.lang.Thread.run(Thread.java:662) > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012