February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources

by Ron Sigal (Jira)

[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ] Ron Sigal commented on WFLY-10319: ---------------------------------- So, [~jestevezsanchez], [~mkopecky], we can close this one? > NameBinding annotations on resources are ignored in subresources > ---------------------------------------------------------------- > > Key: WFLY-10319 > URL: https://issues.jboss.org/browse/WFLY-10319 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 12.0.0.Final > Reporter: Javier Estevez Sanchez > Assignee: Alessio Soldano > Priority: Major > > The following JAX-RS resource exposes two resources via a GET operation: /demo and /demo/subresource. The first one via a sub-resource method, the latter via a sub-resource locator. Additionally, a response filter is binded to the JAX-RS resource class to modify the response. From the JAX-RS 2.0 spec, §6.5.2 Name Binding: > {quote} > Binding annotations that decorate resource classes apply to all resource methods defined in them. > {quote} > However, the binding annotation is not applying to the sub-resource locator method. This happens when the name binding annotation is on the resource class or on the sub-resource locator method. Annotating the sub-resource class or the method within works as expected, though. > Below is the code needed to reproduce this issue: > {code:java|title=The resource and subresource} > @DemoNameBinding > @Produces(MediaType.APPLICATION_JSON) > @Path("/demo") > public class DemoResource { > @GET > public String getDemoValue() { > return "A value"; > } > @Path("/subresource") > public DemoSubResource getSubResource() { > return new DemoSubResource(); > } > public class DemoSubResource { > @GET > public String getDemoValue() { > return "A value"; > } > } > } > {code} > {code:java|title=The filter} > @Provider > @DemoNameBinding > public class SomeFilter implements ContainerResponseFilter { > @Override > public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) { > responseContext.setEntity("A filtered value"); > } > } > {code} > {code:java|title=The binding} > @NameBinding > @Target({ElementType.TYPE, ElementType.METHOD}) > @Retention(RetentionPolicy.RUNTIME) > public @interface DemoNameBinding { > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11692) Upgrade WildFly Core 8.0.0.Beta5

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11692?page=com.atlassian.jira.plugin... ] Jeff Mesnil reassigned WFLY-11692: ---------------------------------- Assignee: Jeff Mesnil (was: Brian Stansberry) > Upgrade WildFly Core 8.0.0.Beta5 > -------------------------------- > > Key: WFLY-11692 > URL: https://issues.jboss.org/browse/WFLY-11692 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11692) Upgrade WildFly Core 8.0.0.Beta5

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11692?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-11692: ------------------------------- Component/s: Management > Upgrade WildFly Core 8.0.0.Beta5 > -------------------------------- > > Key: WFLY-11692 > URL: https://issues.jboss.org/browse/WFLY-11692 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11692) Upgrade WildFly Core 8.0.0.Beta5

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-11692: ---------------------------------- Summary: Upgrade WildFly Core 8.0.0.Beta5 Key: WFLY-11692 URL: https://issues.jboss.org/browse/WFLY-11692 Project: WildFly Issue Type: Component Upgrade Reporter: Jeff Mesnil Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3627) DMN compare FEEL time with tz

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3627: -------------------------------------- Summary: DMN compare FEEL time with tz Key: DROOLS-3627 URL: https://issues.jboss.org/browse/DROOLS-3627 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3626) [DMN Designer] Decision Service Output Data-type should be based on Output Decisions

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3626?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-3626: ---------------------------------------- In order to ascertain the required Decision Service Output Data-type we need to know what Decisions constitute the _outputs_. At the moment we only categorise the Decisions as _encapsulated_ or _output_ when the file is saved. However the linked JIRA ensures the lists of Decisions held by the Decision Service object are correctly categorised as the User makes changes to the Decision Service whilst authoring. > [DMN Designer] Decision Service Output Data-type should be based on Output Decisions > ------------------------------------------------------------------------------------ > > Key: DROOLS-3626 > URL: https://issues.jboss.org/browse/DROOLS-3626 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > The Output Data-type of a Decision Service can currently be set explicitly by the User (and indeed must be set by the User). However the Output Data-type of a Decision Service can be automatically set (and possibly created) based on the Output Data-type of the Output Decision(s) within the Decision Service. > For example, if the Decision Service contains a single Output Decision the Output Data-type of the Decision Service is the same as that of the single Output Decision. If the Decision Service has multiple Output Decisions then the Decision Service Output Data-type should be a combination of those of the different Output Decisions. A new Data-type may need to be automatically generated. For example a DS has 2 OD's with Data-types A and B. The DS Output Data-type should be a single Data-type being the combination of A and B. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3626) [DMN Designer] Decision Service Output Data-type should be based on Output Decisions

by Michael Anstis (Jira)

Michael Anstis created DROOLS-3626: -------------------------------------- Summary: [DMN Designer] Decision Service Output Data-type should be based on Output Decisions Key: DROOLS-3626 URL: https://issues.jboss.org/browse/DROOLS-3626 Project: Drools Issue Type: Enhancement Components: DMN Editor Affects Versions: 7.17.0.Final Reporter: Michael Anstis Assignee: Michael Anstis The Output Data-type of a Decision Service can currently be set explicitly by the User (and indeed must be set by the User). However the Output Data-type of a Decision Service can be automatically set (and possibly created) based on the Output Data-type of the Output Decision(s) within the Decision Service. For example, if the Decision Service contains a single Output Decision the Output Data-type of the Decision Service is the same as that of the single Output Decision. If the Decision Service has multiple Output Decisions then the Decision Service Output Data-type should be a combination of those of the different Output Decisions. A new Data-type may need to be automatically generated. For example a DS has 2 OD's with Data-types A and B. The DS Output Data-type should be a single Data-type being the combination of A and B. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3625) [DMN Designer] Remove Stunners Explorer widget from the RHS dock

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3625?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3625: ----------------------------------- Issue Type: Task (was: Bug) > [DMN Designer] Remove Stunners Explorer widget from the RHS dock > ---------------------------------------------------------------- > > Key: DROOLS-3625 > URL: https://issues.jboss.org/browse/DROOLS-3625 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > The DMN Editor has a "Decision Navigator" widget (in the LHS dock) that currently shows the content of the whole DRG however it will also become the DRD explorer too. This duplicates Stunner's _default_ Explorer widget in the RHS dock. > The DMN Editor should have Stunner's _default_ widget removed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3625) [DMN Designer] Remove Stunners Explorer widget from the RHS dock

by Michael Anstis (Jira)

Michael Anstis created DROOLS-3625: -------------------------------------- Summary: [DMN Designer] Remove Stunners Explorer widget from the RHS dock Key: DROOLS-3625 URL: https://issues.jboss.org/browse/DROOLS-3625 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.17.0.Final Reporter: Michael Anstis Assignee: Michael Anstis The DMN Editor has a "Decision Navigator" widget (in the LHS dock) that currently shows the content of the whole DRG however it will also become the DRD explorer too. This duplicates Stunner's _default_ Explorer widget in the RHS dock. The DMN Editor should have Stunner's _default_ widget removed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3614?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-3614: ---------------------------------------- [~tirelli] [~uxdlc] I was thinking about this JIRA. At the moment editing an expression from the graph changes the _editor_ tab from the _graph_ to the _grid_ view. I was wondering whether it'd be good to change this so that editing an expression opens the corresponding _grid_ in a new tab. This would impact the "<< Back to" bread crumb on the _grid_ view (i.e. remove it!) and navigating from the Decision Navigator. WDYT? > [DMN Designer] Maximize Event brings palette to expression editor > ----------------------------------------------------------------- > > Key: DROOLS-3614 > URL: https://issues.jboss.org/browse/DROOLS-3614 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-02-07 14-25-52.png > > > If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019