November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1166) CompositeTransformer does not transform addresses

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1166?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1166: ------------------------------- Description: If /some=where has a child redirection for the child=* child resource to new-child=*, then {code} { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } {code} gets correctly transformed to {code} { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } {code} But if wrapped in a composite, e.g.: {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} the redirection does not happen in the transformed composite, so we have the original {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} rather than the expected {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } ] } {code} was: If /some=where has a child redirection for the child=* child resource to new-child=*, then {code} { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } {code} gets correctly transformed to {code} { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } {code} But if wrapped in a transformer, e.g.: {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} the redirection does not happen in the transformed composite, so we have the original {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} rather than the expected {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } ] } {code} > CompositeTransformer does not transform addresses > ------------------------------------------------- > > Key: WFCORE-1166 > URL: https://issues.jboss.org/browse/WFCORE-1166 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.3.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > > If /some=where has a child redirection for the child=* child resource to new-child=*, then > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > {code} > gets correctly transformed to > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > {code} > But if wrapped in a composite, e.g.: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > the redirection does not happen in the transformed composite, so we have the original > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > rather than the expected > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > ] > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1166) CompositeTransformer does not transform addresses

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1166?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-2030 to WFCORE-1166: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1166 (was: JBEAP-2030) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Domain Management (was: Domain Management) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.3.Final (was: 7.0.0.ER1) > CompositeTransformer does not transform addresses > ------------------------------------------------- > > Key: WFCORE-1166 > URL: https://issues.jboss.org/browse/WFCORE-1166 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.3.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > > If /some=where has a child redirection for the child=* child resource to new-child=*, then > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > {code} > gets correctly transformed to > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > {code} > But if wrapped in a transformer, e.g.: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > the redirection does not happen in the transformed composite, so we have the original > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > rather than the expected > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > ] > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-378) Release WildFly Elytron 1.1.0.Beta2

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-378: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta2 Key: ELY-378 URL: https://issues.jboss.org/browse/ELY-378 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-35) Notification of outcome from authentication mechanism through to realm.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-35?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse reassigned ELY-35: ----------------------------------- Assignee: David Lloyd > Notification of outcome from authentication mechanism through to realm. > ----------------------------------------------------------------------- > > Key: ELY-35 > URL: https://issues.jboss.org/browse/ELY-35 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta2 > > > Realm implementations may want to track successful / unsuccessful calls. > Note: There may be a better way to consider this so do not take the title too literally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-35) Notification of outcome from authentication mechanism through to realm.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-35?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse resolved ELY-35. --------------------------------- Resolution: Done This is covered by ELY-313 > Notification of outcome from authentication mechanism through to realm. > ----------------------------------------------------------------------- > > Key: ELY-35 > URL: https://issues.jboss.org/browse/ELY-35 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta2 > > > Realm implementations may want to track successful / unsuccessful calls. > Note: There may be a better way to consider this so do not take the title too literally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5725) Attribute "secure" not migrated to Undertow subsystem

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5725?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-5725: ----------------------------------- HttpListenerService#isSecure() method is not used by servlet container to figure out if request is secure or not. it is only used by subsystem itself to implement ConfidentialPortManager that is used to properly do redirects for unsecure-->secure Basically to provide port mapping for <transport-guarantee>CONFIDENTIAL</transport-guarantee> > Attribute "secure" not migrated to Undertow subsystem > ----------------------------------------------------- > > Key: WFLY-5725 > URL: https://issues.jboss.org/browse/WFLY-5725 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: RHEL 7.1 > Reporter: Francesco Marchioni > Assignee: Stuart Douglas > Labels: ea, undertow > > We need to migrate the following EAP 6 configuration from the web subsystem: > <subsystem xmlns="urn:jboss:domain:web:2.1" default-virtual-server="default-host" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="httpconfidential" protocol="HTTP/1.1" scheme="http" socket-binding="httpsecure" secure="true" enabled="true"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > </subsystem> > This configuration uses the *secure="true" * attribute to support the transport-guarantee to CONFIDENTIAL which is required by our applications. (We don't use https in EAP which is configured only on the Apache Web server that serves request to EAP 6) > The configuration has been migrated into EAP 7.0.0 Alpha using the CLI /subsystem=web:migrate command. Although no warnings are shown, the resulting configuration *does not contain the attribute "secure"* : > <subsystem xmlns="urn:jboss:domain:undertow:3.0"> > <buffer-cache name="default"/> > <server name="default-server"> > <http-listener name="http" socket-binding="http"/> > <http-listener name="httpconfidential" socket-binding="httpsecure"/> > <host name="default-host" alias="localhost, example.com"> > <location name="/" handler="welcome-content"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > </servlet-container> > <handlers> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > </subsystem> > Is there any plan to provide backward compatiblity for the secure attribute in EAP 7 ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5699) Upgrade common-collections to 3.2.2

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5699?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-5699: ------------------------------ Fix Version/s: 10.0.0.CR5 > Upgrade common-collections to 3.2.2 > ----------------------------------- > > Key: WFLY-5699 > URL: https://issues.jboss.org/browse/WFLY-5699 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 10.0.0.CR5 > > > Upgrade to address the serialization exploit -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1989: -------------------------------- Another alternative is to always send the reusable buffer and copy at the {{TCP_NIO2}} level *if needed*. For example, if a write of 1000 bytes succeeds than we know that 1000 bytes have been written and the buffer can get reused. If the write returns rc=800, then we know that we still need to write the final 200 bytes. In this case, we could *copy* the bytes in range {{buf[801..1000]}}. I assume that a TCP write would succeed in most cases, so this would not do a lot of copying. Downside: an NIO write is done deep inside JGroups NIO ({{NioConnection}}), so we'd have to let this class somehow know whether or not to copy data. For instance, if a user always provides copied data in the first place, there'd be no need o copy at all. > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1974) Socket factory not set correctly with singleton transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1974?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1974. ---------------------------- Resolution: Won't Fix Dennis, if you have a PR I'll be happy to apply it, but since the shared transport is removed in 4.0, I don't really want to waste time looking into this. > Socket factory not set correctly with singleton transport > --------------------------------------------------------- > > Key: JGRP-1974 > URL: https://issues.jboss.org/browse/JGRP-1974 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.7 > > > When using a singleton transport, the socket factory is not set correctly on startup. > JChannel sets the socket factory down the stack on startup, then starts the stack. > The transport protocol is substituted with a TP.ProtocolAdapter during startup (*after* the socket factory was set), so it still uses its default socket factory, and provides it to all protocols up the stack. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 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 resolved JGRP-1984. ---------------------------- Resolution: Cannot Reproduce Closing this issue as I can't reproduce the problem. Please reopen if you succeed in reproducing the problem. > 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 > > Attachments: RpcForkDispatcherTest.java, tcp-shared.xml > > > 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)

8 years, 5 months

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 November 2015