November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-251) More certain credential based mechanism selection.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-251?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-251: --------------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.Beta2) > More certain credential based mechanism selection. > -------------------------------------------------- > > Key: ELY-251 > URL: https://issues.jboss.org/browse/ELY-251 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta3 > > > When filtering authentication mechanisms we need to really be able to offer two modes: - > 1 - Only offer a mech if we are sure it is supported. > Risks only offering a weaker mechanism in a mixed domain but also eliminates mechanisms that could fail for a valid user that just happens to have a different credential type. > 2- More general support. > i.e. offer the mechs that may be supported. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-208) Update SASL mechanism testing to also be domain backed.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-208?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-208: --------------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.Beta2) > Update SASL mechanism testing to also be domain backed. > ------------------------------------------------------- > > Key: ELY-208 > URL: https://issues.jboss.org/browse/ELY-208 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Kabir Khan > Fix For: 1.1.0.Beta3 > > > There may be a little bit more work required before this is possible but we need to ensure SASL mechanisms are also tested using a CallbackHandler they are likely to encounter which will really be the one from ServerAuthenticationContext. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-358) Wrap all LDAP testing in a single suite

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-358?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-358: --------------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.Beta2) > Wrap all LDAP testing in a single suite > --------------------------------------- > > Key: ELY-358 > URL: https://issues.jboss.org/browse/ELY-358 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta3 > > > If we wrap all these tests in a single suite we can start up the LDAP server one, run all the tests and then stop the server - this will stop us incurring the set-up / tear-down cost for each test case. -- 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)

[ https://issues.jboss.org/browse/ELY-378?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-378. ---------------------------------- Resolution: Done > 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] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1989: ----------------------------------- Now it really just passes the buffer into the queue, but in the past (looking into git history before the NIO stuff) you've copied the buffer there: {code:java} public void send(byte[] data, int offset, int length) throws Exception { if (sender != null) { // we need to copy the byte[] buffer here because the original buffer might get changed meanwhile byte[] tmp = new byte[length]; System.arraycopy(data, offset, tmp, 0, length); sender.addToQueue(tmp); } else _send(data, offset, length, true, true); } {code} So the current state when you allocate the buffer anew is not that worse after all (besides allocating more than you need), because it just moved the invocation to bundler. > 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-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: -------------------------------- TCPConnection.send() only makes a copy if you pass a direct ByteBuffer to it, otherwise it doesn't. Are you referring to code further up the stack? > 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-1989) Bundlers: reuse send buffer when transport == sync.

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1989: ----------------------------------- The data were copied before sending even before, in {{TcpConnection.send}} - will you eliminate this copy, too? > 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] (WFLY-5744) Improve readability of missing dependency logs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5744?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5744: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1283294 Bugzilla Update: Perform > Improve readability of missing dependency logs > ---------------------------------------------- > > Key: WFLY-5744 > URL: https://issues.jboss.org/browse/WFLY-5744 > Project: WildFly > Issue Type: Feature Request > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Dennis Reed > > When there is a problem with a failed deployment due to missing dependencies it is difficult to figure out what the problem is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5744) Improve readability of missing dependency logs

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-5744: ---------------------------------------------- Summary: Improve readability of missing dependency logs Key: WFLY-5744 URL: https://issues.jboss.org/browse/WFLY-5744 Project: WildFly Issue Type: Feature Request Reporter: Bartosz Spyrko-Śmietanko Assignee: Dennis Reed When there is a problem with a failed deployment due to missing dependencies it is difficult to figure out what the problem is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5743) Module org.javassist not excluded when persistence.xml contains property <property name="jboss.as.jpa.providerModule" value="application" />

by Juraj Staník (JIRA)

Juraj Staník created WFLY-5743: ---------------------------------- Summary: Module org.javassist not excluded when persistence.xml contains property <property name="jboss.as.jpa.providerModule" value="application" /> Key: WFLY-5743 URL: https://issues.jboss.org/browse/WFLY-5743 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 9.0.2.Final Environment: OS: Windows 7 JVM: jdk1.7.0_79, WF: wildfly-9.0.2.Final DB: h2 Reporter: Juraj Staník Assignee: David Lloyd Attachments: class-loading-problem.zip Excluding the module 'org.javassit' in the jboss-deployment-structure.xml does not work correctly for all modules in EAR when shipping custom version of Hibernate and Javassist and setting property <property name="jboss.as.jpa.providerModule" value="application" /> in the persistence.xml. In case of the following EAR structure: {noformat} EAR |`-- lib | |`-- javassist-3.20.0-GA.jar | `-- <hibernate 4.2.19 jars> |`-- META-INF | |`-- jboss-deployment-structure.xml | `-- application.xml |`-- EJB-JAR | `-- META-INF | `-- persistence.xml `-- WAR {noformat} and the content of the jboss-deployment-structure.xml {code:title=jboss-deployment-structure.xml|xml} <?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1"> <ear-subdeployments-isolated>false</ear-subdeployments-isolated> <deployment> <exclusions> <module name="org.hibernate" /> <module name="org.javassist" /> </exclusions> </deployment> </jboss-deployment-structure> {code} and persistence.xml {code:title=persistence.xml|xml} <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1"> <persistence-unit name="cce-example" transaction-type="JTA"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>jdbc/CCE_DS</jta-data-source> <properties> <property name="jboss.as.jpa.providerModule" value="application" /> </properties> </persistence-unit> </persistence> {code} The module EJB-JAR loads javassist classes not from the bundled {{EAR/lib/javassist-3.20.0-GA.jar}} but from {{<WF>/modules/system/layers/base/org/javassist/main/javassist-3.18.1-GA.jar}} -- 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