October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3360) Eliminate org.wildfly.extension.elytron.ProviderUtil

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3360: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Eliminate org.wildfly.extension.elytron.ProviderUtil > ---------------------------------------------------- > > Key: WFCORE-3360 > URL: https://issues.jboss.org/browse/WFCORE-3360 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha2 > > > WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3255: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Complex type AttributeDefinition variants don't handle ParameterCorrector properly > ---------------------------------------------------------------------------------- > > Key: WFCORE-3255 > URL: https://issues.jboss.org/browse/WFCORE-3255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha2 > > > If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called. > These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3252) provide better filtering of host-exclude for prior releases

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3252?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3252: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > provide better filtering of host-exclude for prior releases > ----------------------------------------------------------- > > Key: WFCORE-3252 > URL: https://issues.jboss.org/browse/WFCORE-3252 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 4.0.0.Alpha2 > > > Currently a new domain controller connecting to a legacy slave will pass host-exclude values that the HostExcludeResourceDefinition enum on the slave doesn't understand. > WFCORE-3226 provided a simple workaround fix to allow this to work via a transformer, but we should have a better mechanism to only send =< the slave version values from the enum, or something similar perhaps. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3185: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Run parallel boot tasks in coarser grained chunks > ------------------------------------------------- > > Key: WFCORE-3185 > URL: https://issues.jboss.org/browse/WFCORE-3185 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha2 > > > Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete. > The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working. > My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.) > The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem. > Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results. > Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care. > Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3181) Review CustomCredentialSecurityFactoryTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3181: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Review CustomCredentialSecurityFactoryTestCase > ---------------------------------------------- > > Key: WFCORE-3181 > URL: https://issues.jboss.org/browse/WFCORE-3181 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha2 > > > The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'. > The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory. > Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail. > If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3386) Add configuration required to support JASPIC to the Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3386: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Add configuration required to support JASPIC to the Elytron subsystem > --------------------------------------------------------------------- > > Key: WFCORE-3386 > URL: https://issues.jboss.org/browse/WFCORE-3386 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3382) Further Enhance Elytron Permission Configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3382: ------------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) > Further Enhance Elytron Permission Configuration > ------------------------------------------------ > > Key: WFCORE-3382 > URL: https://issues.jboss.org/browse/WFCORE-3382 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha2 > > > This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location. > Finding a way for the default required permissions to be defined in one location could help eliminate the duplication. > We could also consider going one step further and subsystems register the default permissions that should be granted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate

by Alexander Pinske (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin... ] Alexander Pinske commented on JBJCA-1357: ----------------------------------------- Thanks for the clarification! want: JPA-flush JCA-delist commit JPA-close JCA-cleanup have: TM TSR commit TSR TM need: TSR TM commit TSR TM That seems like something that needs to be addressed in the JTA spec, especially now that JPA is going to require the use of TSR.registerSynch. > TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate > ------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1357 > URL: https://issues.jboss.org/browse/JBJCA-1357 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.4.5 > Reporter: Alexander Pinske > Attachments: jca-hibernate.zip > > > The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed. > This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed. > I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR). > http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario. > If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress. > I don't know if my rationale is correct. Could you please comment on the issue? > Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9493) Wildfly 11 SerialVersionUID does not match

by leonardo truccollo (JIRA)

[ https://issues.jboss.org/browse/WFLY-9493?page=com.atlassian.jira.plugin.... ] leonardo truccollo updated WFLY-9493: ------------------------------------- Attachment: Capturar.PNG > Wildfly 11 SerialVersionUID does not match > ------------------------------------------ > > Key: WFLY-9493 > URL: https://issues.jboss.org/browse/WFLY-9493 > Project: WildFly > Issue Type: Feature Request > Components: Application Client > Affects Versions: 11.0.0.Final > Reporter: leonardo truccollo > Assignee: Stuart Douglas > Priority: Critical > Labels: support > Fix For: 10.2.0.Final > > Attachments: Capturar.PNG, image-2017-10-28-16-18-06-831.png > > Original Estimate: 1 day > Remaining Estimate: 1 day > > I'm using wildfly 10.1.0.final in our software with no problems, when migrating to the latest version of wildfly 11 the same project started to appear the error of SerialVersionUID does not match, being that if I turn off the wildfly 11 and re-use the 10 same does not bring any error only in wildfly 11, > the two Servers contain exactly the same compiled build. > This happens every time I update a field in the client, that it goes until the sources make a request. > Something has changed in 11 so that it does not find this parameter, all fonts contain SerialVersionUID = 1L -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9493) Wildfly 11 SerialVersionUID does not match

by leonardo truccollo (JIRA)

[ https://issues.jboss.org/browse/WFLY-9493?page=com.atlassian.jira.plugin.... ] leonardo truccollo reopened WFLY-9493: -------------------------------------- > Wildfly 11 SerialVersionUID does not match > ------------------------------------------ > > Key: WFLY-9493 > URL: https://issues.jboss.org/browse/WFLY-9493 > Project: WildFly > Issue Type: Feature Request > Components: Application Client > Affects Versions: 11.0.0.Final > Reporter: leonardo truccollo > Assignee: Stuart Douglas > Priority: Critical > Labels: support > Fix For: 10.2.0.Final > > Attachments: image-2017-10-28-16-18-06-831.png > > Original Estimate: 1 day > Remaining Estimate: 1 day > > I'm using wildfly 10.1.0.final in our software with no problems, when migrating to the latest version of wildfly 11 the same project started to appear the error of SerialVersionUID does not match, being that if I turn off the wildfly 11 and re-use the 10 same does not bring any error only in wildfly 11, > the two Servers contain exactly the same compiled build. > This happens every time I update a field in the client, that it goes until the sources make a request. > Something has changed in 11 so that it does not find this parameter, all fonts contain SerialVersionUID = 1L -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 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 October 2017