[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
13 years, 7 months
[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
13 years, 7 months
[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
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 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
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)
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
13 years, 7 months
[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
13 years, 7 months
[JBoss JIRA] (AS7-6105) Shutdown process hangs using thread pool executor
by Eiichi Nagai (JIRA)
Eiichi Nagai created AS7-6105:
---------------------------------
Summary: 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.3.Final (EAP), 7.1.1.Final
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
13 years, 7 months
[JBoss JIRA] (AS7-6105) Shutdown process hangs using thread pool executor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-6105:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=882048
> 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
13 years, 7 months
[JBoss JIRA] (AS7-6103) ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-6103?page=com.atlassian.jira.plugin.s... ]
Chao Wang reassigned AS7-6103:
------------------------------
Assignee: Chao Wang
> ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency
> ----------------------------------------------------------------------------------------------------
>
> Key: AS7-6103
> URL: https://issues.jboss.org/browse/AS7-6103
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.2.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Critical
> Labels: dependency, modules
>
> ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency.
> The codes below take care of unload operation.
> {code:title=org.jboss.as.server.moduleservice.ServiceModuleLoader.java|borderStyle=solid}
> case STOP_REQUESTED_to_STOPPING: {
> log.tracef("serviceStopping: %s", controller);
> ModuleSpec moduleSpec = this.moduleSpec;
> try {
> *Module module = loadModule(moduleSpec.getModuleIdentifier());*
> *unloadModuleLocal(module);*
> } catch (ModuleLoadException e) {
> // ignore, the module should always be already loaded by this point,
> // and if not we will only mask the true problem
> }
> // TODO: what if the service is restarted?
> controller.removeListener(this);
> break;
> }
> {code}
> The line *unloadModuleLocal(module)* can not be reached because the previous loadModule(moduleSpec.getModuleIdentifier() will throw ModuleLoadException if module has dependency problem.
--
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] (AS7-6104) jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
by Raymond Naseef (JIRA)
[ https://issues.jboss.org/browse/AS7-6104?page=com.atlassian.jira.plugin.s... ]
Raymond Naseef updated AS7-6104:
--------------------------------
Steps to Reproduce:
1) Create org.postgresql module with main folder holding postgresql-9.1-901-1.jdbc4.jar, module.xml (at end of this field)
2) jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql"
3) jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:remove"
module.xml:
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
<!--
From: https://community.jboss.org/wiki/JBossAS7-DatasourceConfigurationForPostg...
-->
<!-- Load with jboss-cli command:
/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql)
-->
<resources>
<resource-root path="postgresql-9.1-901-1.jdbc4.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
was:
Create org.postgresql module with main folder holding postgresql-9.1-901-1.jdbc4.jar, module.xml:
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
<!--
From: https://community.jboss.org/wiki/JBossAS7-DatasourceConfigurationForPostg...
-->
<!-- Load with jboss-cli command:
/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql)
-->
<resources>
<resource-root path="postgresql-9.1-901-1.jdbc4.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
> jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6104
> URL: https://issues.jboss.org/browse/AS7-6104
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Professional SP1
> Reporter: Raymond Naseef
> Assignee: Jason Greene
> Labels: jboss-as7, modules, postgresql
>
> NullPointerException during jboss-cli remove with commands:
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql"
> * this works
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:remove"
> MS-DOS Console:
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> Server Log:
> 23:17:42,627 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 19) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "postgresql-driver")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.doRemove(OperationContextImpl.java:298) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.OperationContextImpl.removeService(OperationContextImpl.java:293) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.connector.subsystems.datasources.JdbcDriverRemove.performRuntime(JdbcDriverRemove.java:66)
> at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
--
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