[Red Hat JIRA] (SWSQE-1248) Kiali soak test
by Filip Brychta (Jira)
[ https://issues.redhat.com/browse/SWSQE-1248?page=com.atlassian.jira.plugi... ]
Filip Brychta commented on SWSQE-1248:
--------------------------------------
Elasticsearch pod was evicted because of message: 'Pod The node had condition: [DiskPressure]. '
I re-created SM with following SMCP CR (it should only keep 2 days now):
{code:java}
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
namespace: istio-system
name: basic
spec:
tracing:
sampling: 10000
type: Jaeger
policy:
type: Istiod
runtime:
components:
tracing.jaeger.elasticsearch:
container:
resources:
limits:
cpu: '2'
memory: 4Gi
requests:
cpu: 500m
memory: 512Mi
addons:
grafana:
enabled: true
jaeger:
install:
ingress:
enabled: true
storage:
elasticsearch:
nodeCount: 2
indexCleaner:
enabled: true
numberOfDays: 2
type: Elasticsearch
kiali:
enabled: true
prometheus:
enabled: true
version: v2.0
telemetry:
type: Istiod
{code}
> Kiali soak test
> ---------------
>
> Key: SWSQE-1248
> URL: https://issues.redhat.com/browse/SWSQE-1248
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> We need some long running instance of SM
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5924) String vs Number Coercion behavior difference between standard-drl and exec-model
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5924:
-----------------------------------------
Summary: String vs Number Coercion behavior difference between standard-drl and exec-model
Key: DROOLS-5924
URL: https://issues.redhat.com/browse/DROOLS-5924
Project: Drools
Issue Type: Bug
Components: core engine, executable model
Affects Versions: 7.47.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use a Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
$map : Map()
p : Cheese(type < $map.get("key"))
{noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5924) String vs Number Coercion behavior difference between standard-drl and exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5924?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5924:
-------------------------------------------
This issue relates to DROOLS-5910 because range index has the same issue.
> String vs Number Coercion behavior difference between standard-drl and exec-model
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-5924
> URL: https://issues.redhat.com/browse/DROOLS-5924
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.47.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
> Note that we need to use a Map to test this because simple comparison String vs Number causes a compilation error.
> for example)
> {noformat}
> $map : Map()
> p : Cheese(type < $map.get("key"))
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-11986) HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-11986?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski edited comment on WFLY-11986 at 1/4/21 3:45 AM:
-------------------------------------------------------------------
[~stephen.fikes] Sorry, missed notification. Right of the bat, when you create DS, you can change the DB name. I did that and in my case I got exception.
URL was: jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=*TESTDB* but exception: aused by: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot open database "*MyDatabase*" requested by the login.
Created new DB *MyDatabase* in SQL server and it worked.
was (Author: baranowb):
[~stephen.fikes] Sorry, missed notification. Right of the bat, when you create DS, you can change the DB name. I did that and in my case I got exception.
URL was: jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=*TESTDB* but exception: aused by: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot open database "*MyDatabase*" requested by the login.
When I created *MyDatabase* in SQL server, it worked.
> HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11986
> URL: https://issues.redhat.com/browse/WFLY-11986
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 16.0.0.Final
> Environment: Windows 10 Pro RU, MSSQL Server 2008 on remote machine, Microsoft JDBC driver. mssql-jdbc-6.2.2.jre7
> Reporter: Dmitry Lazarev
> Assignee: Bartosz Baranowski
> Priority: Major
>
> When Datasource for MSSQL is created through HAL Management console, it inserts tag <datasource-class>com.microsoft.sqlserver.jdbc.SQLServerDataSource</datasource-class> in <datasource> element in standalone.xml.
> Then when I try to test connection it fails with error "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid" If i remove element <datasource-class> manualy from standalone.xml, Test Connection works properly.
> {code:java}
> 2019-04-12 17:01:15,500 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (External Management Request Threads – 2) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031084: Unable to create connection
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:345)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1325)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:499)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:1067)
> at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:93)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:240)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:97)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$489/1626912192.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$491/1133081806.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler$$Lambda$541/1958155244.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$542/1328593333.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Не удалось установить соединение TCP/IP к серверу localhost по порту 1433. Ошибка: "Connection refused: no further information. Проверьте свойства соединения. Убедитесь, что на сервере запущен экземпляр SQL Server и он принимает TCP/IP-соединения по порту. Убедитесь, что TCP-соединения по этому порту не блокируются брандмауэром.".
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:227)
> at com.microsoft.sqlserver.jdbc.SQLServerException.ConvertConnectExceptionToSQLServerException(SQLServerException.java:284)
> at com.microsoft.sqlserver.jdbc.SocketFinder.findSocket(IOBuffer.java:2435)
> at com.microsoft.sqlserver.jdbc.TDSChannel.open(IOBuffer.java:635)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2010)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnectionInternal(SQLServerDataSource.java:968)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnection(SQLServerDataSource.java:78)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:314)
> ... 39 more {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14241) The messageID cannot be used in a filter expressing via JBoss CLI
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14241?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-14241:
------------------------------------------
Quoting [~jbertram]
{code:java}
Filters work on message properties and some selected attributes (e.g. AMQDurable, AMQPriority, etc.). See the documentation for more details on this. The message ID you're inspecting is not filterable. It's really meant for internal use and only displayed for informational or debugging purposes here.{code}
> The messageID cannot be used in a filter expressing via JBoss CLI
> -----------------------------------------------------------------
>
> Key: WFLY-14241
> URL: https://issues.redhat.com/browse/WFLY-14241
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 22.0.0.Beta1
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The messageID header property holds a java.lang.Long value, however, it is not possible to use filter operators on the messageID header property.
> For example, the following expression would not work besides messageID in each message was greater than '0'.
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=A:count-messages(filter="messageID>0")
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14241) The messageID cannot be used in a filter expressing via JBoss CLI
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14241?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-14241:
-------------------------------------
Summary: The messageID cannot be used in a filter expressing via JBoss CLI (was: [GSS](7.3.z) The messageID cannot be used in a filter expressing via JBoss CLI)
> The messageID cannot be used in a filter expressing via JBoss CLI
> -----------------------------------------------------------------
>
> Key: WFLY-14241
> URL: https://issues.redhat.com/browse/WFLY-14241
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 22.0.0.Beta1
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The messageID header property holds a java.lang.Long value, however, it is not possible to use filter operators on the messageID header property.
> For example, the following expression would not work besides messageID in each message was greater than '0'.
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=A:count-messages(filter="messageID>0")
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-11986) HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-11986?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski commented on WFLY-11986:
-------------------------------------------
[~stephen.fikes] Sorry, missed notification. Right of the bat, when you create DS, you can change the DB name. I did that and in my case I got exception.
URL was: jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=*TESTDB* but exception: aused by: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot open database "*MyDatabase*" requested by the login.
When I created *MyDatabase* in SQL server, it worked.
> HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11986
> URL: https://issues.redhat.com/browse/WFLY-11986
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 16.0.0.Final
> Environment: Windows 10 Pro RU, MSSQL Server 2008 on remote machine, Microsoft JDBC driver. mssql-jdbc-6.2.2.jre7
> Reporter: Dmitry Lazarev
> Assignee: Bartosz Baranowski
> Priority: Major
>
> When Datasource for MSSQL is created through HAL Management console, it inserts tag <datasource-class>com.microsoft.sqlserver.jdbc.SQLServerDataSource</datasource-class> in <datasource> element in standalone.xml.
> Then when I try to test connection it fails with error "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid" If i remove element <datasource-class> manualy from standalone.xml, Test Connection works properly.
> {code:java}
> 2019-04-12 17:01:15,500 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (External Management Request Threads – 2) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031084: Unable to create connection
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:345)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1325)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:499)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:1067)
> at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:93)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:240)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:97)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$489/1626912192.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$491/1133081806.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler$$Lambda$541/1958155244.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$542/1328593333.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Не удалось установить соединение TCP/IP к серверу localhost по порту 1433. Ошибка: "Connection refused: no further information. Проверьте свойства соединения. Убедитесь, что на сервере запущен экземпляр SQL Server и он принимает TCP/IP-соединения по порту. Убедитесь, что TCP-соединения по этому порту не блокируются брандмауэром.".
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:227)
> at com.microsoft.sqlserver.jdbc.SQLServerException.ConvertConnectExceptionToSQLServerException(SQLServerException.java:284)
> at com.microsoft.sqlserver.jdbc.SocketFinder.findSocket(IOBuffer.java:2435)
> at com.microsoft.sqlserver.jdbc.TDSChannel.open(IOBuffer.java:635)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2010)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnectionInternal(SQLServerDataSource.java:968)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnection(SQLServerDataSource.java:78)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:314)
> ... 39 more {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-11365) Test JSONBTestCase fails with security manager
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-11365?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski commented on WFLY-11365:
-------------------------------------------
This can be closed as PR from James cover this and other JIRAs concerning tests.
> Test JSONBTestCase fails with security manager
> ----------------------------------------------
>
> Key: WFLY-11365
> URL: https://issues.redhat.com/browse/WFLY-11365
> Project: WildFly
> Issue Type: Bug
> Components: EE, Test Suite
> Affects Versions: 15.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: security-manager
> Attachments: sm-fix.patch
>
>
> {noformat}
> org.jboss.as.test.integration.json (1)
> JSONBTestCase.testJsonbServlet
> {noformat}
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/eclipse/yasson/1.0.2/yasson-1.0.2.jar" "read")" in code source "(vfs:/content/jsonb10-test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jsonb10-test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:359)
> at java.util.zip.ZipFile.<init>(ZipFile.java:216)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:112)
> at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108)
> at org.jboss.as.test.integration.json.JSONBServlet.doGet(JSONBServlet.java:46) ...
> {noformat}
> Looks to me similar to WFLY-11337
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months