November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5673) Equals signs in cookies configuration is not working in Domain mode

by Boominathan Shanmugam (JIRA)

[ https://issues.jboss.org/browse/WFLY-5673?page=com.atlassian.jira.plugin.... ] Boominathan Shanmugam commented on WFLY-5673: --------------------------------------------- Thanks Tomaz. Currently tried with 8.1.0 Final version. Will try with 8.2.x or 9.0 and will update. > Equals signs in cookies configuration is not working in Domain mode > ------------------------------------------------------------------- > > Key: WFLY-5673 > URL: https://issues.jboss.org/browse/WFLY-5673 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Boominathan Shanmugam > Assignee: Tomaz Cerar > > The property that allows WILDFLY 8.1 in standalone mode to have = in cookie values > <subsystem xmlns="urn:jboss:domain:undertow:1.1"> > <buffer-cache name="default"/> > <server name="default-server"> > <http-listener name="default" socket-binding="http" allow-equals-in-cookie-value="true"/> > The issue we are seeing is that setting that to true, via CLI, in domain mode does not make the code behave the same way as it does in standalone. Could be that there are more changes required in domain mode than just setting this setting, but I could not find anything. Could also be that caching is somehow not letting the new value in, tho I did restart the entire system, including the DC (even deleted the /tmp folder on both nodes and on DC). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1984) NPE while creating a dynamic FORK channel

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1984?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1984: --------------------------- Fix Version/s: 3.6.7 > NPE while creating a dynamic FORK channel > ----------------------------------------- > > Key: JGRP-1984 > URL: https://issues.jboss.org/browse/JGRP-1984 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Ramesh Reddy > Assignee: Bela Ban > Fix For: 3.6.7 > > > I am trying to create a ForkChannel based on the example in docs with code, when FORK protocol not present in the main stack > {code} > channel=new JChannel("tcp.xml")); > channel.connect("RpcDispatcherTestGroup"); > ForkChannel forkChannel = new ForkChannel(channel, "test-rpc", name, true, ProtocolStack.BELOW, FRAG2.class); > forkChannel.connect("test-rpc"); > {code} > this ends with > {code} > Exception in thread "main" java.lang.NullPointerException > at org.jgroups.protocols.FORK.createForkStack(FORK.java:199) > at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:79) > at org.teiid.systemmodel.RpcDispatcherTest.start(RpcDispatcherTest.java:32) > at org.teiid.systemmodel.RpcDispatcherTest.main(RpcDispatcherTest.java:54 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1984) NPE while creating a dynamic FORK channel

by Ramesh Reddy (JIRA)

Ramesh Reddy created JGRP-1984: ---------------------------------- Summary: NPE while creating a dynamic FORK channel Key: JGRP-1984 URL: https://issues.jboss.org/browse/JGRP-1984 Project: JGroups Issue Type: Bug Affects Versions: 3.6.4 Reporter: Ramesh Reddy Assignee: Bela Ban I am trying to create a ForkChannel based on the example in docs with code, when FORK protocol not present in the main stack {code} channel=new JChannel("tcp.xml")); channel.connect("RpcDispatcherTestGroup"); ForkChannel forkChannel = new ForkChannel(channel, "test-rpc", name, true, ProtocolStack.BELOW, FRAG2.class); forkChannel.connect("test-rpc"); {code} this ends with {code} Exception in thread "main" java.lang.NullPointerException at org.jgroups.protocols.FORK.createForkStack(FORK.java:199) at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:79) at org.teiid.systemmodel.RpcDispatcherTest.start(RpcDispatcherTest.java:32) at org.teiid.systemmodel.RpcDispatcherTest.main(RpcDispatcherTest.java:54 {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5238) [Migration operation] [Web to Undertow] Unable to migrate any valve to handler

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-5238?page=com.atlassian.jira.plugin.... ] ehsavoie Hugonnet reassigned WFLY-5238: --------------------------------------- Assignee: ehsavoie Hugonnet (was: Stuart Douglas) > [Migration operation] [Web to Undertow] Unable to migrate any valve to handler > ------------------------------------------------------------------------------ > > Key: WFLY-5238 > URL: https://issues.jboss.org/browse/WFLY-5238 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Radim Hatlapatka > Assignee: ehsavoie Hugonnet > > In Undertow there are Handlers which can be used similarly as Valves. Some valves have corresponding handler in Undertow. Such valves could be migrated. > E.g. as part of [EAP7-428] there is added {{io.undertow.server.handlers.RequestDumpingHandler}}. > This could be thereby migrated from > {code:xml} > <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false"> > <valve name="request-dumper" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RequestDumperValve"/> > <virtual-server name="default-host" enable-welcome-root="false"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > ... > </subsystem> > {code} > to something like: > {code:xml} > <subsystem xmlns="urn:jboss:domain:undertow:3.0"> > <buffer-cache name="default"/> > <server name="default-server" default-host="default-host"> > <host name="default-host" alias="localhost, example.com"> > <filter-ref name="request-dumper"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > </servlet-container> > <filter name="request-dumper" module="io.undertow.core" class-name="io.undertow.server.handlers.RequestDumpingHandler"/> > ... > </subsystem> > {code} > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5597) Release wildfly-arquillian 1.0.2.Final and use it in WFLY

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5597?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-5597. ------------------------------- Resolution: Done component was upgraded > Release wildfly-arquillian 1.0.2.Final and use it in WFLY > --------------------------------------------------------- > > Key: WFLY-5597 > URL: https://issues.jboss.org/browse/WFLY-5597 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: James Perkins > Priority: Critical > Fix For: 10.0.0.CR5 > > > WildFly should arquillian that has ARQ-1992 fixed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1156) Service changes due to rollback should be completed before operation completes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1156?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1156: ------------------------------------------ [~ehugonnet] I really have no idea what this issue is any more. It was filed against WildFly 8.0.0.Alpha1. I believe the desired behavior implied by the title "Service changes due to rollback should be completed before operation completes" has been present for a real long time now, so perhaps this is just out of date. Or maybe it's just a test coverage thing as the PR is about tests. In which case it's lower priority. > Service changes due to rollback should be completed before operation completes > ------------------------------------------------------------------------------ > > Key: WFCORE-1156 > URL: https://issues.jboss.org/browse/WFCORE-1156 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: ehsavoie Hugonnet > > "As executeAndRollbackOperation() result is retrieved but actual rollback of deployment is is not complete." > That's a bug then. Service changes due to rollback should be completed before the operation returns. > for more details see https://github.com/wildfly/wildfly/pull/4664 > and DeploymentScannerTestCase -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1156) Service changes due to rollback should be completed before operation completes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1156?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1554 to WFCORE-1156: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1156 (was: WFLY-1554) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 8.0.0.Alpha1) > Service changes due to rollback should be completed before operation completes > ------------------------------------------------------------------------------ > > Key: WFCORE-1156 > URL: https://issues.jboss.org/browse/WFCORE-1156 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: ehsavoie Hugonnet > > "As executeAndRollbackOperation() result is retrieved but actual rollback of deployment is is not complete." > That's a bug then. Service changes due to rollback should be completed before the operation returns. > for more details see https://github.com/wildfly/wildfly/pull/4664 > and DeploymentScannerTestCase -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3639) default-web-module doesn't work for non default host

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3639: ------------------------------ Fix Version/s: (was: 10.0.0.CR5) > default-web-module doesn't work for non default host > ---------------------------------------------------- > > Key: WFLY-3639 > URL: https://issues.jboss.org/browse/WFLY-3639 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > If you use config like this: > {code:xml} > <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/> > <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/> > {code} > and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1145: ------------------------------------- >From a security angle, we can create an ephemeral/one-off socket server which is only available during the server-to-host establishment process, using a one-time random token for verification (it could simply be a response type for a "connect back" command in the response protocol described in WFCORE-1147). Not having Remoting in the picture greatly simplifies the security of this connection as well, and has a side benefit that the child servers don't actually need Remoting for anything at all unless they're using it for user stuff. > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1554) Service changes due to rollback should be completed before operation completes

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1554?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-1554: --------------------------------- Assignee: ehsavoie Hugonnet (was: Tomaz Cerar) > Service changes due to rollback should be completed before operation completes > ------------------------------------------------------------------------------ > > Key: WFLY-1554 > URL: https://issues.jboss.org/browse/WFLY-1554 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: ehsavoie Hugonnet > > "As executeAndRollbackOperation() result is retrieved but actual rollback of deployment is is not complete." > That's a bug then. Service changes due to rollback should be completed before the operation returns. > for more details see https://github.com/wildfly/wildfly/pull/4664 > and DeploymentScannerTestCase -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 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 November 2015