October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ] Panagiotis Sotiropoulos commented on WFLY-1264: ----------------------------------------------- Karel could you please provide the requirements and assign the issue back, or close it. Thank you in advance. > Create a test to get notifications when hosts join/leave a domain > ----------------------------------------------------------------- > > Key: WFLY-1264 > URL: https://issues.jboss.org/browse/WFLY-1264 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Andrew Rubinger > Assignee: Karel Piwko > > Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ] Panagiotis Sotiropoulos updated WFLY-1264: ------------------------------------------ Assignee: Karel Piwko (was: Panagiotis Sotiropoulos) > Create a test to get notifications when hosts join/leave a domain > ----------------------------------------------------------------- > > Key: WFLY-1264 > URL: https://issues.jboss.org/browse/WFLY-1264 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Andrew Rubinger > Assignee: Karel Piwko > > Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3967) Wrong keys added when creating trust domains

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-3967?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-3967: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6803 > Wrong keys added when creating trust domains > -------------------------------------------- > > Key: WFLY-3967 > URL: https://issues.jboss.org/browse/WFLY-3967 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Labels: PL_SUB > > When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. > The wrong key uses a host as its value, where should be the alias of a key/certificate. > The logic that creates keys based on trust-domain insertion is no longer necessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3967) Wrong keys added when creating trust domains

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-3967?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-3967: ----------------------------- Description: When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. The wrong key uses a host as its value, where should be the alias of a key/certificate. The logic that creates keys based on trust-domain insertion is no longer necessary. was: When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. The wrong key uses a host as its value, where should be the alias of a certificate. The logic that creates keys based on trust-domain insertion is no longer necessary. > Wrong keys added when creating trust domains > -------------------------------------------- > > Key: WFLY-3967 > URL: https://issues.jboss.org/browse/WFLY-3967 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Labels: PL_SUB > > When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. > The wrong key uses a host as its value, where should be the alias of a key/certificate. > The logic that creates keys based on trust-domain insertion is no longer necessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3262) WebServiceRef injection without explicit wsdl file fails during Servlet initialization

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-3262?page=com.atlassian.jira.plugin.... ] R Searls reassigned WFLY-3262: ------------------------------ Assignee: R Searls (was: Alessio Soldano) > WebServiceRef injection without explicit wsdl file fails during Servlet initialization > -------------------------------------------------------------------------------------- > > Key: WFLY-3262 > URL: https://issues.jboss.org/browse/WFLY-3262 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.CR1 > Reporter: Matus Abaffy > Assignee: R Searls > Fix For: 9.0.0.CR1 > > > Reproducer test available at https://github.com/bafco/wildfly/commits/wsServletInjection > I have the following servlet > {code} > @WebServlet(/*..., */ loadOnStartup = 1) > public class ServletLoadOnStartup extends HttpServlet { > @WebServiceRef(value = EndpointService.class) > private EndpointInterface endpoint1; > //... > {code} > (It is located in the package org.jboss.as.test.integration.ws.serviceref. There you can find more info about the other classes.) > And i get the following exception: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: ws-servlet-test.war > ... > Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ws-servlet-test" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ws-servlet-test: javax.servlet.ServletException: UT010013: Could not instantiate ServletLoadOnStartup > Caused by: javax.servlet.ServletException: UT010013: Could not instantiate ServletLoadOnStartup > Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance > Caused by: java.lang.RuntimeException: JBAS011875: Resource lookup for injection failed: env/org.jboss.as.test.integration.ws.serviceref.ServletLoadOnStartup/endpoint1 > Caused by: javax.naming.NamingException: JBAS011878: Failed to lookup env/org.jboss.as.test.integration.ws.serviceref.ServletLoadOnStartup/endpoint1 [Root exception is org.jboss.wsf.spi.WSFException: Cannot create service] > Caused by: org.jboss.wsf.spi.WSFException: Cannot create service > Caused by: java.lang.reflect.InvocationTargetException > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service. > Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service. > Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl'.: java.io.FileNotFoundException: http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl > Caused by: java.io.FileNotFoundException: http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl"}} > {code} > If I change loadOnStartup parameter to -1, everything works fine, i.e. servlet gets instantiated and WS is injected correctly. Therefore, I suppose this is a bug. > Another workaround exists - adding wsdl file to the deployment archive and using the 'wsdlLocation' parameter in @WebServiceRef (as can be seen in ServiceRefSevletTestCase). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3967) Wrong keys added when creating trust domains

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-3967?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-3967: ----------------------------- Description: When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. The wrong key uses a host as its value, where should be the alias of a certificate. The logic that creates keys based on trust-domain insertion is no longer necessary. > Wrong keys added when creating trust domains > -------------------------------------------- > > Key: WFLY-3967 > URL: https://issues.jboss.org/browse/WFLY-3967 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Labels: PL_SUB > > When adding a trust-domain to an identity-provider resource, a wrong key is added to the key-store resource. > The wrong key uses a host as its value, where should be the alias of a certificate. > The logic that creates keys based on trust-domain insertion is no longer necessary. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3967) Wrong keys added when creating trust domains

by Pedro Igor (JIRA)

Pedro Igor created WFLY-3967: -------------------------------- Summary: Wrong keys added when creating trust domains Key: WFLY-3967 URL: https://issues.jboss.org/browse/WFLY-3967 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 9.0.0.Alpha1 Reporter: Pedro Igor Assignee: Pedro Igor -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-3966: --------------------------------- Affects Version/s: 9.0.0.Alpha1 (was: 8.1.0.Final) > Update saaj-impl based on fix for SAAJ-74 > ----------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by Mustafa Musaji (JIRA)

Mustafa Musaji created WFLY-3966: ------------------------------------ Summary: Update saaj-impl based on fix for SAAJ-74 Key: WFLY-3966 URL: https://issues.jboss.org/browse/WFLY-3966 Project: WildFly Issue Type: Component Upgrade Components: Web Services Affects Versions: 8.1.0.Final Reporter: Mustafa Musaji SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3965) Messaging: NullPointerException when http-acceptor and https-acceptor configured

by Darren Jones (JIRA)

Darren Jones created WFLY-3965: ---------------------------------- Summary: Messaging: NullPointerException when http-acceptor and https-acceptor configured Key: WFLY-3965 URL: https://issues.jboss.org/browse/WFLY-3965 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 8.1.0.Final Environment: Windows 7 Pro, Java 7u55 Reporter: Darren Jones Assignee: Jeff Mesnil With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log. I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped. Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException. I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method. The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal. The exception was: [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161) [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153) [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149) [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271) [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221) [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131) [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351) [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78) [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33) [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273) [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207) [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489) [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470) [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152) [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45) [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45) [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014