[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4331:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1188420|https://bugzilla.redhat.com/show_bug.cgi?id=1188420] from POST to ASSIGNED
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4512) Upgrade Weld to 2.2.11.Final
by Jozef Hartinger (JIRA)
Jozef Hartinger created WFLY-4512:
-------------------------------------
Summary: Upgrade Weld to 2.2.11.Final
Key: WFLY-4512
URL: https://issues.jboss.org/browse/WFLY-4512
Project: WildFly
Issue Type: Component Upgrade
Components: CDI / Weld
Reporter: Jozef Hartinger
Assignee: Jozef Hartinger
Priority: Critical
Fix For: 9.0.0.CR1
Tracker issue to upgrade Weld to the latest version before releasing WildFly 9 Final.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4511) CMTTxInterceptor.invokeInOurTx contains stale code handling ApplicationDeadlockException
by Chao Wang (JIRA)
Chao Wang created WFLY-4511:
-------------------------------
Summary: CMTTxInterceptor.invokeInOurTx contains stale code handling ApplicationDeadlockException
Key: WFLY-4511
URL: https://issues.jboss.org/browse/WFLY-4511
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 9.0.0.Beta2
Reporter: Chao Wang
Assignee: Chao Wang
Priority: Minor
Description of problem:
* git://git.app.eng.bos.redhat.com/jbossas/jboss-as.git
* ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java
There is stale code catching ApplicationDeadlockException and attempting to retry the transaction. This results in a failure if the exception is raised and retry does not occur.
Version-Release number of selected component (if applicable):
How reproducible:
Consistently
Steps to Reproduce:
* Visual Inspection
OR
* Register a transaction Synchronization object which raises the exception during beforeCompletion()
Note that EAP no longer raises this exception. The catch block code handling ApplicationDeadlockException seems to be an artifact of EAP 4 and should simply be removed.
Actual results:
Retry does not occur
Expected results:
Retry should not be attempted by this code
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4510) "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4510?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-4510.
-------------------------------
Labels: (was: jdbc job-repository wildfly)
Fix Version/s: 9.0.0.Beta1
Resolution: Done
This Seems to be fixed in WildFly 9.0.0.Beta1.
> "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4510
> URL: https://issues.jboss.org/browse/WFLY-4510
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Environment: Windows 8.1 x64, JDK 1.8.0_20, Wildfly 8.2.0.Final
> Reporter: Renann Prado
> Assignee: James Perkins
> Fix For: 9.0.0.Beta1
>
>
> The below exception is thrown after the DataSource is disabled/enabled.
> I read that in Wildfly 9 onwards disabling/enabling a DataSource is deprecated, so *maybe* this problem won`t happen in next Wildfly version.
> {noformat}
> 2015-04-12 16:48:07,691 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /XXXXXe-web/NewServlet: javax.batch.operations.BatchRuntimeException: JBERET000622: Failed to obtain connection from org.jboss.jca.adapters.jdbc.WrapperDataSource@da89438, java:jboss/dasources/MySQL
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:802) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.insertJobInstance(JdbcRepository.java:264) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.AbstractRepository.createJobInstance(AbstractRepository.java:91) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:82) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.invokeTransaction(JobOperatorImpl.java:295) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at com.test.NewServlet.processRequest(NewServlet.java:64) [classes:]
> at com.test.NewServlet.doGet(NewServlet.java:95) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:800) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 36 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:371)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:421)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:515)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> ... 37 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4510) "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4510?page=com.atlassian.jira.plugin.... ]
James Perkins moved JBERET-155 to WFLY-4510:
--------------------------------------------
Project: WildFly (was: JBeret)
Key: WFLY-4510 (was: JBERET-155)
Affects Version/s: (was: 1.0.2.Final)
Component/s: Batch
(was: jberet-core)
> "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4510
> URL: https://issues.jboss.org/browse/WFLY-4510
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Environment: Windows 8.1 x64, JDK 1.8.0_20, Wildfly 8.2.0.Final
> Reporter: Renann Prado
> Assignee: James Perkins
> Labels: jdbc, job-repository, wildfly
>
> The below exception is thrown after the DataSource is disabled/enabled.
> I read that in Wildfly 9 onwards disabling/enabling a DataSource is deprecated, so *maybe* this problem won`t happen in next Wildfly version.
> {noformat}
> 2015-04-12 16:48:07,691 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /XXXXXe-web/NewServlet: javax.batch.operations.BatchRuntimeException: JBERET000622: Failed to obtain connection from org.jboss.jca.adapters.jdbc.WrapperDataSource@da89438, java:jboss/dasources/MySQL
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:802) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.insertJobInstance(JdbcRepository.java:264) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.AbstractRepository.createJobInstance(AbstractRepository.java:91) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:82) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.invokeTransaction(JobOperatorImpl.java:295) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at com.test.NewServlet.processRequest(NewServlet.java:64) [classes:]
> at com.test.NewServlet.doGet(NewServlet.java:95) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:800) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 36 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:371)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:421)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:515)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> ... 37 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-641) The discovery-option "module" attribute should support undefined values
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-641:
---------------------------------------
Summary: The discovery-option "module" attribute should support undefined values
Key: WFCORE-641
URL: https://issues.jboss.org/browse/WFCORE-641
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.CR1
The xsd says the following for the discovery-optionType 'module' attribute:
{code}
<xs:attribute name="module" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>
The module from which the DiscoveryOption implementation should be loaded. If not provided,
the DiscoveryOption implementation must be available from the Host Controller's own module.
</xs:documentation>
</xs:annotation>
</xs:attribute>
{code}
But the MODULE attribute definition does not allow undefined.
But still, DiscoveryOptionAddHandler is coded as if undefined is allowed, but poorly so as it would pass an illegal null into ModuleIdentifier.fromString.
I like the behavior described in the xsd and think the AD and the handlers should be corrected.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods
by Jakub Grabowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ]
Jakub Grabowski reopened WFLY-4289:
-----------------------------------
According to my previous comment... I tried patching, but still I get not allowed on one-way methods when @RolesAllowed is set on class level.
> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
> Key: WFLY-4289
> URL: https://issues.jboss.org/browse/WFLY-4289
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Jakub Grabowski
> Assignee: Jim Ma
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-640) Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found"
by Brandon Gaisford (JIRA)
[ https://issues.jboss.org/browse/WFCORE-640?page=com.atlassian.jira.plugin... ]
Brandon Gaisford commented on WFCORE-640:
-----------------------------------------
Darran,
Regarding the timeliness, understood. I spent a good deal of time over the weekend researching the issue, most notably trying to get my head around Windows file permissions. I feel like I have a good handle on the permissions now and a reasonable Windows 7 test environment. Regarding JDK7, I believe there were updates [1] that may allow AddUser code to check some permissions up front.
In order to limit the scope of the analysis/development I'm going to make some assumptions:
i) Will assume end user installed WildFly directory structure matches that generated by the WildFly build process
ii) Will assume end user file permissions do not prevent user from executing add-user.bat
Will do my best to get you updates (assuming there are some) quickly.
[1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6203387
> Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found"
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-640
> URL: https://issues.jboss.org/browse/WFCORE-640
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods
by Jakub Grabowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ]
Jakub Grabowski commented on WFLY-4289:
---------------------------------------
[~jim.ma] I've checked resolution by pathching wildfly 8.2 code with the change you mentioned. Unfortunately it doesn't resolve my issue. It works for @PermitAll only, but fails for one-way methods when there's RolesAllowed on class level. Have you check this scenario?
> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
> Key: WFLY-4289
> URL: https://issues.jboss.org/browse/WFLY-4289
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Jakub Grabowski
> Assignee: Jim Ma
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months