[JBoss JIRA] (DROOLS-2978) Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2978?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2978:
--------------------------------
Description:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules (x)
-- check rule can extend rule (x)
-- check dtable can extend rule (x)
-- No error in server log (/)
-- Convert to gdst (/)
was:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules
-- check rule can extend rule
-- check dtable can extend rule
-- No error in server log
-- Convert to gdst (/)
- Upload invalid XLSX
> Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
> ----------------------------------------------------------------------------
>
> Key: DROOLS-2978
> URL: https://issues.jboss.org/browse/DROOLS-2978
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.7.0.Final
> Environment: Red Hat Decision Manager 7.0.0
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools, support
> Attachments: repo.zip, rule-selection-in-EXPECTATION.png
>
>
> In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
> h2. Acceptance test
> - Upload valid XLSX
> -- Check scenarios see rules (x)
> -- check rule can extend rule (x)
> -- check dtable can extend rule (x)
> -- No error in server log (/)
> -- Convert to gdst (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2978) Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2978?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2978:
--------------------------------
Description:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules
-- check rule can extend rule
-- check dtable can extend rule
-- No error in server log
-- Convert to gdst (/)
- Upload invalid XLSX
was:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules
-- check rule can extend rule
-- check dtable can extend rule
-- No error in server log
-- Convert to gdst
- Upload invalid XLSX
> Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
> ----------------------------------------------------------------------------
>
> Key: DROOLS-2978
> URL: https://issues.jboss.org/browse/DROOLS-2978
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.7.0.Final
> Environment: Red Hat Decision Manager 7.0.0
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools, support
> Attachments: repo.zip, rule-selection-in-EXPECTATION.png
>
>
> In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
> h2. Acceptance test
> - Upload valid XLSX
> -- Check scenarios see rules
> -- check rule can extend rule
> -- check dtable can extend rule
> -- No error in server log
> -- Convert to gdst (/)
> - Upload invalid XLSX
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2978) Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2978?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2978:
--------------------------------
Description:
In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
h2. Acceptance test
- Upload valid XLSX
-- Check scenarios see rules
-- check rule can extend rule
-- check dtable can extend rule
-- No error in server log
-- Convert to gdst
- Upload invalid XLSX
was:In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
> Test Scenario: unable to select rule defined in xlsx in EXPECTATION settings
> ----------------------------------------------------------------------------
>
> Key: DROOLS-2978
> URL: https://issues.jboss.org/browse/DROOLS-2978
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.7.0.Final
> Environment: Red Hat Decision Manager 7.0.0
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools, support
> Attachments: repo.zip, rule-selection-in-EXPECTATION.png
>
>
> In Test Scenario editor, when setting EXPECTATION, rule which is defined in XLSX is not listed in selection list of rule like an attached image.
> h2. Acceptance test
> - Upload valid XLSX
> -- Check scenarios see rules
> -- check rule can extend rule
> -- check dtable can extend rule
> -- No error in server log
> -- Convert to gdst
> - Upload invalid XLSX
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10879) Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10879?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-10879:
-----------------------------------------
Assignee: Bartosz Spyrko-Śmietanko (was: Jason Greene)
> Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10879
> URL: https://issues.jboss.org/browse/WFLY-10879
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Bartosz Spyrko-Śmietanko
> Attachments: server.log
>
>
> According to the spec (see below excerpt of ejb3.2 specification) the application should not avaialble if a Singleton initialization has failed.
> The current behaviour with two ejb.jar's in one ear, or other combinations is
> that the failure is logged, the deployment seems removed (there is a APP.ear.failed marker file) but another EJB of a second jar inside the ear is accesible, also web applications war deployemts are started.
> from the Spec 3.2
> 4.8.1 Singleton Session Bean Initialization
> By default, the container is responsible for deciding when to initialize a singleton session bean instance.
> However, the Bean Provider can optionally configure the singleton session bean for eager initialization.
> If the Startup annotation appears on the singleton session bean class or if the singleton session bean
> has been designated via the deployment descriptor as requiring eager initialization, the container must
> initialize the singleton session bean instance during the application startup sequence.
> ***** The container must initialize all such startup-time singleton session beans before any external client requests (that is,
> client requests originating outside of the application) are delivered to any enterprise bean components in
> the application. ******
> 4.8.4 Singleton SB error handling
> Errors occurring during singleton session bean initialization are considered fatal and must result in the
> discarding of the singleton session bean instance. ...
> If a singleton session bean fails to initialize, attempted invocations on the singleton session bean result in the
> javax.ejb.NoSuchEJBException exception as defined by Section 3.4.3 and Section 3.4.4 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10996) [Postgres] Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
[ https://issues.jboss.org/browse/WFLY-10996?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri updated WFLY-10996:
---------------------------------------
Summary: [Postgres] Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager (was: Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager)
> [Postgres] Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10996
> URL: https://issues.jboss.org/browse/WFLY-10996
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Environment: CentOS 7/Mac OS
> WildFly 14.0.0 / WildFly 14.0.1
> Reporter: Rakesh K. Cherukuri
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
>
>
> Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
> The changes are so minimal that it should basically work.
> Attached:
> # error.log - exception in the server log
> # jpa-war.tar.gz - maven module that can be used to reproduce the issue
> # pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
> # standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
> Note:
> - Tested same steps with wildfly 13 and there its woking fine.
> - Tested with latest postgres driver and issue exists with v14.0.0 (and v14.0.1). Postgres driver is thus ruled out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10996) Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
[ https://issues.jboss.org/browse/WFLY-10996?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-10996:
--------------------------------------------
also, the issue happens ONLY if you are using postgres.
> Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10996
> URL: https://issues.jboss.org/browse/WFLY-10996
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Environment: CentOS 7/Mac OS
> WildFly 14.0.0 / WildFly 14.0.1
> Reporter: Rakesh K. Cherukuri
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
>
>
> Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
> The changes are so minimal that it should basically work.
> Attached:
> # error.log - exception in the server log
> # jpa-war.tar.gz - maven module that can be used to reproduce the issue
> # pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
> # standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
> Note:
> - Tested same steps with wildfly 13 and there its woking fine.
> - Tested with latest postgres driver and issue exists with v14.0.0 (and v14.0.1). Postgres driver is thus ruled out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10996) Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
[ https://issues.jboss.org/browse/WFLY-10996?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-10996:
--------------------------------------------
[~smarlow] , adding dependency fixed the problem. Thanks.
Just to clarify, you can reproduce the issue with the downloaded zip files and also the maven repo wildfly-dist files. That would only mean that the release dist downloads (both from wildfly website and the maven repo) are not usable for any one who is using postgres.
I can only recommend to update the dist files to include the fix if thats possible.
> Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10996
> URL: https://issues.jboss.org/browse/WFLY-10996
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Environment: CentOS 7/Mac OS
> WildFly 14.0.0 / WildFly 14.0.1
> Reporter: Rakesh K. Cherukuri
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
>
>
> Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
> The changes are so minimal that it should basically work.
> Attached:
> # error.log - exception in the server log
> # jpa-war.tar.gz - maven module that can be used to reproduce the issue
> # pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
> # standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
> Note:
> - Tested same steps with wildfly 13 and there its woking fine.
> - Tested with latest postgres driver and issue exists with v14.0.0 (and v14.0.1). Postgres driver is thus ruled out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2592) PMML - tests in class ScorecardReasonCodeTest fail randomly
by Lance Leverich (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2592?page=com.atlassian.jira.plugi... ]
Lance Leverich commented on DROOLS-2592:
----------------------------------------
Uploaded new output.zip file. This file contains a directory for each run in a series of 11 tests (using the test.sh that was uploaded earlier). Within each directory, there are...
* Generated drl and class files
* output.log - this is the actual output that was generated during each maven build
Of the 11 tests, two failed. The output.log files for the failing tests are in the generated04 and generated08 directories.
NOTE: These tests were run after I had applied the proposed fix in [DROOLS-2060|https://github.com/kiegroup/drools/pull/2060]. The proposed fix may fix another issue, but it does not fix this one.
> PMML - tests in class ScorecardReasonCodeTest fail randomly
> -----------------------------------------------------------
>
> Key: DROOLS-2592
> URL: https://issues.jboss.org/browse/DROOLS-2592
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Lance Leverich
> Priority: Critical
> Labels: drools-core
> Attachments: output.zip, results_bad.zip, results_good.zip, test.sh
>
>
> When the ScorecardReasonCodeTest.testPointsBelow is run repeatedly, it sometimes fail with following assertion fail [1]. Setting this as critical, because the random fail causes build problems in the CI environment. Same applies for testPointsAbove, testReasonCodesCombination and probably others (I tested those 3 mentioned).
> [1] https://gist.github.com/baldimir/4c8ac4563fd17d13e4646fd60dd3a357
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JBEE-196) JSP and JSTL missing from EE 7 BOM
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/JBEE-196?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins resolved JBEE-196.
----------------------------------
Resolution: Done
JavaEE 8 Spec BOMs 1.0.1.Final is available on Maven and fixes this issue. JavaEE 7 Spec BOMs with this fix to be done
> JSP and JSTL missing from EE 7 BOM
> ----------------------------------
>
> Key: JBEE-196
> URL: https://issues.jboss.org/browse/JBEE-196
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Affects Versions: JavaEE 7 Spec APIs 1.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Eduardo Martins
>
> jboss-javaee-7.0 version 1.0.4 includes JSP and JSTL. Version 1.1.0 and later effectively do not, because they declare those dependencies to be provided scope for some reason. Servlet would also be affected, except JACC has a transitive dependency on it.
> This bug appears to have been introduced as part of resolving JBEE-170.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months