[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-6999:
-----------------------------------
Component/s: Security
> client authentication not behaving correctly?
> ---------------------------------------------
>
> Key: WFLY-6999
> URL: https://issues.jboss.org/browse/WFLY-6999
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.2.Final
> Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
> Reporter: Pascal Knüppel
> Assignee: Darran Lofthouse
>
> I am currently reading the wildfly 9 documentation and I started to test some things and I began with client certificate authentication since I am going to need this feature in short future.
> I found a way to realize mutual authentication but this one is rather a workaround than anything else.
> For starters it is my intention to deploy a web application on an https-port that requires client authentication. Additionally I want other applications under the same port that do not require client authentication. This is a feature that does not seem to be possible eventhough the documentation uses references to the security-domain section here.
> Now I will provide my configuration how I configured my application and my wildfly server to activate client cert authentication. Note that I had to configure a second virtual host with a new port to accomplish this.
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <!--<login-config>-->
> <!--<auth-method>CLIENT-CERT</auth-method>-->
> <!--<!–<realm-name>secured-app-domain</realm-name>–>-->
> <!--</login-config>-->
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <server-instance>client-auth-server</server-instance>
> <virtual-host>client-auth-host</virtual-host>
> <!--<security-domain>secured-app-domain</security-domain>-->
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="gfi"/>
> </authentication>
> </security-realm>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="client-auth-server">
> <https-listener name="secured-https" socket-binding="client-auth-https" security-realm="SSLRealm" verify-client="REQUIRED"/>
> <host name="client-auth-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> <socket-binding name="client-auth-https" port="${jboss.https.port:8444}"/>
> {code}
> This is everything needed for client-authentication if roles are not necessary. In case of using roles I had to add the uncommented security-domain not listed in the above code.
> Now to the point:
> this configuration seems undesirable to me and I am not sure if this is really wanted like this... as you can see in *web.xml* the tag <login-config> is uncommented. This configuration is completely ignored if set. The tag <realm-name> seems to have no effect either. I can write in this field what I want it changes nothing. So I did some more research and figured that the actual correct settings should be set like this:
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server gegenüber authentifiziert. -->
> <auth-method>CLIENT-CERT</auth-method>
> <!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS SHOULD ACCOMPLISH -->
> </login-config>
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>secured-app-domain</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw"/>
> </ssl>
> </server-identities>
> </security-realm>
> ...
> <security-domain name="trust-domain">
> <jsse truststore-password="pw" truststore-url="file:${jboss.server.config.dir}/gfi.jks" client-auth="true"/>
> </security-domain>
> <security-domain name="secured-app-domain">
> <authentication>
> <login-module code="Certificate" flag="required">
> <module-option name="securityDomain" value="trust-domain"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> {code}
> This configuration should work based on this article [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...] but the configuration is completely ignored and I have access to my application without any certificates imported to my browser. Can anyone explain this behaviour it just does not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-6999:
--------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> client authentication not behaving correctly?
> ---------------------------------------------
>
> Key: WFLY-6999
> URL: https://issues.jboss.org/browse/WFLY-6999
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final
> Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
> Reporter: Pascal Knüppel
> Assignee: Darran Lofthouse
>
> I am currently reading the wildfly 9 documentation and I started to test some things and I began with client certificate authentication since I am going to need this feature in short future.
> I found a way to realize mutual authentication but this one is rather a workaround than anything else.
> For starters it is my intention to deploy a web application on an https-port that requires client authentication. Additionally I want other applications under the same port that do not require client authentication. This is a feature that does not seem to be possible eventhough the documentation uses references to the security-domain section here.
> Now I will provide my configuration how I configured my application and my wildfly server to activate client cert authentication. Note that I had to configure a second virtual host with a new port to accomplish this.
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <!--<login-config>-->
> <!--<auth-method>CLIENT-CERT</auth-method>-->
> <!--<!–<realm-name>secured-app-domain</realm-name>–>-->
> <!--</login-config>-->
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <server-instance>client-auth-server</server-instance>
> <virtual-host>client-auth-host</virtual-host>
> <!--<security-domain>secured-app-domain</security-domain>-->
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="gfi"/>
> </authentication>
> </security-realm>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="client-auth-server">
> <https-listener name="secured-https" socket-binding="client-auth-https" security-realm="SSLRealm" verify-client="REQUIRED"/>
> <host name="client-auth-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> <socket-binding name="client-auth-https" port="${jboss.https.port:8444}"/>
> {code}
> This is everything needed for client-authentication if roles are not necessary. In case of using roles I had to add the uncommented security-domain not listed in the above code.
> Now to the point:
> this configuration seems undesirable to me and I am not sure if this is really wanted like this... as you can see in *web.xml* the tag <login-config> is uncommented. This configuration is completely ignored if set. The tag <realm-name> seems to have no effect either. I can write in this field what I want it changes nothing. So I did some more research and figured that the actual correct settings should be set like this:
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server gegenüber authentifiziert. -->
> <auth-method>CLIENT-CERT</auth-method>
> <!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS SHOULD ACCOMPLISH -->
> </login-config>
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>secured-app-domain</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw"/>
> </ssl>
> </server-identities>
> </security-realm>
> ...
> <security-domain name="trust-domain">
> <jsse truststore-password="pw" truststore-url="file:${jboss.server.config.dir}/gfi.jks" client-auth="true"/>
> </security-domain>
> <security-domain name="secured-app-domain">
> <authentication>
> <login-module code="Certificate" flag="required">
> <module-option name="securityDomain" value="trust-domain"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> {code}
> This configuration should work based on this article [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...] but the configuration is completely ignored and I have access to my application without any certificates imported to my browser. Can anyone explain this behaviour it just does not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on JBJCA-1329:
----------------------------------------
I see and do understand. Thanks for clarification. My original reason for this being filled as bug was there is no information in log that work was cancelled/forgotten.
Would you think it would be reasonable to put {{cancel()}} log information to higher level (e.g. WARN) than the trace is?
I have there still a small doubt of correct processing as the exception which is attached to {{WorkEvent}} that {{WorkListener}} receives should have an error code. This is not fully true now. The received exception looks this way
{code}
e = WorkCompletedException [id=542]
- cause = WorkCompletedException [id=632]
- cause = WorkCompletedException [id=632]
- detailMessage = ARJUNA016068: Work already active! (id=653)
- errorCode = "2" (id=654)
- linkedException = null
- stackTrace = []
- suppressedExceptions = []
- detailMessage = ARJUNA016068: Work already active!, error code: 2 (id=633)
- errorCode = null
- linkedException = null
- stackTrace = []
- suppressedExceptions = []
{code}
And my last question is once again related to jca specification. In requirements of _Transaction inflow_ (15.4.4) is said that
{quote}
The application server must disallow Work submissions with aWorkCompletedException set to the error codeWorkException.TX_CONCURRENT_WORK_DISALLOWED, if there is already a Workinstance associated with the transaction, irrespective of which resource adapter isinvolved in the Work submission.
{quote}
I do understand that the work has to be refused during submission. Currently the work is accepted for processing ({{WorkManager.scheduleWork}}) and is canceled later on. Do I understand the specification wrong at this place?
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1259) Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1259?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1259.
-------------------------------
Resolution: Out of Date
> Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1259
> URL: https://issues.jboss.org/browse/DROOLS-1259
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Local
> Reporter: Kavi sri
> Assignee: Mario Fusco
> Labels: later
>
> I'm trying to implement Kie Scanner in my Maven based REST API which invokes Drools Rule engine. Kie scanner works fine when Aggregate functions are not used in the DRL file. But it is not invoking the Rules, when collect / accumulate function is involved in the DRL.
> I had configured Kie scanner in my applicationContext. That is referred from the forum link shared in the Forum reference tab.
> Please let me know if there is a similar issue already reported or If it is new Please reply back with your comments
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1259) Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1259?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1259:
-------------------------------------
I have never heard of this problem regarding the workbench. However my understanding is that the KieScanner is now working as expected, so I'm about to close this ticket. If you think you've found a workbench issue please open another jira describing your issue and possibly providing a reproducer.
> Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1259
> URL: https://issues.jboss.org/browse/DROOLS-1259
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Local
> Reporter: Kavi sri
> Assignee: Mario Fusco
> Labels: later
>
> I'm trying to implement Kie Scanner in my Maven based REST API which invokes Drools Rule engine. Kie scanner works fine when Aggregate functions are not used in the DRL file. But it is not invoking the Rules, when collect / accumulate function is involved in the DRL.
> I had configured Kie scanner in my applicationContext. That is referred from the forum link shared in the Forum reference tab.
> Please let me know if there is a similar issue already reported or If it is new Please reply back with your comments
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1259) Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
by Kavi sri (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1259?page=com.atlassian.jira.plugi... ]
Kavi sri commented on DROOLS-1259:
----------------------------------
Hi Mario,
I had updated the Drools version to 6.4, Now Kie Scanner scans the updated Rule file with aggregate functions in local Maven repo. But now if i Update the Rule in workbench, local Maven repository is not getting updated with the new Rule files.I had tested the same with Local Workbench. Local Workbench is able to update the changes to Local Maven repository, but not the Dev Environment Workbench Maven. Please let me know if there is already a issue on it.
> Kie Scanner is not reading updated Rules when the rule file has aggregate functions like collect, accumulate
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1259
> URL: https://issues.jboss.org/browse/DROOLS-1259
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Local
> Reporter: Kavi sri
> Assignee: Mario Fusco
> Labels: later
>
> I'm trying to implement Kie Scanner in my Maven based REST API which invokes Drools Rule engine. Kie scanner works fine when Aggregate functions are not used in the DRL file. But it is not invoking the Rules, when collect / accumulate function is involved in the DRL.
> I had configured Kie scanner in my applicationContext. That is referred from the forum link shared in the Forum reference tab.
> Please let me know if there is a similar issue already reported or If it is new Please reply back with your comments
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-306:
-----------------------------------------
No plans in the short term.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-306:
------------------------------------
Fix Version/s: (was: 3.0.0.Alpha6)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri edited comment on JBJCA-1329 at 8/25/16 5:24 AM:
-----------------------------------------------------------------
I believe it is not a bug and it's up to the listener to manage the error condition.
As you can see from the log the WorkCompleted event has the right WorkCompletedException. Looking in 10.3.3.3 and 10.3.3.5 it's correct to have a WorkCompleted event since WorkCompletedException can be set only on this event, while WorkRejected could have only WorkRejectedException.
So the portion of spec you are quoting (it's in 15.4.4) is asking to set a proper WorkCOmpletedExcption, that is in fact how the application server is rejecting Work submission.
was (Author: maeste):
I believe is not a bug and it's up to the listener to manage the error condition.
As you can see from the log the WorkCompleted event has the right WorkCompletedException. Looking in 10.3.3.3 and 10.3.3.5 it's correct to have a WorkCompleted event since WorkCompletedException can be set only on this event, while WorkRejected could have only WorkRejectedException.
So the portion of spec you are quoting (it's in 15.4.4) is asking to set a proper WorkCOmpletedExcption, that is in fact how the application server is rejecting Work submission.
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1329:
----------------------------------------
I believe is not a bug and it's up to the listener to manage the error condition.
As you can see from the log the WorkCompleted event has the right WorkCompletedException. Looking in 10.3.3.3 and 10.3.3.5 it's correct to have a WorkCompleted event since WorkCompletedException can be set only on this event, while WorkRejected could have only WorkRejectedException.
So the portion of spec you are quoting (it's in 15.4.4) is asking to set a proper WorkCOmpletedExcption, that is in fact how the application server is rejecting Work submission.
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months