[JBoss JIRA] (DROOLS-5576) Unable to further edit scesim header cell when editing mode previously canceled with Esc
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5576?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5576:
--------------------------------
Sprint: 2020 Week 31-33 (from Jul 27)
> Unable to further edit scesim header cell when editing mode previously canceled with Esc
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-5576
> URL: https://issues.redhat.com/browse/DROOLS-5576
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.42.0.Final
> Reporter: Jan Stastny
> Assignee: Jozef Marko
> Priority: Major
>
> In Rule based Test Scenario an alias in Given/Expect facts for either instance or property can be introduced (i.e. in header cells) and override the default instance/property names.
> The header cell can be opened in editing mode by either double-clicking on it or arrow key navigation and pressing Enter.
> When the editing mode is opened the changes can be either confirmed (by pressing Enter or Tab) or canceled (by pressing Esc).
> When the editing mode is canceled using Esc, any consecutive attempt to edit that exact cell is not successful - the editing mode for the cell can't be opened neither by clicking nor pressing any keys.
> For others (not yet hit by the issue) the editing mode opens fine up to the moment described above.
> The issue is not present in ordinary cells (the lines for actual test scenario definitions below the header cells of the grid.)
> The only workaround is to close and open the editor anew.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5576) Unable to further edit scesim header cell when editing mode previously canceled with Esc
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5576?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5576:
--------------------------------
Tester: Jan Stastny
> Unable to further edit scesim header cell when editing mode previously canceled with Esc
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-5576
> URL: https://issues.redhat.com/browse/DROOLS-5576
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.42.0.Final
> Reporter: Jan Stastny
> Assignee: Jozef Marko
> Priority: Major
>
> In Rule based Test Scenario an alias in Given/Expect facts for either instance or property can be introduced (i.e. in header cells) and override the default instance/property names.
> The header cell can be opened in editing mode by either double-clicking on it or arrow key navigation and pressing Enter.
> When the editing mode is opened the changes can be either confirmed (by pressing Enter or Tab) or canceled (by pressing Esc).
> When the editing mode is canceled using Esc, any consecutive attempt to edit that exact cell is not successful - the editing mode for the cell can't be opened neither by clicking nor pressing any keys.
> For others (not yet hit by the issue) the editing mode opens fine up to the moment described above.
> The issue is not present in ordinary cells (the lines for actual test scenario definitions below the header cells of the grid.)
> The only workaround is to close and open the editor anew.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
Matěj Novotný updated WFLY-12815:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/13485
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Fix For: 21.0.0.Beta1
>
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
Matěj Novotný updated WFLY-12815:
---------------------------------
Fix Version/s: 21.0.0.Beta1
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Fix For: 21.0.0.Beta1
>
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-4367) Tests in drools coverage are not really using the executable model
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-4367?page=com.atlassian.jira.plug... ]
Daniel Rosa updated DROOLS-4367:
--------------------------------
Sprint: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6) (was: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27))
> Tests in drools coverage are not really using the executable model
> ------------------------------------------------------------------
>
> Key: DROOLS-4367
> URL: https://issues.redhat.com/browse/DROOLS-4367
> Project: Drools
> Issue Type: Bug
> Reporter: Luca Molteni
> Assignee: Daniel Rosa
> Priority: Minor
>
> Such as
> https://github.com/kiegroup/drools/blob/ba9c79c4bfaf9cfc1ec2363bee3865c3d...
> Even if the test itself is parametrized, in the body it calls directly buildAll therefore discarding the executable model
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-4367) Tests in drools coverage are not really using the executable model
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-4367?page=com.atlassian.jira.plug... ]
Daniel Rosa updated DROOLS-4367:
--------------------------------
Sprint: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 34-36 (from Aug 17) (was: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6))
> Tests in drools coverage are not really using the executable model
> ------------------------------------------------------------------
>
> Key: DROOLS-4367
> URL: https://issues.redhat.com/browse/DROOLS-4367
> Project: Drools
> Issue Type: Bug
> Reporter: Luca Molteni
> Assignee: Daniel Rosa
> Priority: Minor
>
> Such as
> https://github.com/kiegroup/drools/blob/ba9c79c4bfaf9cfc1ec2363bee3865c3d...
> Even if the test itself is parametrized, in the body it calls directly buildAll therefore discarding the executable model
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-7419) Include RESTEasy WADL module
by Alessio Soldano (Jira)
[ https://issues.redhat.com/browse/WFLY-7419?page=com.atlassian.jira.plugin... ]
Alessio Soldano commented on WFLY-7419:
---------------------------------------
[~weinanli], please go ahead in testing, documenting and maybe adding an example of using the resteasy-wadl module in a deployment as previously suggested by Frank. [~yogesh.vedpathak] , I assume that approach would we what you could propose the customer to use, would that be fine?
> Include RESTEasy WADL module
> ----------------------------
>
> Key: WFLY-7419
> URL: https://issues.redhat.com/browse/WFLY-7419
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
> Reporter: Frank Langelage
> Assignee: Weinan Li
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JBAS-5199) Exception in server.log during startup
by Amol Dongare (Jira)
[ https://issues.redhat.com/browse/JBAS-5199?page=com.atlassian.jira.plugin... ]
Amol Dongare updated JBAS-5199:
-------------------------------
Attachment: (was: server.log)
> Exception in server.log during startup
> --------------------------------------
>
> Key: JBAS-5199
> URL: https://issues.redhat.com/browse/JBAS-5199
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Affects Versions: JBossAS-5.0.0.Beta3
> Environment: windows xp; jboss 5.0.0Beta3
> Reporter: Scott Dickerson
> Priority: Major
>
> 2008-02-01 11:28:19,685 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Failed to update pkgs for cl=org.jboss.mx.loading.UnifiedClassLoader3@473fc2{ url=vfsfile:/C:/JavaTools/jboss-5.0.0.Beta3/server/test/deploy/http-invoker.sar/ ,addedOrder=20}
> java.io.FileNotFoundException: C:\JavaTools\jboss-5.0.0.Beta3\server\test\deploy\http-invoker.sar\invoker.war\WEB-INF\classes (Access is denied)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:106)
> at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:105)
> at java.net.URL.openStream(URL.java:1007)
> ....
> (see attached server.log)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months