[JBoss JIRA] (WFCORE-3989) AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3989?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-3989.
--------------------------------------
Fix Version/s: 6.0.0.Alpha5
Resolution: Duplicate Issue
> AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-3989
> URL: https://issues.jboss.org/browse/WFCORE-3989
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.0.Alpha4
> Environment: {noformat}
> Apache Maven 3.5.0 (Red Hat 3.5.0-6)
> Maven home: /usr/share/maven
> Java version: 1.8.0_172
> {noformat}
> Reporter: Vilém Obrátil
> Assignee: Vilém Obrátil
> Fix For: 6.0.0.Alpha5
>
>
> org.jboss.as.test.manualmode.auditlog.AuditLogBootingSyslogTest from deployment-scanner module of wildfly-core fails due to unexpected queue size length.
> The test method waitForExpectedQueueSize expects that there can only be one possible queue size (17), but in practice the queue can be longer, which occasionally causes the test to fail.
> Test javadoc snippet:
> {noformat}
> * The event to add the extensions fits into a single syslog event. The composite operation is chopped to fit into multiple
> * events, at the time of writing it is split across 17 events.
> *
> * Small differences between the expected count and actual count could be caused by configuration changes changing how many
> * events it takes to hold the entire composite operation.
> {noformat}
> The expected queue size was changed from 18 to 17 by https://github.com/wildfly/wildfly-core/pull/3379/files#diff-2308836c2a67...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (SWSQE-357) Collect test reports from all sub-jobs and merge it to one report
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-357?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-357.
---------------------------------
Resolution: Done
Using junit-merge tool and copyArtifacts plugin:
copyArtifacts(projectName: 'fbr-demo-python-ui-tests', parameters: 'TEST_SUITE_NAME=group16', selector: lastCompleted(), target: 'group16');
copyArtifacts(projectName: 'fbr-demo-python-ui-tests', parameters: 'TEST_SUITE_NAME=group17', selector: lastCompleted(), target: 'group17');
sh 'junit-merge -d . -r'
junit "merged-test-results.xml"
> Collect test reports from all sub-jobs and merge it to one report
> -----------------------------------------------------------------
>
> Key: SWSQE-357
> URL: https://issues.jboss.org/browse/SWSQE-357
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
>
> We are using separated slaves to start subset of tests so we have separated test results which need to be merged to one.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFCORE-3989) AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3989?page=com.atlassian.jira.plugi... ]
Petr Kremensky reopened WFCORE-3989:
------------------------------------
> AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-3989
> URL: https://issues.jboss.org/browse/WFCORE-3989
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.0.Alpha4
> Environment: {noformat}
> Apache Maven 3.5.0 (Red Hat 3.5.0-6)
> Maven home: /usr/share/maven
> Java version: 1.8.0_172
> {noformat}
> Reporter: Vilém Obrátil
> Assignee: Vilém Obrátil
>
> org.jboss.as.test.manualmode.auditlog.AuditLogBootingSyslogTest from deployment-scanner module of wildfly-core fails due to unexpected queue size length.
> The test method waitForExpectedQueueSize expects that there can only be one possible queue size (17), but in practice the queue can be longer, which occasionally causes the test to fail.
> Test javadoc snippet:
> {noformat}
> * The event to add the extensions fits into a single syslog event. The composite operation is chopped to fit into multiple
> * events, at the time of writing it is split across 17 events.
> *
> * Small differences between the expected count and actual count could be caused by configuration changes changing how many
> * events it takes to hold the entire composite operation.
> {noformat}
> The expected queue size was changed from 18 to 17 by https://github.com/wildfly/wildfly-core/pull/3379/files#diff-2308836c2a67...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBJCA-1380) XAManagedConnectionFactory screws up Datasource urls containing ;
by Chris Poulsen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1380?page=com.atlassian.jira.plugin... ]
Chris Poulsen updated JBJCA-1380:
---------------------------------
Description:
While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
"jdbc:h2:mem:unit-test;MODE=Oracle"
I was unable to deploy the datasource using:
<xa-datasource-property name="url">jdbc:h2:mem:unit-test;MODE=Oracle</xa-datasource-property>
Ironjacamar keeps complaining about:
Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
My initial thought was that <url-delimiter> was the cause, but no dice.
Following the trace into the sources, I guess the offending line is:
{code:java}
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
{code}
In XAManagedConnectionFactory around line: 174 (see following snippet)
{code:java}
public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
{
this.xaDataSourceProperties = xaDataSourceProperties;
xaProps.clear();
if (xaDataSourceProperties != null)
{
// Map any \ to \\
xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
// Map any ; to \n
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
try
{
Properties p = new Properties();
p.load(is);
for (Map.Entry<Object, Object> entry : p.entrySet())
{
xaProps.put((String)entry.getKey(), (String)entry.getValue());
}
}
{code}
was:
While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
"jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1"
I was unable to deploy the datasource using:
<xa-datasource-property name="url">jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1</xa-datasource-property>
Ironjacamar keeps complaining about:
Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
My initial thought was that <url-delimiter> was the cause, but no dice.
Following the trace into the sources, I guess the offending line is:
{code:java}
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
{code}
In XAManagedConnectionFactory around line: 174 (see following snippet)
{code:java}
public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
{
this.xaDataSourceProperties = xaDataSourceProperties;
xaProps.clear();
if (xaDataSourceProperties != null)
{
// Map any \ to \\
xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
// Map any ; to \n
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
try
{
Properties p = new Properties();
p.load(is);
for (Map.Entry<Object, Object> entry : p.entrySet())
{
xaProps.put((String)entry.getKey(), (String)entry.getValue());
}
}
{code}
> XAManagedConnectionFactory screws up Datasource urls containing ;
> -----------------------------------------------------------------
>
> Key: JBJCA-1380
> URL: https://issues.jboss.org/browse/JBJCA-1380
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Environment: Unit testing using an embedded ironjacamar
> Reporter: Chris Poulsen
> Attachments: XAManagedConnectionFactory-h2-error.txt
>
>
> While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
> H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
> "jdbc:h2:mem:unit-test;MODE=Oracle"
> I was unable to deploy the datasource using:
> <xa-datasource-property name="url">jdbc:h2:mem:unit-test;MODE=Oracle</xa-datasource-property>
> Ironjacamar keeps complaining about:
> Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
> My initial thought was that <url-delimiter> was the cause, but no dice.
> Following the trace into the sources, I guess the offending line is:
> {code:java}
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> {code}
> In XAManagedConnectionFactory around line: 174 (see following snippet)
> {code:java}
> public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
> {
> this.xaDataSourceProperties = xaDataSourceProperties;
> xaProps.clear();
> if (xaDataSourceProperties != null)
> {
> // Map any \ to \\
> xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
> // Map any ; to \n
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
> try
> {
> Properties p = new Properties();
> p.load(is);
> for (Map.Entry<Object, Object> entry : p.entrySet())
> {
> xaProps.put((String)entry.getKey(), (String)entry.getValue());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFCORE-3989) AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
by Vilém Obrátil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3989?page=com.atlassian.jira.plugi... ]
Vilém Obrátil resolved WFCORE-3989.
-----------------------------------
Resolution: Done
The method waitForExpectedQueueSize now has a lower and upper bound for queue size. Therefore the test now accepts more than one possible queue size.
> AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-3989
> URL: https://issues.jboss.org/browse/WFCORE-3989
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.0.Alpha4
> Environment: {noformat}
> Apache Maven 3.5.0 (Red Hat 3.5.0-6)
> Maven home: /usr/share/maven
> Java version: 1.8.0_172
> {noformat}
> Reporter: Vilém Obrátil
> Assignee: Vilém Obrátil
>
> org.jboss.as.test.manualmode.auditlog.AuditLogBootingSyslogTest from deployment-scanner module of wildfly-core fails due to unexpected queue size length.
> The test method waitForExpectedQueueSize expects that there can only be one possible queue size (17), but in practice the queue can be longer, which occasionally causes the test to fail.
> Test javadoc snippet:
> {noformat}
> * The event to add the extensions fits into a single syslog event. The composite operation is chopped to fit into multiple
> * events, at the time of writing it is split across 17 events.
> *
> * Small differences between the expected count and actual count could be caused by configuration changes changing how many
> * events it takes to hold the entire composite operation.
> {noformat}
> The expected queue size was changed from 18 to 17 by https://github.com/wildfly/wildfly-core/pull/3379/files#diff-2308836c2a67...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBJCA-1380) XAManagedConnectionFactory screws up Datasource urls containing ;
by Chris Poulsen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1380?page=com.atlassian.jira.plugin... ]
Chris Poulsen updated JBJCA-1380:
---------------------------------
Attachment: XAManagedConnectionFactory-h2-error.txt
> XAManagedConnectionFactory screws up Datasource urls containing ;
> -----------------------------------------------------------------
>
> Key: JBJCA-1380
> URL: https://issues.jboss.org/browse/JBJCA-1380
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Environment: Unit testing using an embedded ironjacamar
> Reporter: Chris Poulsen
> Attachments: XAManagedConnectionFactory-h2-error.txt
>
>
> While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
> H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
> "jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1"
> I was unable to deploy the datasource using:
> <xa-datasource-property name="url">jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1</xa-datasource-property>
> Ironjacamar keeps complaining about:
> Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
> My initial thought was that <url-delimiter> was the cause, but no dice.
> Following the trace into the sources, I guess the offending line is:
> {code:java}
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> {code}
> In XAManagedConnectionFactory around line: 174 (see following snippet)
> {code:java}
> public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
> {
> this.xaDataSourceProperties = xaDataSourceProperties;
> xaProps.clear();
> if (xaDataSourceProperties != null)
> {
> // Map any \ to \\
> xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
> // Map any ; to \n
> xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
> InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
> try
> {
> Properties p = new Properties();
> p.load(is);
> for (Map.Entry<Object, Object> entry : p.entrySet())
> {
> xaProps.put((String)entry.getKey(), (String)entry.getValue());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBJCA-1380) XAManagedConnectionFactory screws up Datasource urls containing ;
by Chris Poulsen (JIRA)
Chris Poulsen created JBJCA-1380:
------------------------------------
Summary: XAManagedConnectionFactory screws up Datasource urls containing ;
Key: JBJCA-1380
URL: https://issues.jboss.org/browse/JBJCA-1380
Project: IronJacamar
Issue Type: Bug
Components: JDBC
Affects Versions: 1.4.9
Environment: Unit testing using an embedded ironjacamar
Reporter: Chris Poulsen
While trying to adjust settings on the H2 data source we use for a corner of our system during testing, I ran into problems.
H2 accepts parameters appended to the url on the form ";<name>=<value>" for example:
"jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1"
I was unable to deploy the datasource using:
<xa-datasource-property name="url">jdbc:h2:mem:unit-test;DB_CLOSE_DELAY=-1</xa-datasource-property>
Ironjacamar keeps complaining about:
Caused by: java.lang.NoSuchMethodException: Method setMODE not found some setter not being found.
My initial thought was that <url-delimiter> was the cause, but no dice.
Following the trace into the sources, I guess the offending line is:
{code:java}
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
{code}
In XAManagedConnectionFactory around line: 174 (see following snippet)
{code:java}
public void setXADataSourceProperties(String xaDataSourceProperties) throws ResourceException
{
this.xaDataSourceProperties = xaDataSourceProperties;
xaProps.clear();
if (xaDataSourceProperties != null)
{
// Map any \ to \\
xaDataSourceProperties = xaDataSourceProperties.replaceAll("\\\\", "\\\\\\\\");
// Map any ; to \n
xaDataSourceProperties = xaDataSourceProperties.replace(';', '\n');
InputStream is = new ByteArrayInputStream(xaDataSourceProperties.getBytes());
try
{
Properties p = new Properties();
p.load(is);
for (Map.Entry<Object, Object> entry : p.entrySet())
{
xaProps.put((String)entry.getKey(), (String)entry.getValue());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFCORE-3949) Cannot use server-file audit logger handler in JMX audit logging
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3949?page=com.atlassian.jira.plugi... ]
Yeray Borges resolved WFCORE-3949.
----------------------------------
Resolution: Rejected
Changed the resolution to "rejected" because really it is not a bug. It is an invalid configuration, as per Brian's comments looks like it is not worth the effort of developing a better way to handle it.
> Cannot use server-file audit logger handler in JMX audit logging
> -----------------------------------------------------------------
>
> Key: WFCORE-3949
> URL: https://issues.jboss.org/browse/WFCORE-3949
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Reporter: Yeray Borges
> Assignee: Yeray Borges
>
> When we are working in domain mode, we can register two kinds of audit logger handlers into JMX audit logging.
> Those predefined handlers are {{host-file}} handler, which has a log file relative to {{jboss.domain.data.dir}}, and {{server-file}} handler, which has a log file relative to {{jboss.server.data.dir}}.
> When we try to register {{server-file}} handler into JMX audit logging, its relative path cannot be resolved and when a log entry is written, we can see the following error log:
> {code:java}
> ERROR [org.jboss.as.controller.management-operation] (MSC service thread 1-1) WFLYCTL0037: Update of the management operation audit log failed in handler 'server-file': java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called 'jboss.server.data.dir'
> [Host Controller] at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
> [Host Controller] at org.jboss.as.controller.audit.AbstractFileAuditLogHandler.initialize(AbstractFileAuditLogHandler.java:62)
> [Host Controller] at org.jboss.as.controller.audit.AuditLogHandler.writeLogItem(AuditLogHandler.java:82)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.writeLogItem(ManagedAuditLoggerImpl.java:266)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.storeLogItem(ManagedAuditLoggerImpl.java:248)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.logJmxMethodAccess(ManagedAuditLoggerImpl.java:122)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1281)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1184)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.registerMBean(MBeanServerAuditLogRecordFormatter.java:147)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:880)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:385)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:379)
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.<init>(EnhancedQueueExecutor.java:379)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$Builder.build(EnhancedQueueExecutor.java:671)
> [Host Controller] at org.jboss.as.controller.remote.AbstractModelControllerOperationHandlerFactoryService.start(AbstractModelControllerOperationHandlerFactoryService.java:112)
> [Host Controller] at org.jboss.as.host.controller.mgmt.MasterDomainControllerOperationHandlerService.start(MasterDomainControllerOperationHandlerService.java:90)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [Host Controller] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> {code}
> Registering a {{host-file}} does not throw any errors and work as expected. Althought there is a capability reference to jboss.server.data.dir in HostPathManagerService, when the handler is registered for JMX, jboss.server.data.dir cannot be resolved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFCORE-3989) AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
by Vilém Obrátil (JIRA)
Vilém Obrátil created WFCORE-3989:
-------------------------------------
Summary: AuditLogBootingSyslogTest should make assertion on lower and upper bound for queue size
Key: WFCORE-3989
URL: https://issues.jboss.org/browse/WFCORE-3989
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 6.0.0.Alpha4
Environment: {noformat}
Apache Maven 3.5.0 (Red Hat 3.5.0-6)
Maven home: /usr/share/maven
Java version: 1.8.0_172
{noformat}
Reporter: Vilém Obrátil
Assignee: Vilém Obrátil
org.jboss.as.test.manualmode.auditlog.AuditLogBootingSyslogTest from deployment-scanner module of wildfly-core fails due to unexpected queue size length.
The test method waitForExpectedQueueSize expects that there can only be one possible queue size (17), but in practice the queue can be longer, which occasionally causes the test to fail.
Test javadoc snippet:
{noformat}
* The event to add the extensions fits into a single syslog event. The composite operation is chopped to fit into multiple
* events, at the time of writing it is split across 17 events.
*
* Small differences between the expected count and actual count could be caused by configuration changes changing how many
* events it takes to hold the entire composite operation.
{noformat}
The expected queue size was changed from 18 to 17 by https://github.com/wildfly/wildfly-core/pull/3379/files#diff-2308836c2a67...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months