January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-778) DelegatingPolicy should delegate refresh()

by Jan Kalina (JIRA)

Jan Kalina created SECURITY-778: ----------------------------------- Summary: DelegatingPolicy should delegate refresh() Key: SECURITY-778 URL: https://issues.jboss.org/browse/SECURITY-778 Project: PicketBox Issue Type: Enhancement Security Level: Public (Everyone can see) Components: PicketBox Reporter: Jan Kalina Assignee: Stefan Guilhen Priority: Optional DelegatingPolicy delegates non-JACC permissions to the java.security.Policy (or subclass) object. It delegates getPermissions() and implies() methods, but not refresh() method. It is bad, because DelegatingPolicy is used by default in current Wildfly and applications assuming standard policy provider and using normal security policy file will not refresh policies from file. Yes, user application can bypass it by using Policy.getPolicy().getPolicyProxy().refresh(); but this require to have "org.picketbox" in dependencies, so application on picketlink depends, or is incompatible... This illustrate patch of my policy switching jboss extension - before patch it works only without picketlink, after it works only with picketlink: https://github.com/honza889/jsm-policy-subsystem/commit/f2fb420b43ac3eedb... This should resolve this one line in DelegatingPolicy class: {code:java} public void refresh() { delegate.refresh(); } {code} Thanks More informations about DelegatingPolicy: https://community.jboss.org/wiki/DelegatingPolicy https://github.com/picketbox/picketbox-container/blob/e8dfc3e8306cdbd2329... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1765: -------------------------------- And why would that be a problem ? > TP: enable loopback by default and discard own multicasts > --------------------------------------------------------- > > Key: JGRP-1765 > URL: https://issues.jboss.org/browse/JGRP-1765 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again. > When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization. > SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText

by Andre Pankraz (JIRA)

[ https://issues.jboss.org/browse/WFLY-2703?page=com.atlassian.jira.plugin.... ] Andre Pankraz updated WFLY-2703: -------------------------------- Description: Combine input text with default ajax event (leave): <h:form id="inhaltSearch"> <h:inputText id="contentname" size="30" value="#{contentList.content.searchTerms}"> <f:ajax render=":inhaltSearch" /> </h:inputText> </h:form> Enter value and press "Enter" (Tab works). A short Javascript alert appears and vanishes again. Stacktrace in Server: 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45] at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45] at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45] at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45] at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45] at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7] at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117) at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7] at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510) ... 9 more Affects Version/s: 8.0.0.CR1 Environment: Linux, JDK 7 Component/s: Web (Undertow) > Undertow Broken pipe with JSFs f:ajax and h:inputText > ----------------------------------------------------- > > Key: WFLY-2703 > URL: https://issues.jboss.org/browse/WFLY-2703 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: Linux, JDK 7 > Reporter: Andre Pankraz > > Combine input text with default ajax event (leave): > <h:form id="inhaltSearch"> > <h:inputText id="contentname" size="30" > value="#{contentList.content.searchTerms}"> > <f:ajax render=":inhaltSearch" /> > </h:inputText> > </h:form> > Enter value and press "Enter" (Tab works). > A short Javascript alert appears and vanishes again. > Stacktrace in Server: > 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.io.IOException: Broken pipe > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45] > at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45] > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45] > at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45] > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45] > at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7] > at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484) > at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189) > at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7] > at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117) > at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7] > at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510) > ... 9 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText

by Andre Pankraz (JIRA)

Andre Pankraz created WFLY-2703: ----------------------------------- Summary: Undertow Broken pipe with JSFs f:ajax and h:inputText Key: WFLY-2703 URL: https://issues.jboss.org/browse/WFLY-2703 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andre Pankraz -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts

by Karim AMMOUS (JIRA)

[ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.... ] Karim AMMOUS commented on JGRP-1765: ------------------------------------ Disable the loopback ensures as much as possible that the sender handles the message at the same time as the other receivers. Otherwise, with loopback, there are more risks the sender processes the data much before the other members due to the network latency. > TP: enable loopback by default and discard own multicasts > --------------------------------------------------------- > > Key: JGRP-1765 > URL: https://issues.jboss.org/browse/JGRP-1765 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again. > When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization. > SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-490) Domain Management Role Based Access Control

by Gopi Chand Uppala (JIRA)

[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ] Gopi Chand Uppala commented on WFLY-490: ---------------------------------------- Okay. Thanks for the clarification! > Domain Management Role Based Access Control > ------------------------------------------- > > Key: WFLY-490 > URL: https://issues.jboss.org/browse/WFLY-490 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: Authorization > Fix For: 8.0.0.Final > > > Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute. > Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-351) KIE FileSystem resource type overriding does not work as reported by documentation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-351?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-351: ------------------------------------------------ Tomas Schlosser <tschloss(a)redhat.com> changed the Status of [bug 1034250|https://bugzilla.redhat.com/show_bug.cgi?id=1034250] from ON_QA to VERIFIED > KIE FileSystem resource type overriding does not work as reported by documentation > ---------------------------------------------------------------------------------- > > Key: DROOLS-351 > URL: https://issues.jboss.org/browse/DROOLS-351 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.1.0.Beta1 > > > When a resource is written into the KieFileSystem using the method write( path, Resource ), the resource type is ignored and it will be resolved from the file extension instead. > That is, Example 4.10 in the Drools Official Documentation is misleading and pointing to an unimplemented feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1548: ----------------------------------------------- Shaun Appleton <sappleto(a)redhat.com> changed the Status of [bug 901311|https://bugzilla.redhat.com/show_bug.cgi?id=901311] from ASSIGNED to CLOSED > Add fallback querry to jconsole plugin > -------------------------------------- > > Key: WFLY-1548 > URL: https://issues.jboss.org/browse/WFLY-1548 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Darran Lofthouse > Labels: JConsole, JMX, Plugin > Fix For: 8.0.0.Beta1 > > > JConsolePlugin connecects to default port, despite chance to use proper info. > Problem: > Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote. > AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990. > However we can check for socket bindings and try to connect to proper socket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2702) CalendarBasedTimeoutTestCase failures at end/begin of the month

by Eduardo Martins (JIRA)

Eduardo Martins created WFLY-2702: ------------------------------------- Summary: CalendarBasedTimeoutTestCase failures at end/begin of the month Key: WFLY-2702 URL: https://issues.jboss.org/browse/WFLY-2702 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Reporter: Eduardo Martins Assignee: Eduardo Martins The referred test in the ejb module fails on end and begin of months, due to different timezones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1765: -------------------------------- Why ? I want to reduce the number of properties, and removing loopback is on my list as we'd loop back messages by default. > TP: enable loopback by default and discard own multicasts > --------------------------------------------------------- > > Key: JGRP-1765 > URL: https://issues.jboss.org/browse/JGRP-1765 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again. > When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization. > SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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 January 2014