January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3529) Cleanup capability API

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-3529: ----------------------------------- Summary: Cleanup capability API Key: WFCORE-3529 URL: https://issues.jboss.org/browse/WFCORE-3529 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar We have few deprecated methods and methods that ware there just for binary comparability. we should be able to remove them now. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3528) Detect conflicting packages in deployments

by David Lloyd (JIRA)

David Lloyd created WFCORE-3528: ----------------------------------- Summary: Detect conflicting packages in deployments Key: WFCORE-3528 URL: https://issues.jboss.org/browse/WFCORE-3528 Project: WildFly Core Issue Type: Enhancement Reporter: David Lloyd We should have a deployment processor which detects package conflicts within deployments. It should ensure that no deployment package is exported by any module provided by the application server (the {{ModuleSpecification#getSystemDependencies}} set) (excluding {{META-INF/**}} and the empty package from consideration, and maybe one or two others). The processor could either raise an error, or it could introduce a PathFilter to block the offending packages and print a warning to that effect. We could also add other checks - like warning if the same package is present in more than one archive within the deployment that have visibility to each other, for example - but it's somewhat harder to establish hard rules about these cases that are always correct. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9713) Test suite tests using shrinkwrap are creating many duplicated classes

by David Lloyd (JIRA)

David Lloyd created WFLY-9713: --------------------------------- Summary: Test suite tests using shrinkwrap are creating many duplicated classes Key: WFLY-9713 URL: https://issues.jboss.org/browse/WFLY-9713 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: David Lloyd The test suite uses shrinkwrap rather extensively to generate archives. It seems that there is a lot of fast-and-loose archive generation going on though: in many cases, the same class is being included in multiple archives in the same deployment. The result is that if you change the class loading order so that the deployment loader comes first, you get errors like this: {noformat} Caused by: java.util.ServiceConfigurationError: org.jboss.msc.service.ServiceActivator: Provider org.jboss.as.test.integration.logging.LoggingServiceActivator not a subtype {noformat} Or this: {noformat} org.jboss.as.test.integration.jca.poolattributes.DatasourcePoolAttributesTestCase.testModifyNonReloadAttributes: java.lang.ClassCastException: org.jboss.as.connector.subsystems.datasources.WildFlyDataSource cannot be cast to org.jboss.as.connector.subsystems.datasources.WildFlyDataSource {noformat} This is related to other problems, whose JIRAs I will link presently. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code

by Richard Opalka (JIRA)

Richard Opalka created WFCORE-3527: -------------------------------------- Summary: Remove OSGi obsolete code Key: WFCORE-3527 URL: https://issues.jboss.org/browse/WFCORE-3527 Project: WildFly Core Issue Type: Enhancement Components: Server Affects Versions: 4.0.0.Alpha5 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 4.0.0.Alpha6 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3523) Don't initialize extension parsers on a domain server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3523?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3523 at 1/19/18 11:11 AM: -------------------------------------------------------------------- A simple attempt at this[1] produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth. [1] see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... until I someday delete it was (Author: brian.stansberry): A simple attempt at this (see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... until I someday delete it) produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth. > Don't initialize extension parsers on a domain server > ----------------------------------------------------- > > Key: WFCORE-3523 > URL: https://issues.jboss.org/browse/WFCORE-3523 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3523) Don't initialize extension parsers on a domain server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3523?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3523. -------------------------------------- Resolution: Won't Do A simple attempt at this (see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... until I someday delete it) produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth. > Don't initialize extension parsers on a domain server > ----------------------------------------------------- > > Key: WFCORE-3523 > URL: https://issues.jboss.org/browse/WFCORE-3523 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3524) Attempt to initialize the latest Extension parser if that has been registered are suppliers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3524?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3524: ------------------------------------- Description: The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot. I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added. To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces. See the discussion on https://github.com/wildfly/wildfly-core/pull/3035 was: The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot. I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added. To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces. > Attempt to initialize the latest Extension parser if that has been registered are suppliers > ------------------------------------------------------------------------------------------- > > Key: WFCORE-3524 > URL: https://issues.jboss.org/browse/WFCORE-3524 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot. > I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added. > To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces. > See the discussion on https://github.com/wildfly/wildfly-core/pull/3035 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2 configuration error

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-9708: ---------------------------------- [~mkouba] Yes, it seems so. The only other option might be to manually update the injection module after using the multi-jsf installer so it contains the working version of {{WeldApplication}}. > Wildfly 11.0.0.Final JSF 1.2 configuration error > ------------------------------------------------ > > Key: WFLY-9708 > URL: https://issues.jboss.org/browse/WFLY-9708 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 11.0.0.Final > Reporter: Luis Canales > Priority: Optional > Attachments: log.txt > > > Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersi...) and deploy a JSF1.2 application, I get this error: > _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_ > If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2 configuration error

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.... ] Martin Kouba reassigned WFLY-9708: ---------------------------------- Assignee: (was: Martin Kouba) > Wildfly 11.0.0.Final JSF 1.2 configuration error > ------------------------------------------------ > > Key: WFLY-9708 > URL: https://issues.jboss.org/browse/WFLY-9708 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 11.0.0.Final > Reporter: Luis Canales > Priority: Optional > Attachments: log.txt > > > Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersi...) and deploy a JSF1.2 application, I get this error: > _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_ > If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2246) Internal thread pool not created if default thread pool is injected

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated JGRP-2246: ------------------------------- Description: WildFly injects a custom thread pool into its JGroups transports. However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method. The internal thread pool does not. However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. Can we restore the TP.setInternalThreadPool(...) method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? was: WildFly injects a custom thread pool into its JGroups transports. However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method. The internal thread pool does not. However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. Can we restore the TP.setInternalThreadPool(...) method? > Internal thread pool not created if default thread pool is injected > ------------------------------------------------------------------- > > Key: JGRP-2246 > URL: https://issues.jboss.org/browse/JGRP-2246 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.9 > Reporter: Paul Ferraro > Assignee: Bela Ban > > WildFly injects a custom thread pool into its JGroups transports. However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method. The internal thread pool does not. However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly. > Can we restore the TP.setInternalThreadPool(...) method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018