[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)
5 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)
5 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)
5 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)
5 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)
5 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)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5923) ResourceType does not work
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5923?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5923:
--------------------------------
Sprint: 2020 Week 52-03 (from Dec 21)
> ResourceType does not work
> --------------------------
>
> Key: DROOLS-5923
> URL: https://issues.redhat.com/browse/DROOLS-5923
> Project: Drools
> Issue Type: Bug
> Reporter: Ruffian Jiang
> Assignee: Mario Fusco
> Priority: Major
>
> I use drools as follow:
> {code:java}
> import org.kie.internal.utils.KieHelper;
> // code placeholder
> public static final ResourceType LOCAL_DRL = ResourceType.addResourceTypeToRegistry("DRL",
> "Drools Rule Language",
> "src/main/resources/com/jiang",
> "drl");
> public KieSession loadForRule2(String drlStr) {
> KieHelper helper = new KieHelper();
> helper.addContent(drlStr, LOCAL_DRL);
> return helper.build().newKieSession();
> }
> {code}
> This param *defaultPath* dose not work, I see that the code is fixed，
>
> {code:java}
> // code placeholder
> private String generateResourceName(ResourceType type) {
> return "src/main/resources/file" + counter++ + "." + type.getDefaultExtension();
> }
> {code}
> I think it should be changed as follows
> {code:java}
> // code placeholder
> private String generateResourceName(ResourceType type) {
> return type.getDefaultPath() + counter++ + "." + type.getDefaultExtension();
> }{code}
> Now，i use another function to temporarily solve
> {code:java}
> // code placeholder
> helper.addContent(drlStr, "/com/jiang/ww.drl");
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-12375) Server returns 2 JSESSIONID cookies
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-12375?page=com.atlassian.jira.plugi... ]
Parul Sharma closed WFLY-12375.
-------------------------------
Resolution: Cannot Reproduce
> Server returns 2 JSESSIONID cookies
> ------------------------------------
>
> Key: WFLY-12375
> URL: https://issues.redhat.com/browse/WFLY-12375
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 17.0.1.Final
> Reporter: Nicolas NESMON
> Assignee: Parul Sharma
> Priority: Major
> Labels: COOKIES, JSESSIONID
>
> Please find below the source code of my simplified JAX-RS application:
> {code:java}
> @ApplicationPath("myApp")
> public class Application extends javax.ws.rs.core.Application {
> public Application() {
> }
> @Override
> public Set<Object> getSingletons() {
> return Collections.singleton(new HelloWorldResource());
> }
> }
> {code}
> {code:java}
> @Path("/")
> @Produces(MediaType.TEXT_PLAIN)
> public class HelloWorldResource {
> @Context
> private HttpServletRequest httpServletRequest;
> @GET
> public Response helloWorld() {
> HttpSession session = this.httpServletRequest.getSession(false);
> return Response.ok(session == null ? "Hello world" : "Bye bye world")
> .cookie(new NewCookie("JSESSIONID", "id", "demo", null, null, -1, false)).build();
> }
> }
> {code}
> When deploying this application in WF 17.0.1.Final and running following request:
> {noformat}
> GET http://localhost:8080/demo/myApp/
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1
> Pragma: no-cache
> Cache-Control: no-cache
> Cookie: JSESSIONID=Hello => without this cookie, I only get the cookie I created.
> {noformat}
> I get following response
> {noformat}
> HTTP/1.1 200 OK
> Connection: keep-alive
> Set-Cookie: JSESSIONID=id;Version=1;Path=/demo
> Set-Cookie: JSESSIONID=hello.vpi070236; path=/demo
> Content-Type: text/plain;charset=UTF-8
> Content-Length: 11
> Date: Tue, 13 Aug 2019 23:28:15 GMT
> {noformat}
> As you may notice, there are 2 JSESSIONID cookies in the response:
> * The one I was expecting with "id" value since I created it.
> * Another one created by the server even if I did not ask for it since in my code I don't create no HTTP session. And by the way this JSESSIONID cookie is created but there no server side session created...weird
> Any idea why this second JSESSIONID cookies is created by the server ?
> Since my real application don't use HTTP session at all the workaround I found is to set session tracking mode to URL:
> {noformat}
> <web-app>
> <session-config>
> <tracking-mode>URL</tracking-mode>
> </session-config>
> </web-app>
> {noformat}
> Thanks
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months