February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods

by Trond G. Ziarkowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ] Trond G. Ziarkowski updated WFLY-6280: -------------------------------------- Steps to Reproduce: {noformat} public class VisibilityBridgedMethod { static class Parent { public String methodToCall() { return "value"; } } public static class Child extends Parent { // methodToCall() will be bridged by compiler } public static void main(String[] args) { ELProcessor processor = new ELProcessor(); processor.defineBean("child", new Child()); processor.eval("child.methodToCall()"); } } {noformat} was: {{public class VisibilityBridgedMethod { static class Parent { public String methodToCall() { return "value"; } } public static class Child extends Parent { // methodToCall() will be bridged by compiler } public static void main(String[] args) { ELProcessor processor = new ELProcessor(); processor.defineBean("child", new Child()); processor.eval("child.methodToCall()"); } } }} > Can not call "visibility" bridged methods > ----------------------------------------- > > Key: WFLY-6280 > URL: https://issues.jboss.org/browse/WFLY-6280 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Trond G. Ziarkowski > Assignee: Farah Juma > > After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods. > This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods

by Trond G. Ziarkowski (JIRA)

Trond G. Ziarkowski created WFLY-6280: ----------------------------------------- Summary: Can not call "visibility" bridged methods Key: WFLY-6280 URL: https://issues.jboss.org/browse/WFLY-6280 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 10.0.0.Final, 9.0.2.Final Reporter: Trond G. Ziarkowski Assignee: Farah Juma After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods. This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Radim Vansa resolved JGRP-1711. ------------------------------- Fix Version/s: 3.6 (was: Future) Resolution: Done Changes already incorporated into DELAY. > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5916) jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-5916?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann commented on WFLY-5916: ------------------------------------------ Do you see a chance to include at least jackson-datatype-jsr310 in the next WildFly release? > jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing > ------------------------------------------------------------- > > Key: WFLY-5916 > URL: https://issues.jboss.org/browse/WFLY-5916 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.CR5 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > > WildFly doesn't provide jackson-datatype-jsr310 and jackson-datatype-jdk8 for RESTEasy. jackson-datatype-jsr310 supports the new JDK 8 time API, and jackson-datatype-jdk8 supports the new JDK 8 Optional type. > The GAVs are: > com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.6.3 > com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.6.3 > The latest Jackson GA version is 2.6.4. Please see also https://issues.jboss.org/browse/WFLY-5915. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2020) Remove demos and tests packages from final artifact

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2020?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2020: --------------------------- Fix Version/s: 4.0 Certainly not the demos, as people may want to run them. The tests, yes, but they are actually removed, but as part of the (damn) maven build they were added again. I'm working on https://issues.jboss.org/browse/JGRP-1706 to create an equivalent ant&ivy build to replace the maven build system. > Remove demos and tests packages from final artifact > --------------------------------------------------- > > Key: JGRP-2020 > URL: https://issues.jboss.org/browse/JGRP-2020 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Environment: Wildfly 10.0.0.Final > Reporter: Mathieu Lachance > Assignee: Bela Ban > Fix For: 4.0 > > > Would it be possible to remove unecessary (I assume) demos and tests packages from the final built artifact. > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6251) Add configuration to disable systematic file watch in ServletResourceManager

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/WFLY-6251?page=com.atlassian.jira.plugin.... ] Mathieu Lachance commented on WFLY-6251: ---------------------------------------- I'm working on a legacy application which is writing inside the exploded war at runtime (yes indeed, this is pretty bad), hence explaining the exploded format. That application is also servicing a lot of static content files spread across many folders (yes indeed a web server should have been used for that). To make things worse, we are using one big server machine, which host multiple jboss process which will then host multiple time that exploded war (one war per tenant). All of this combined, make it hard on the OS. Having a system property configuration would allow us to smoothly transition to non exploded war format without having to patch undertow meanwhile. Hope this better help you understand the use case. > Add configuration to disable systematic file watch in ServletResourceManager > ---------------------------------------------------------------------------- > > Key: WFLY-6251 > URL: https://issues.jboss.org/browse/WFLY-6251 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Oracle JDK 8u74 on CentOs > Reporter: Mathieu Lachance > Assignee: Stuart Douglas > > Our application is deployed multiple time in production as an exploded war. > Eventually we are running into "User limit of inotify watches reached": > {code} > ERROR [io.undertow] (MSC service thread 1-6) UT005024: Could not register resource change listener for caching resource manager, automatic invalidation of cached resource will not work: java.lang.RuntimeException: java.io.IOException: User limit of inotify watches reached > at org.xnio.nio.WatchServiceFileSystemWatcher.watchPath(WatchServiceFileSystemWatcher.java:179) > at io.undertow.server.handlers.resource.FileResourceManager.registerResourceChangeListener(FileResourceManager.java:161) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:80) > at io.undertow.server.handlers.resource.CachingResourceManager.<init>(CachingResourceManager.java:64) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:525) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:256) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > Caused by: java.io.IOException: User limit of inotify watches reached > at sun.nio.fs.LinuxWatchService$Poller.implRegister(LinuxWatchService.java:264) [rt.jar:1.8.0_45] > at sun.nio.fs.AbstractPoller.processRequests(AbstractPoller.java:260) [rt.jar:1.8.0_45] > at sun.nio.fs.LinuxWatchService$Poller.run(LinuxWatchService.java:329) [rt.jar:1.8.0_45] > ... 1 more > {code} > From what I'm seeing in: > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... > there's no way to disable the file resource watch at the sole exception of using non-exploded war deployment. > We will eventually switch to a non-exploded war but I think having a configuration (either within the standalone.xml or via system property) to completly turn off that feature would be a nice addition / improvement. > In the meanwhile, as a workaround we have increased the inotify watch on the OS and will most likely patch either undertow and/or wildfly-undertow to not add any watch at all. > Thanks -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5969) io.undertow.servlet.handlers.DefaultServlet will list incorrect directory contents

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5969?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5969: -------------------------------------- Do you have a reproducer that demonstrates this? I don't see how setting the context path could be affecting this. > io.undertow.servlet.handlers.DefaultServlet will list incorrect directory contents > ---------------------------------------------------------------------------------- > > Key: WFLY-5969 > URL: https://issues.jboss.org/browse/WFLY-5969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Environment: MacOS with Java 8u65 > Reporter: Matthew Casperson > Assignee: Stuart Douglas > Attachments: Screen Shot 2016-01-11 at 11.24.34 am.png, Screen Shot 2016-01-11 at 11.24.41 am.png > > > The Untertow DefaultServlet exhibits some odd behaviour when it has been mapped to a subdirectory. > To see this behaviour, build the WAR file from the sample project at https://github.com/mcasperson/wildfly-default-servlet-bug. Deploy to WildFly 10 CR5, and open the link http://localhost:8080/wildfly-default-servlet-bug/static (note no slash on the end of the URL). You'll see the expected directory listing. > !Screen Shot 2016-01-11 at 11.24.41 am.png|thumbnail! > Now open http://localhost:8080/wildfly-default-servlet-bug/static/ (note the slash on the end). You'll actually now be browsing the root directory of the application. > !Screen Shot 2016-01-11 at 11.24.34 am.png|thumbnail! > Now open http://localhost:8080/wildfly-default-servlet-bug/static/static/data.xml (note the double static in the URL). You'll be able to open the XML file. This is not what I would have expected. > Now open http://localhost:8080/wildfly-default-servlet-bug/static/data.xml. You'll get a 404. I would have expected to be able to open the file using this URL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6251) Add configuration to disable systematic file watch in ServletResourceManager

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6251?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6251: -------------------------------------- Why are you using exploded wars if you don't want to use hot deploy? > Add configuration to disable systematic file watch in ServletResourceManager > ---------------------------------------------------------------------------- > > Key: WFLY-6251 > URL: https://issues.jboss.org/browse/WFLY-6251 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Oracle JDK 8u74 on CentOs > Reporter: Mathieu Lachance > Assignee: Stuart Douglas > > Our application is deployed multiple time in production as an exploded war. > Eventually we are running into "User limit of inotify watches reached": > {code} > ERROR [io.undertow] (MSC service thread 1-6) UT005024: Could not register resource change listener for caching resource manager, automatic invalidation of cached resource will not work: java.lang.RuntimeException: java.io.IOException: User limit of inotify watches reached > at org.xnio.nio.WatchServiceFileSystemWatcher.watchPath(WatchServiceFileSystemWatcher.java:179) > at io.undertow.server.handlers.resource.FileResourceManager.registerResourceChangeListener(FileResourceManager.java:161) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:80) > at io.undertow.server.handlers.resource.CachingResourceManager.<init>(CachingResourceManager.java:64) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:525) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:256) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > Caused by: java.io.IOException: User limit of inotify watches reached > at sun.nio.fs.LinuxWatchService$Poller.implRegister(LinuxWatchService.java:264) [rt.jar:1.8.0_45] > at sun.nio.fs.AbstractPoller.processRequests(AbstractPoller.java:260) [rt.jar:1.8.0_45] > at sun.nio.fs.LinuxWatchService$Poller.run(LinuxWatchService.java:329) [rt.jar:1.8.0_45] > ... 1 more > {code} > From what I'm seeing in: > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... > there's no way to disable the file resource watch at the sole exception of using non-exploded war deployment. > We will eventually switch to a non-exploded war but I think having a configuration (either within the standalone.xml or via system property) to completly turn off that feature would be a nice addition / improvement. > In the meanwhile, as a workaround we have increased the inotify watch on the OS and will most likely patch either undertow and/or wildfly-undertow to not add any watch at all. > Thanks -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1068) java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1068?page=com.atlassian.jira.plugi... ] Bill Tuminaro commented on DROOLS-1068: --------------------------------------- Still broke in drools-distribution-6.4.0.Beta2 -BillT > java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535) > ------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1068 > URL: https://issues.jboss.org/browse/DROOLS-1068 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: droolsReproducer.jar > > > We have encountered this issue when we insert a fact matching a certain rule, delete the fact then call fire all rules. > A reproducer is attached. > -BillT -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1068) java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1068?page=com.atlassian.jira.plugi... ] Bill Tuminaro commented on DROOLS-1068: --------------------------------------- Would trying the drools-distribution-6.4.0.Beta2.zip code level be helpful -BillT > java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535) > ------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1068 > URL: https://issues.jboss.org/browse/DROOLS-1068 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: droolsReproducer.jar > > > We have encountered this issue when we insert a fact matching a certain rule, delete the fact then call fire all rules. > A reproducer is attached. > -BillT -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 2016