December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11567) Provide way to retrieve VirtualFile instance from url.openConnection()

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11567?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-11567: ---------------------------------- Fix Version/s: 19.0.0.Beta1 > Provide way to retrieve VirtualFile instance from url.openConnection() > ---------------------------------------------------------------------- > > Key: WFLY-11567 > URL: https://issues.jboss.org/browse/WFLY-11567 > Project: WildFly > Issue Type: Enhancement > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Major > Fix For: 19.0.0.Beta1 > > > It is not possible to obtain VirtualFile (and by extensions it's physicalFile) instance wrapped in VirtualFileURLConnection without using reflection. > Code snippet from Drools [1], where they try to get hold of {{VirtualFile#getPhysicalFile()}}: > {code} > private static Object findVirtualFile( URL url ) throws IOException { > URLConnection urlConnection = url.openConnection(); > try { > if ( urlConnection.getClass().getName().equals( "org.jboss.vfs.protocol.VirtualFileURLConnection" ) ) { > Field f = urlConnection.getClass().getDeclaredField( "file" ); > f.setAccessible( true ); > return f.get( urlConnection ); > } > } catch (NoSuchFieldException | IllegalAccessException e) { > // ignored > } > return urlConnection.getContent(); > } > {code} > [1] https://github.com/kiegroup/drools/commit/2a36f67a29ed06d0f980a60ff1c81fa... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-1020) Config UI Delete - Verify is deleted

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1020: ------------------------------------- Summary: Config UI Delete - Verify is deleted Key: SWSQE-1020 URL: https://issues.jboss.org/browse/SWSQE-1020 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-1016) Review PR jobs settings regarding checking branch or merge commit

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-1016?page=com.atlassian.jira.plugin... ] Filip Brychta updated SWSQE-1016: --------------------------------- Sprint: Kiali Sprint #30 > Review PR jobs settings regarding checking branch or merge commit > ----------------------------------------------------------------- > > Key: SWSQE-1016 > URL: https://issues.jboss.org/browse/SWSQE-1016 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > PR jobs are now checking git checkout ${CORE_PR} but we should be probably checking origin/pr/${CORE_PR}/merge -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4367) Tests in drools coverage are not really using the executable model

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4367?page=com.atlassian.jira.plugi... ] Tibor Zimanyi updated DROOLS-4367: ---------------------------------- Story Points: 5 Sprint: 2019 Week 47-49 (from Nov 18) > Tests in drools coverage are not really using the executable model > ------------------------------------------------------------------ > > Key: DROOLS-4367 > URL: https://issues.jboss.org/browse/DROOLS-4367 > Project: Drools > Issue Type: Bug > Reporter: Luca Molteni > Assignee: Tibor Zimanyi > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-12659) Creation of a GUI for multi-version test distribution across different Multi-version Testsuites (EAT, etc)

by Panagiotis Sotiropoulos (Jira)

[ https://issues.jboss.org/browse/WFLY-12659?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos commented on WFLY-12659: ------------------------------------------------ Repo : https://github.com/panossot/GoAT To be continued (Not done yet) ... > Creation of a GUI for multi-version test distribution across different Multi-version Testsuites (EAT,etc) > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-12659 > URL: https://issues.jboss.org/browse/WFLY-12659 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Creation of a GUI for multi-version test distribution across different Multi-version Testsuites (EAT,etc) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12836) Large allocations in EJBContextImpl#isCallerInRole

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12836?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-12836: ------------------------------------ Component/s: Security > Large allocations in EJBContextImpl#isCallerInRole > -------------------------------------------------- > > Key: WFLY-12836 > URL: https://issues.jboss.org/browse/WFLY-12836 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.1.Final > Reporter: Philippe Marschall > Assignee: Cheng Fang > Priority: Major > Attachments: elytron_allocations_redacted.PNG > > > In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet|https://stackoverflow.com/questions/344117/how-to-get-user-roles-...]. > That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations. > This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4785) DRL applies even if groupflow was not assigned 7.5

by Anna Dupliak (Jira)

[ https://issues.jboss.org/browse/DROOLS-4785?page=com.atlassian.jira.plugi... ] Anna Dupliak updated DROOLS-4785: --------------------------------- Affects Version/s: 7.30.0.Final (was: 7.5.0.Final) > DRL applies even if groupflow was not assigned 7.5 > -------------------------------------------------- > > Key: DROOLS-4785 > URL: https://issues.jboss.org/browse/DROOLS-4785 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Anna Dupliak > Assignee: Daniele Zonca > Priority: Major > > *For version 7.5* > # Given Traffic repo > # Edit DRL driver status rules > {code}rule "Status 1: young driver" > when > driver: Driver(age <= 18) > then > driver.setStatus("young"); > end > rule "Status 2: young adult driver" > when > driver: Driver(age > 18 && < 25) > then > driver.setStatus("young adult"); > end > rule "Status 3: adult driver" > when > driver: Driver(age >= 25) > then > driver.setStatus("adult"); > end {code} > # Go to Driver Status Rules Tests.scesim > # Run the Tests > Expected : Tests failed bcs the values null expected (no DRL rules are applied) > Actual: Tests passed rules group was not updated -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2356) Failure in a step ResultHandler should not always be reported as occurring during rollback

by Katarina Hermanova (Jira)

[ https://issues.jboss.org/browse/WFCORE-2356?page=com.atlassian.jira.plugi... ] Katarina Hermanova reassigned WFCORE-2356: ------------------------------------------ Assignee: Katarina Hermanova > Failure in a step ResultHandler should not always be reported as occurring during rollback > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2356 > URL: https://issues.jboss.org/browse/WFCORE-2356 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Brian Stansberry > Assignee: Katarina Hermanova > Priority: Minor > > When AbstractOperationContext.Step invokes a ResultHandler it catches and logs any exception. But the logged message states that the catch was during rollback handling. When the code was first written, perhaps the catch block was only for rollback handling, but now it handles both rollback and completion of successful ops. So the log message needs to be accurate. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4767) Use descriptive error message for duplicate host/context deployments

by Katarina Hermanova (Jira)

[ https://issues.jboss.org/browse/WFCORE-4767?page=com.atlassian.jira.plugi... ] Katarina Hermanova updated WFCORE-4767: --------------------------------------- Component/s: Server > Use descriptive error message for duplicate host/context deployments > -------------------------------------------------------------------- > > Key: WFCORE-4767 > URL: https://issues.jboss.org/browse/WFCORE-4767 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Paul Ferraro > Assignee: Katarina Hermanova > Priority: Minor > > If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons. > What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4767) Use descriptive error message for duplicate host/context deployments

by Katarina Hermanova (Jira)

[ https://issues.jboss.org/browse/WFCORE-4767?page=com.atlassian.jira.plugi... ] Katarina Hermanova moved WFLY-4051 to WFCORE-4767: -------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4767 (was: WFLY-4051) Component/s: (was: Web (Undertow)) Affects Version/s: (was: 9.0.0.Alpha1) > Use descriptive error message for duplicate host/context deployments > -------------------------------------------------------------------- > > Key: WFCORE-4767 > URL: https://issues.jboss.org/browse/WFCORE-4767 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Paul Ferraro > Assignee: Katarina Hermanova > Priority: Minor > > If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons. > What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2019