[JBoss JIRA] (DROOLS-1534) Facing issue with Drools 6.3.0 version while updating to tomcat(Specific to Window platform)
by rajendra rathore (JIRA)
rajendra rathore created DROOLS-1534:
----------------------------------------
Summary: Facing issue with Drools 6.3.0 version while updating to tomcat(Specific to Window platform)
Key: DROOLS-1534
URL: https://issues.jboss.org/browse/DROOLS-1534
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: rajendra rathore
Assignee: Mario Fusco
Priority: Critical
Attachments: drools exception.txt
Hi Team,
we upgrade our tomcat as daily update process, previously we are using tomcat 8.5.5 and now updated to 8.5.13, we found that after updating tomcat to 8.5.13 our drools rule are not working and attached the exception for your reference.
We analyse the issue and found that *ecj.jar* is causing the issue, please let me know if there is any dependency with ECJ.jar, we are using 3.12.1.v20160829-0950 and it is bundled with tomcat 8.5.13.
Please let me know if you have any workaround for this issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1097) FIPS CS, specific error message if keyAlias does not exist.
by Martin Choma (JIRA)
Martin Choma created ELY-1097:
---------------------------------
Summary: FIPS CS, specific error message if keyAlias does not exist.
Key: ELY-1097
URL: https://issues.jboss.org/browse/ELY-1097
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
There is same error message if keyAlias does not exists and if exists but is of different type than SecretKey
_CredentialStoreException: ELY09512: External storage key under alias "key-alias" has to be a SecretKey_
When alias does not exist error message should be more specific, e.g:
{{CredentialStoreException: ELY0XXXX: External storage key under alias "key-alias" does not exists}}
{code}
09:48:44,127 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:119)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09512: External storage key under alias "key-alias" has to be a SecretKey
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.fetchStorageSecretKey(KeyStoreCredentialStore.java:1129)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.init(KeyStoreCredentialStore.java:1105)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:885)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:785)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:183)
at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:119)
at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:117)
... 5 more
09:48:44,130 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("credential-store" => "fips-credential-store")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09512: External storage key under alias \"key-alias\" has to be a SecretKey"}}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ]
Tomas Hofman edited comment on WFLY-8032 at 4/21/17 3:59 AM:
-------------------------------------------------------------
New PR merged: https://github.com/ironjacamar/ironjacamar/pull/623
Released in https://github.com/ironjacamar/ironjacamar/commits/ironjacamar-1.4.4.Final
was (Author: thofman):
New PR merged: https://github.com/ironjacamar/ironjacamar/pull/623
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8032
> URL: https://issues.jboss.org/browse/WFLY-8032
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-8032:
------------------------------------
New PR merged: https://github.com/ironjacamar/ironjacamar/pull/623
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8032
> URL: https://issues.jboss.org/browse/WFLY-8032
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman resolved JBJCA-1338.
---------------------------------
Resolution: Done
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
Amos Feng updated WFLY-8620:
----------------------------
Parent: WFLY-3854
Issue Type: Sub-task (was: Bug)
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Amos Feng
> Assignee: Amos Feng
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
Amos Feng created WFLY-8620:
-------------------------------
Summary: wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
Key: WFLY-8620
URL: https://issues.jboss.org/browse/WFLY-8620
Project: WildFly
Issue Type: Bug
Reporter: Amos Feng
Assignee: Amos Feng
{noformat}
Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:292)
at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
{noformat}
It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years