[JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause test failures
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
SBS JIRA Integration updated WFLY-2641:
---------------------------------------
Forum Reference: https://community.jboss.org/message/851346#851346
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Aslak Knutsen
> Priority: Critical
> Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {code}
--
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
10 years, 4 months
[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 commented on WFLY-2703:
-------------------------------------
OK, happens only with
web.xml:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
not with Production, SystemTest etc.
can live with that...but should be fixed ;)
> 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
10 years, 4 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2689:
---------------------------------------
Bean accessibility follows classloader isolation - a bean from a deployment is not considered accessible from a bean in a static module. We cannot change this until WELD-1536 is resolved.
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
10 years, 4 months
[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:
------------------------------------
- Use multicast allows all members to receive the data (command) at the same time. In our system, due to non-functional requirements, we must ensure the delay between the treatment done by the emitter and the receivers is less than few dozens of milliseconds.
- Useful to synchronize many actions.
- And if there is a multicast issue, the emitter *and* the receivers won't handle the message.
> 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
10 years, 4 months
[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
10 years, 4 months
[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
10 years, 4 months
[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
10 years, 4 months
[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
10 years, 4 months
[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
10 years, 4 months