[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Artur Mioduszewski (JIRA)
[ https://issues.jboss.org/browse/JBCOMMON-131?page=com.atlassian.jira.plug... ]
Artur Mioduszewski edited comment on JBCOMMON-131 at 11/6/13 1:59 PM:
----------------------------------------------------------------------
Dimitris, why you cannot assign issue to proper project instead of closing it ? Rejecting an issue does not solve it ...
I don't know which exact project this issue is related to. Could you assign this issue to "JBoss Enterprise Application Platform" project (I have no such privilage) ?
was (Author: kliczko):
Dimitris, why you cannot assign issue to proper project instead of closing it ? Rejecting an issue does not solve it ...
I don't know which exact project this issue is related to. Could you assign this issue to proper JBoss project ?
> Setting cache timeout for JAAS under jboss-eap-6.1 does not work
> ----------------------------------------------------------------
>
> Key: JBCOMMON-131
> URL: https://issues.jboss.org/browse/JBCOMMON-131
> Project: JBoss Common
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: jboss-eap-6.1
> Reporter: Artur Mioduszewski
> Assignee: Dimitris Andreadis
>
> When: cache-type="default" in security-domain configuration -> authentication works correctly.
> When I have used below configuration in order to try to set cache timeout in JAAS -> JAAS authentication stops to work - I am not able to log in (on JBoss console there are not any errors)
> <code>
> ...
> <security-domain name="myJaasDomain" cache-type="infinispan">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
> <module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
> <module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="base64"/>
> <module-option name="unauthenticatedIdentity" value="guest"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
> <cache-container name="cluster" aliases="ha-partition" default-cache="default">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC" batching="true">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <transaction mode="NONE"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC">
> <transaction mode="NONE"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <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
11 years, 2 months
[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Artur Mioduszewski (JIRA)
[ https://issues.jboss.org/browse/JBCOMMON-131?page=com.atlassian.jira.plug... ]
Artur Mioduszewski edited comment on JBCOMMON-131 at 11/6/13 1:59 PM:
----------------------------------------------------------------------
Dimitris, why you cannot assign issue to proper project instead of closing it ? Rejecting an issue does not solve it ...
I don't know which exact project this issue is related to. Could you move this issue to "JBoss Enterprise Application Platform" project (I have no such privilage) ?
was (Author: kliczko):
Dimitris, why you cannot assign issue to proper project instead of closing it ? Rejecting an issue does not solve it ...
I don't know which exact project this issue is related to. Could you assign this issue to "JBoss Enterprise Application Platform" project (I have no such privilage) ?
> Setting cache timeout for JAAS under jboss-eap-6.1 does not work
> ----------------------------------------------------------------
>
> Key: JBCOMMON-131
> URL: https://issues.jboss.org/browse/JBCOMMON-131
> Project: JBoss Common
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: jboss-eap-6.1
> Reporter: Artur Mioduszewski
> Assignee: Dimitris Andreadis
>
> When: cache-type="default" in security-domain configuration -> authentication works correctly.
> When I have used below configuration in order to try to set cache timeout in JAAS -> JAAS authentication stops to work - I am not able to log in (on JBoss console there are not any errors)
> <code>
> ...
> <security-domain name="myJaasDomain" cache-type="infinispan">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
> <module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
> <module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="base64"/>
> <module-option name="unauthenticatedIdentity" value="guest"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
> <cache-container name="cluster" aliases="ha-partition" default-cache="default">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC" batching="true">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <transaction mode="NONE"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC">
> <transaction mode="NONE"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <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
11 years, 2 months
[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Artur Mioduszewski (JIRA)
[ https://issues.jboss.org/browse/JBCOMMON-131?page=com.atlassian.jira.plug... ]
Artur Mioduszewski reopened JBCOMMON-131:
-----------------------------------------
> Setting cache timeout for JAAS under jboss-eap-6.1 does not work
> ----------------------------------------------------------------
>
> Key: JBCOMMON-131
> URL: https://issues.jboss.org/browse/JBCOMMON-131
> Project: JBoss Common
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: jboss-eap-6.1
> Reporter: Artur Mioduszewski
> Assignee: Dimitris Andreadis
>
> When: cache-type="default" in security-domain configuration -> authentication works correctly.
> When I have used below configuration in order to try to set cache timeout in JAAS -> JAAS authentication stops to work - I am not able to log in (on JBoss console there are not any errors)
> <code>
> ...
> <security-domain name="myJaasDomain" cache-type="infinispan">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
> <module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
> <module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="base64"/>
> <module-option name="unauthenticatedIdentity" value="guest"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
> <cache-container name="cluster" aliases="ha-partition" default-cache="default">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC" batching="true">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <transaction mode="NONE"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC">
> <transaction mode="NONE"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <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
11 years, 2 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2426 at 11/6/13 1:51 PM:
-------------------------------------------------------------
Talked to Paul. EAP already has such file, version.txt, but FWIU it is not a documented/guaranteed format. Support reportedly relies on that (Jimmy).
See JBPAPP6-1044 .
Also, there is a file which is basically what we need,
see https://github.com/jbossas/jboss-eap/commit/b8f636d9a765fcfe67cf0a8e2ff28...
resp. https://github.com/jbossas/jboss-eap/blob/b8f636d9a765fcfe67cf0a8e2ff2804...
{code}
JBoss-Product-Release-Name: EAP
JBoss-Product-Release-Version: 6.2.0.GA
JBoss-Product-Console-Slot: eap
{code}
Besides the key names say product, this could be what we need. Just to move it to the root or bin/. Any other information needed? I was thinking about a field saying product/project, if useful.
was (Author: ozizka):
Talked to Paul. EAP already has such file, version.txt, but FWIU it is not a documented/guaranteed format. Support reportedly relies on that (Jimmy).
Also, there is a file which is basically what we need,
see https://github.com/jbossas/jboss-eap/commit/b8f636d9a765fcfe67cf0a8e2ff28...
resp. https://github.com/jbossas/jboss-eap/blob/b8f636d9a765fcfe67cf0a8e2ff2804...
{code}
JBoss-Product-Release-Name: EAP
JBoss-Product-Release-Version: 6.2.0.GA
JBoss-Product-Console-Slot: eap
{code}
Besides the key names say product, this could be what we need. Just to move it to the root or bin/. Any other information needed? I was thinking about a field saying product/project, if useful.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1728 at 11/6/13 1:21 PM:
--------------------------------------------------------------------
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
I've set up a PR and have this mechanism working. No extra jars or other mechanisms are required.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task from within runtest:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
was (Author: rachmato):
So, because JGroups uses suite files to control the testsuite, there is no easy way to turn parallelism on and off.
There was a mechanism in place which used the system properties listed in the first comment and passed those through to the runtest macro, but these had no effect on the suite definition files. We must somehow modify these files for parallel and non-parallel test execution modes.
One way would be to have a set of suite files for non-parallel mode, and another set of suite files for parallel mode. We could then use the parallel.tests and parallel.methods build properties to control which suite definition file (parallel or non-parallel) was picked up for test execution. But if you wanted to change say the thread-count of the functional tests, you would have to go into the file and change it.
Another way is to take the suite files in conf/testng and pre-process them before use, based on the parallel= and thread-count= attributes passed to runtest. This can be acheived by using a small XSLT transform which runs in a step just before the testNG task is invoked and configures the suite file on the fly.
When the runtest macro gets called, it takes the parallel= and thread-count= parameters passed to runtest and uses an XSLT transform called configParallel.xsl to change the corresponding attributes in the suite file. The transformed suite file is then stored in the temp.dir where the test results are also stored in named directories. This modified suite file is then used to control the test and will be cleaned up when the clean ant task is run.
Here is the xslt file, in conf/testng/parallelConfig.xsl:
{noformat}
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:param name="parallel" select="'methods'"/>
<xsl:param name="thread-count" select="'1'"/>
<!-- copy everything -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- change value of parallel attribute -->
<xsl:template match="@parallel[parent::suite]">
<xsl:attribute name="parallel">
<xsl:value-of select="$parallel"/>
</xsl:attribute>
</xsl:template>
<!-- change value of thread-count attribute -->
<xsl:template match="@thread-count[parent::suite]">
<xsl:attribute name="thread-count">
<xsl:value-of select="$thread-count"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
{noformat}
and here is the invocation of the xslt task from within runtest:
{noformat}
<!-- use XSLT to add parallelism directives to the suite definition files -->
<xslt in="${testng.conf.dir}/(a){testng.xmlfile}" out="${tmp.dir}/(a){testng.xmlfile}"
extension=".xml" style="${testng.conf.dir}/parallelConfig.xsl">
<param name="parallel" expression="@{parallel}"/>
<param name="thread-count" expression="@{threadcount}"/>
</xslt>
{noformat}
I've set up a PR and have this mechanism working. No extra jars or other mechanisms are required.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
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
11 years, 2 months