February 2016 - jboss-jira - Jboss List Archives

[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)

9 years, 8 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)

9 years, 8 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)

9 years, 8 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)

9 years, 8 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)

9 years, 8 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)

9 years, 8 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: --------------------------------------- Are the drools jar files available for download for this snapshot or do I have compile them myself? -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)

9 years, 8 months

1
0
0 / 0

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

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1068?page=com.atlassian.jira.plugi... ] Mark Proctor commented on DROOLS-1068: -------------------------------------- Any chance you could confirm this against 7.0 snapshot, as it may already be fixed. If it is not, would it possible to submit a self contained test. Similar to other MiscTests. Please see getting involved docs for how to do pull requests and write tests we can easily add to our test suite: http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch01.ht... > 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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6267) JSTL will fail with tags using x:out nested in a x:forEach

by Matthew Casperson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6267?page=com.atlassian.jira.plugin.... ] Matthew Casperson commented on WFLY-6267: ----------------------------------------- Pull request has been done: https://github.com/jboss/jboss-jstl-api_spec/pull/12 > JSTL will fail with tags using x:out nested in a x:forEach > ---------------------------------------------------------- > > Key: WFLY-6267 > URL: https://issues.jboss.org/browse/WFLY-6267 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Matthew Casperson > Assignee: Stuart Douglas > > See https://github.com/mcasperson/wildfly_jstl_bug/ > What happens is you have a x:forEach in a JSP page. Inside this x:forEach you call a tag that itself has a x:forEach. The variable created by the second x:forEach is inaccessible to any nested x:out elements. > This happens because the x:out pageContext is actually linked to the pageContext from the jsp page, which doesn't hold any variables created by the x:whatever elements in the tag file. > See https://github.com/mcasperson/wildfly_jstl_bug/blob/master/src/main/webap... and https://github.com/mcasperson/wildfly_jstl_bug/blob/master/src/main/webap... for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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)

Bill Tuminaro created DROOLS-1068: ------------------------------------- Summary: 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)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016