November 2015 - jboss-jira - Jboss List Archives

[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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1966: -------------------------------- Not sure I understand what the issue is. Also, I've never used either JDK logging or sl4j. Can you submit a pull request to fix what you perceive to be the issue? Meanwhile, I'm closing this one, feel free to reopen once you have a PR. > Specify logger name for LogRecord in JDKLogImpl > ----------------------------------------------- > > Key: JGRP-1966 > URL: https://issues.jboss.org/browse/JGRP-1966 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: George Zalizko > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > I use Spring Boot with logback. > For logging I have pattern: > {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code} > And in console I see: > {code} > 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code} > This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger" > Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1966. ---------------------------- Resolution: Won't Fix > Specify logger name for LogRecord in JDKLogImpl > ----------------------------------------------- > > Key: JGRP-1966 > URL: https://issues.jboss.org/browse/JGRP-1966 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: George Zalizko > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > I use Spring Boot with logback. > For logging I have pattern: > {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code} > And in console I see: > {code} > 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code} > This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger" > Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

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

by Christian Heinemann (JIRA)

[ https://issues.jboss.org/browse/WFLY-5699?page=com.atlassian.jira.plugin.... ] Christian Heinemann commented on WFLY-5699: ------------------------------------------- Fix version should be assigned to 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 > > Upgrade to address the serialization exploit -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1990?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1990: -------------------------------- If we do these optimizations, we need to make sure that the wire format doesn't change. Shouldn't be the case anyway, as we're still sending IDs and header, for each header. > Headers: use 1 array rather than 2 > ---------------------------------- > > Key: JGRP-1990 > URL: https://issues.jboss.org/browse/JGRP-1990 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.: > {noformat} > | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n | > {noformat} > This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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