[JBoss JIRA] (AS7-6144) Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-6144?page=com.atlassian.jira.plugin.s... ]
Scott Marlow resolved AS7-6144.
-------------------------------
Resolution: Duplicate Issue
Already fixed for Hibernate 4.1.7 via HHH-7563
> Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6144
> URL: https://issues.jboss.org/browse/AS7-6144
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Environment: JBoss AS 7.1.2.Final, Hibernate 4.1.2.Final
> Reporter: Marek Posolda
> Assignee: Scott Marlow
>
> Normally UserTransaction is available in JBoss via JNDI lookup to "java:comp/UserTransaction" . But sometimes this approach does not work (For example if we have custom worker threads in our application or we are starting our AS7 deployment with custom MSC thread before "java:comp" context is available to JNDI)
> So it may be good to fallback to "java:jboss/UserTransaction", which is available in JBoss AS7 even from custom threads.
> Is it possible to change "org.jboss.as.jpa.hibernate4.JBossAppServerJtaPlatform" or "org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" to have method locateUserTransaction() similar to this?:
> {code}
> public static final String AS7_NEW_UT_NAME = "java:jboss/UserTransaction";
> @Override
> protected UserTransaction locateUserTransaction() {
> try {
> return (UserTransaction) jndiService().locate(UT_NAME);
> }
> catch(JndiException jndiException) {
> return (UserTransaction) jndiService().locate(AS7_NEW_UT_NAME);
> }
> }
> {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-6144) Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-6144?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on AS7-6144:
-----------------------------------
Internally, Hibernate is already looking up the java:jboss/UserTransaction first (HHH-7563), so no need to change AS code.
I pushed a potential fix to https://github.com/scottmarlow/jboss-as/tree/AS7-6144_utlookup if we ever need it.
> Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6144
> URL: https://issues.jboss.org/browse/AS7-6144
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Environment: JBoss AS 7.1.2.Final, Hibernate 4.1.2.Final
> Reporter: Marek Posolda
> Assignee: Scott Marlow
>
> Normally UserTransaction is available in JBoss via JNDI lookup to "java:comp/UserTransaction" . But sometimes this approach does not work (For example if we have custom worker threads in our application or we are starting our AS7 deployment with custom MSC thread before "java:comp" context is available to JNDI)
> So it may be good to fallback to "java:jboss/UserTransaction", which is available in JBoss AS7 even from custom threads.
> Is it possible to change "org.jboss.as.jpa.hibernate4.JBossAppServerJtaPlatform" or "org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" to have method locateUserTransaction() similar to this?:
> {code}
> public static final String AS7_NEW_UT_NAME = "java:jboss/UserTransaction";
> @Override
> protected UserTransaction locateUserTransaction() {
> try {
> return (UserTransaction) jndiService().locate(UT_NAME);
> }
> catch(JndiException jndiException) {
> return (UserTransaction) jndiService().locate(AS7_NEW_UT_NAME);
> }
> }
> {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-6144) Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-6144?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on AS7-6144:
-----------------------------------
Good point Stuart, I'll either do that or keep a reference to the UT around to return. We currently do that for returning the TM + TSR to Hibernate ORM.
> Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6144
> URL: https://issues.jboss.org/browse/AS7-6144
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Environment: JBoss AS 7.1.2.Final, Hibernate 4.1.2.Final
> Reporter: Marek Posolda
> Assignee: Scott Marlow
>
> Normally UserTransaction is available in JBoss via JNDI lookup to "java:comp/UserTransaction" . But sometimes this approach does not work (For example if we have custom worker threads in our application or we are starting our AS7 deployment with custom MSC thread before "java:comp" context is available to JNDI)
> So it may be good to fallback to "java:jboss/UserTransaction", which is available in JBoss AS7 even from custom threads.
> Is it possible to change "org.jboss.as.jpa.hibernate4.JBossAppServerJtaPlatform" or "org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" to have method locateUserTransaction() similar to this?:
> {code}
> public static final String AS7_NEW_UT_NAME = "java:jboss/UserTransaction";
> @Override
> protected UserTransaction locateUserTransaction() {
> try {
> return (UserTransaction) jndiService().locate(UT_NAME);
> }
> catch(JndiException jndiException) {
> return (UserTransaction) jndiService().locate(AS7_NEW_UT_NAME);
> }
> }
> {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 Eiichi Nagai (JIRA)
[ https://issues.jboss.org/browse/AS7-6105?page=com.atlassian.jira.plugin.s... ]
Eiichi Nagai reopened AS7-6105:
-------------------------------
I have reopened this JIRA. I am interested in David's comment. I believe that you tackle again regarding this behavior.
> 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-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:
--------------------------------
Description:
NullPointerException during jboss-cli remove with command:
jboss-cli --connect command="/subsystem=datasources/jdbc-driver=bop:remove"
Console and log below.
This happens when standalone.xml has XML entry for driver that does not exist (see "Steps to Reproduce"). I have also seen this happen in a case where the driver does exist; not sure how the latter happened, or how important that is.
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]
was:
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]
> 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: Domain Management, JCA
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Professional SP1
> Reporter: Raymond Naseef
> Assignee: Stefano Maestri
> Labels: jboss-as7, modules, postgresql
>
> NullPointerException during jboss-cli remove with command:
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=bop:remove"
> Console and log below.
> This happens when standalone.xml has XML entry for driver that does not exist (see "Steps to Reproduce"). I have also seen this happen in a case where the driver does exist; not sure how the latter happened, or how important that is.
> 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
[JBoss JIRA] (AS7-6144) Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6144?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6144:
-------------------------------------
We might as well just use java:jboss/UserTransaction all the time, no need for the fallback, as the returned object is the same.
> Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6144
> URL: https://issues.jboss.org/browse/AS7-6144
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Environment: JBoss AS 7.1.2.Final, Hibernate 4.1.2.Final
> Reporter: Marek Posolda
> Assignee: Scott Marlow
>
> Normally UserTransaction is available in JBoss via JNDI lookup to "java:comp/UserTransaction" . But sometimes this approach does not work (For example if we have custom worker threads in our application or we are starting our AS7 deployment with custom MSC thread before "java:comp" context is available to JNDI)
> So it may be good to fallback to "java:jboss/UserTransaction", which is available in JBoss AS7 even from custom threads.
> Is it possible to change "org.jboss.as.jpa.hibernate4.JBossAppServerJtaPlatform" or "org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" to have method locateUserTransaction() similar to this?:
> {code}
> public static final String AS7_NEW_UT_NAME = "java:jboss/UserTransaction";
> @Override
> protected UserTransaction locateUserTransaction() {
> try {
> return (UserTransaction) jndiService().locate(UT_NAME);
> }
> catch(JndiException jndiException) {
> return (UserTransaction) jndiService().locate(AS7_NEW_UT_NAME);
> }
> }
> {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-6128) In domain mode after some CLI I was not able to restart a particular host until..
by Jim Tyrrell (JIRA)
[ https://issues.jboss.org/browse/AS7-6128?page=com.atlassian.jira.plugin.s... ]
Jim Tyrrell commented on AS7-6128:
----------------------------------
The CLI never stopped responding, however I was not able to, in as I said, in the web UI click on the stop button of the server and have it work, it just errored out with a general error message . I just got an error message. This happened only once, but if it can happen at all I am concerned.
I appreciate this is a hard bug to track down, but it most certainly appeared, and was very disconcerting.
Where are the instructions or scripts I should invoke when having an odd issue to get as much information as possible?
> In domain mode after some CLI I was not able to restart a particular host until..
> ---------------------------------------------------------------------------------
>
> Key: AS7-6128
> URL: https://issues.jboss.org/browse/AS7-6128
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Linux and EAP 6
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
>
> Running the examples in the JB348 Admin II class around the CLI section I uncovered an odd error, that I was not able to reproduce, and no one else seemed to have, but I thought I should log it here.
> In the class last week I was doing the CLI activities per the guide on a domain instance. I fat fingered a bunch of things, and was getting errors. Once I was done making the changes with any errors I tried to restart host1 in the web console. This errored out without a good error message. After a few times of that I tried cntrl-cing in the console, only to have the server shutdown after about 5 minutes or so of hitting cntrl-c. I did not notice any error messages, but it makes me think some sort of racing, or locking condition exists in domain mode.
--
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] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ]
Anil Saldhana commented on SECURITY-709:
----------------------------------------
Our authentication is not coupled either to the web container or LDAP server. What decides is the security domain. The security domain defines a bunch of login modules. So when JAAS system throws an loginexception, we return either true/false as to the status of the authentication process. The web container's security uses this true/false to either proceed to authorization checks or return 401 (case of BASIC, SPNego usecases).
Yi, we cannot accept this JIRA request.
> Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available
> ---------------------------------------------------------------------------------------
>
> Key: SECURITY-709
> URL: https://issues.jboss.org/browse/SECURITY-709
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Affects Versions: PicketBox_v4_0_7
> Reporter: Yi Chen
> Assignee: Anil Saldhana
>
> I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method:
> ...
> catch (LoginException e)
> {
> // Don't log anonymous user failures unless trace level logging is on
> if (principal != null && principal.getName() != null || trace)
> log.error("Login failure", e);
> authException = e;
> }
> // Set the security association thread context info exception
> SubjectActions.setContextInfo("org.jboss.security.exception", authException);
> return authenticated;
> }
> So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client.
> Steps to reproduce:
> Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401.
--
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