[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ]
Michal Petrov commented on WFLY-10319:
--------------------------------------
[~jestevezsanchez], I don't think this is a bug. By design nested classes do not inherit the annotations of their outer class and annotations are not inheritable by default. That is core Java not something in the JAX-RS subsystem or RESTEasy. In order to make something like this work you need to:
* make DemoSubResource extend DemoResource
* add \@Inherited to the name binding
> NameBinding annotations on resources are ignored in subresources
> ----------------------------------------------------------------
>
> Key: WFLY-10319
> URL: https://issues.jboss.org/browse/WFLY-10319
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Javier Estevez Sanchez
> Assignee: Jason Greene
>
> 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.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFCORE-3996) GC logging is not working on Java 9
by Radovan Stancel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3996?page=com.atlassian.jira.plugi... ]
Radovan Stancel updated WFCORE-3996:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3496, https://github.com/wildfly/wildfly-core/pull/3538 (was: https://github.com/wildfly/wildfly-core/pull/3496)
> GC logging is not working on Java 9
> -----------------------------------
>
> Key: WFCORE-3996
> URL: https://issues.jboss.org/browse/WFCORE-3996
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
> Assignee: Radovan Stancel
> Priority: Blocker
> Labels: Java11, blocker-WF14
> Fix For: 7.0.0.Alpha2
>
>
> GC logging is not working on Java 9. This is related to the fact G1 GC is default and there are changes in configuration option.
> {code}
> GC_LOG="true" ./standalone.sh
> {code}
> Java 8:
> {code}
> JAVA_OPTS: -server -verbose:gc -Xloggc:"/Users/rsvoboda/TESTING/7.2.0.CD12.CR1/jboss-eap-7.2/standalone/log/gc.log"
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5
> -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
> Java 9:
> {code}
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1653) JDK 11 Support
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/ELY-1653?page=com.atlassian.jira.plugin.s... ]
Ondrej Kotek updated ELY-1653:
------------------------------
Labels: Java11 (was: )
> JDK 11 Support
> --------------
>
> Key: ELY-1653
> URL: https://issues.jboss.org/browse/ELY-1653
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Justin Cook
> Labels: Java11
> Fix For: 1.7.0.CR3
>
>
> I suspect this will likely take three / four steps: -
> # Convert he project to a multi-release built using Java 9
> # Eliminate the use of APIs in sun.misc and sun.reflect in the Java 9 variant
> # Ensure the project can be build on JDK 11
> This final step may not be achievable in the short term until we can drop support for JDK 8 but by moving to the Java 9 MR jar our jar should be compatible on Java 10 and 11 as well. We may want to define a PR run that builds on Java 9 but tests in Java 11, this would mean the testsuite at least needs to be buildable on Java 11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ELY-1642) Compilation error on JDK 11: cannot find class sun.reflect.Reflection
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/ELY-1642?page=com.atlassian.jira.plugin.s... ]
Ondrej Kotek updated ELY-1642:
------------------------------
Labels: Java11 (was: )
> Compilation error on JDK 11: cannot find class sun.reflect.Reflection
> ---------------------------------------------------------------------
>
> Key: ELY-1642
> URL: https://issues.jboss.org/browse/ELY-1642
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 1.5.1.Final
> Environment: openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+25)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+25, mixed mode)
> Reporter: Ondrej Kotek
> Assignee: Justin Cook
> Priority: Critical
> Labels: Java11
> Fix For: 1.7.0.CR1
>
>
> {{mvn test}} results in compilation error:
> {noformat}
> [ERROR] /home/okotek/git/wildfly-elytron/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[58,19] cannot find symbol
> symbol: class Reflection
> location: package sun.reflect
> {noformat}
> Blocks testing on JDK 11, setting to Critical.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Klara Kufova (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3053:
---------------------------------
Tester: Klara Kufova
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months