[JBoss JIRA] (WFLY-7149) Unable to remove elytron subsystem with defined properties-realm
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7149?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7149:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Unable to remove elytron subsystem with defined properties-realm
> ----------------------------------------------------------------
>
> Key: WFLY-7149
> URL: https://issues.jboss.org/browse/WFLY-7149
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
> \[1\]
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
> Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7103:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7103
> URL: https://issues.jboss.org/browse/WFLY-7103
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Radim Hatlapatka
> Assignee: Jan Kalina
> Fix For: 11.0.0.Final
>
>
> When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable.
> If it is really mandatory, it should be marked as required.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4769:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Final
>
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-7214) Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7214?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7214:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7214
> URL: https://issues.jboss.org/browse/WFLY-7214
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Lin Gao
> Assignee: Lin Gao
> Fix For: 11.0.0.Final
>
>
> When a data-source was failed to be added because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2, connection-url="jdbc:h2:test")
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:test-connection-in-pool()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid",
> "rolled-back" => true
> }
> {code}
> {panel:title=NOTE FOR THE VERIFY}
> Changing the Step 1 to:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> for the verifying, because of with fixing of https://issues.jboss.org/browse/JBJCA-1331 (also fixed in ironjacamar-1.3.5.Final), the original step 1 will not cause problems any more.
> {panel}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-6122) It is not possible to set HTTP/2 options on a connector
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6122?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6122:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> It is not possible to set HTTP/2 options on a connector
> -------------------------------------------------------
>
> Key: WFLY-6122
> URL: https://issues.jboss.org/browse/WFLY-6122
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 11.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4763) Include org.jboss.invocation in group ids that are synced to Maven central
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4763?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4763:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Include org.jboss.invocation in group ids that are synced to Maven central
> --------------------------------------------------------------------------
>
> Key: WFLY-4763
> URL: https://issues.jboss.org/browse/WFLY-4763
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: jaikiran pai
> Assignee: Paul Gier
> Fix For: 11.0.0.Final
>
>
> The jboss-invocation module under the org.jboss.invocation group (https://github.com/jbossas/jboss-invocation/ - project home) isn't available in Maven central unlike most of the other org.jboss projects.
> jboss-invocation is part of WildFly dependencies. Please include the org.jboss.invocation group id in the groups that are synced to Maven central.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-8731) Unable to inject EJBs into web resources
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8731?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-8731:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Unable to inject EJBs into web resources
> ----------------------------------------
>
> Key: WFLY-8731
> URL: https://issues.jboss.org/browse/WFLY-8731
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0 on Windows 10
> Reporter: Archimedes Trajano
> Assignee: Stuart Douglas
> Fix For: 11.0.0.Final
>
>
> There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
> Their comment was based on just WebListener, but I found it applied to the following as well
> * WebServlet
> * WebService (code first and contract first)
> * JAX-RS paths.
> One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-8813) Move javax.json module to WildFly Core
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8813?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-8813:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Move javax.json module to WildFly Core
> --------------------------------------
>
> Key: WFLY-8813
> URL: https://issues.jboss.org/browse/WFLY-8813
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> The Elytron subsystem has been moved to WildFly Core, the Elytron audit logger makes use of JSON so this module is required (Currently marked as optional).
> Once available the module dependency from the org.wildfly.security.elytron-private module should also not be marked as optional.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-6153) [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6153?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6153:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
> ------------------------------------------------------------------
>
> Key: WFLY-6153
> URL: https://issues.jboss.org/browse/WFLY-6153
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Fix For: 11.0.0.Final
>
>
> When migrating RemoteIpValve which looks like this
> {code:xml}
> <valve name="remote-ip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
> <param param-name="httpServerPort" param-value="8080"/>
> <param param-name="httpsServerPort" param-value="8443"/>
> <param param-name="internalProxies" param-value="192.*|127.*"/>
> <param param-name="trustedProxies" param-value="10.*"/>
> <param param-name="protocolHeaderHttpsValue" param-value="https"/>
> <param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
> <param param-name="remoteIpHeader" param-value="X-Forwarded-For"/>
> <param param-name="proxiesHeader" param-value="X-Forwarded-By"/>
> </valve>
> {code}
> it is migrated to expression filter looking like this
> {noformat}
> <expression-filter expression="regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }" name="remote-ip-valve"/>
> {noformat}
> When doing request to http://127.0.0.1:8080/ it fails with 500 and this exception in log
> {noformat}
> 14:06:53,648 ERROR [io.undertow.request] (default I/O-4) UT005071: Undertow request failed HttpServerExchange{ GET / request {Accept=[*/*], User-Agent=[curl/7.43.0-DEV], Host=[127.0.0.1:8080]} response {}}: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string Expecting , or ):
> regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }
> ^
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.error(PredicatedHandlersParser.java:727)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parseExpression(PredicatedHandlersParser.java:506)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:381)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:322)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:85)
> at org.wildfly.extension.undertow.filters.ExpressionFilterDefinition.createHttpHandler(ExpressionFilterDefinition.java:88)
> at org.wildfly.extension.undertow.filters.FilterService.createHttpHandler(FilterService.java:57)
> at org.wildfly.extension.undertow.filters.FilterRef.createHttpHandler(FilterRef.java:69)
> at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:96)
> at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:117)
> at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:171)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:285)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:64)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> {noformat}
> The exception is caused by not having in quotes the '%\{i, x-forwarded-for\}'.
> Also there is no predicate named {{regexp}}, the correct name is {{regex}}.
> As this is hidden to the customer during the migration operation and is not visible before customer sends request to the server marking as blocker.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months