May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10364) Upgrade Hibernate ORM from 5.1.13 to 5.1.14

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10364?page=com.atlassian.jira.plugin... ] Lin Gao updated WFLY-10364: --------------------------- Labels: downstream_dependency (was: ) > Upgrade Hibernate ORM from 5.1.13 to 5.1.14 > ------------------------------------------- > > Key: WFLY-10364 > URL: https://issues.jboss.org/browse/WFLY-10364 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Lin Gao > Assignee: Lin Gao > Labels: downstream_dependency > > https://github.com/hibernate/hibernate-orm/compare/5.1.13...5.1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10364) Upgrade Hibernate ORM from 5.1.13 to 5.1.14

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10364?page=com.atlassian.jira.plugin... ] Lin Gao moved JBEAP-14727 to WFLY-10364: ---------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-10364 (was: JBEAP-14727) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Fix Version/s: (was: 7.1.3.GA) > Upgrade Hibernate ORM from 5.1.13 to 5.1.14 > ------------------------------------------- > > Key: WFLY-10364 > URL: https://issues.jboss.org/browse/WFLY-10364 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Lin Gao > Assignee: Lin Gao > > https://github.com/hibernate/hibernate-orm/compare/5.1.13...5.1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10256) [JDK9+] shaded client jars with MR overlays do not have defined Multi-Release in Manifest

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10256?page=com.atlassian.jira.plugin... ] Rostislav Svoboda updated WFLY-10256: ------------------------------------- Description: Shaded bin/client/jboss-client.jar should have Manifest entry WFCORE-3835 tracks effort for jboss-cli-client.jar WFCOM-40 tracks effort for WildFly Common ELY-1567 tracks effort for wildfly-elytron-tool jar *Older details* Several jars with MR overlays do not have defined Multi-Release in Manifest Results with WildFly master from 2018-04-18: {code} DistributionTestCase.checkOverlayDirectoryAndManifestEntryForExpectedMRJars:93 The following 4 assertions failed: 1) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 2) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-cli-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 3) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 4) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> {code} According MR JAR Support in JBoss Parent proposal WildFly Common should have Manifest entry * modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar I believe shaded jars should also have Manifest entry * bin/wildfly-elytron-tool.jar * bin/client/jboss-cli-client.jar * bin/client/jboss-client.jar Using https://github.com/jboss-eap-qe/jarest/pull/3/files ++ mvn test -Djarest.input.dir=/Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT was: Shaded client jars should have Manifest entry * bin/client/jboss-cli-client.jar * bin/client/jboss-client.jar WFCOM-40 tracks effort for WildFly Common ELY-1567 tracks effort for wildfly-elytron-tool jar *Full / older details* Several jars with MR overlays do not have defined Multi-Release in Manifest Results with WildFly master from 2018-04-18: {code} DistributionTestCase.checkOverlayDirectoryAndManifestEntryForExpectedMRJars:93 The following 4 assertions failed: 1) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 2) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-cli-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 3) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> 4) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> {code} According MR JAR Support in JBoss Parent proposal WildFly Common should have Manifest entry * modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar I believe shaded jars should also have Manifest entry * bin/wildfly-elytron-tool.jar * bin/client/jboss-cli-client.jar * bin/client/jboss-client.jar Using https://github.com/jboss-eap-qe/jarest/pull/3/files ++ mvn test -Djarest.input.dir=/Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT > [JDK9+] shaded client jars with MR overlays do not have defined Multi-Release in Manifest > ----------------------------------------------------------------------------------------- > > Key: WFLY-10256 > URL: https://issues.jboss.org/browse/WFLY-10256 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 12.0.0.Final > Reporter: Rostislav Svoboda > Assignee: David Lloyd > Priority: Critical > Fix For: 13.0.0.Beta1 > > > Shaded bin/client/jboss-client.jar should have Manifest entry > WFCORE-3835 tracks effort for jboss-cli-client.jar > WFCOM-40 tracks effort for WildFly Common > ELY-1567 tracks effort for wildfly-elytron-tool jar > *Older details* > Several jars with MR overlays do not have defined Multi-Release in Manifest > Results with WildFly master from 2018-04-18: > {code} > DistributionTestCase.checkOverlayDirectoryAndManifestEntryForExpectedMRJars:93 > The following 4 assertions failed: > 1) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 2) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-cli-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 3) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-client.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > 4) [Artifact /Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar is expected to be Multi-Release JAR, jar.isMultiReleaseJar() returns false] expected:<[tru]e> but was:<[fals]e> > at DistributionTestCase.lambda$checkOverlayDirectoryAndManifestEntryForExpectedMRJars$8(DistributionTestCase.java:90) expected:<[tru]e> but was:<[fals]e> > {code} > According MR JAR Support in JBoss Parent proposal WildFly Common should have Manifest entry > * modules/system/layers/base/org/wildfly/common/main/wildfly-common-1.3.1.Final.jar > I believe shaded jars should also have Manifest entry > * bin/wildfly-elytron-tool.jar > * bin/client/jboss-cli-client.jar > * bin/client/jboss-client.jar > Using https://github.com/jboss-eap-qe/jarest/pull/3/files ++ mvn test -Djarest.input.dir=/Users/rsvoboda/git/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3817) Remove usages of deprecated ServiceListeners

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3817?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3817: ------------------------------------- Fix Version/s: 5.0.0.Beta2 (was: 5.0.0.Beta1) > Remove usages of deprecated ServiceListeners > -------------------------------------------- > > Key: WFCORE-3817 > URL: https://issues.jboss.org/browse/WFCORE-3817 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3806) Eliminate code that was using transitive MSC dependencies

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3806?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3806: ------------------------------------- Fix Version/s: 5.0.0.Beta2 (was: 5.0.0.Beta1) > Eliminate code that was using transitive MSC dependencies > --------------------------------------------------------- > > Key: WFCORE-3806 > URL: https://issues.jboss.org/browse/WFCORE-3806 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Beta2 > > > Prior MSC 1.2.8 stability monitors were reporting problems if > some transitive dependency wasn't available. This has changed > since MSC 1.2.8. There is no notion of transitive > dependencies in JBoss MSC anymore. If stability monitor detects > a problem it is always immediate dependency of monitored controller. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Fix Version/s: 5.0.0.Beta2 (was: 5.0.0.Beta1) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 5.0.0.Beta2 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3261) Unignore NotificationSupportImplTestCase.doManyNotificationOrderingWithExecutor

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3261?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3261: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 (was: 3.0.2.Final) > Unignore NotificationSupportImplTestCase.doManyNotificationOrderingWithExecutor > ------------------------------------------------------------------------------- > > Key: WFCORE-3261 > URL: https://issues.jboss.org/browse/WFCORE-3261 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > Priority: Minor > Fix For: 4.0.0.Alpha1 > > > The test is currently ignored: https://github.com/wildfly/wildfly-core/blob/3.0.1.Final/controller/src/t... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3762) OperationDefinition deprecationData is not used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3762?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3762: ------------------------------------- Fix Version/s: (was: 5.0.0.Alpha4) > OperationDefinition deprecationData is not used > ----------------------------------------------- > > Key: WFCORE-3762 > URL: https://issues.jboss.org/browse/WFCORE-3762 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If you configure your OperationDefinition with DeprecationData nothing happens if the operation is invoked. There's no call path that results in anything being logged if the operation is invoked. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3742) management operation to generate provisioning feature specs for managed resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3742?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3742: ------------------------------------- Fix Version/s: 5.0.0.Alpha6 (was: 5.0.0.Beta1) > management operation to generate provisioning feature specs for managed resources > --------------------------------------------------------------------------------- > > Key: WFCORE-3742 > URL: https://issues.jboss.org/browse/WFCORE-3742 > Project: WildFly Core > Issue Type: Task > Components: Management > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 5.0.0.Alpha6 > > > To be able to use Galleon as the provisioning mechanism we need to be able to represent resources in the domain management model as Galleon features, i.e. we need to be able to generate feature spec files for all the resources. The idea is to add a global operation handler which will describe a resource as a Galleon feature (using the ModelNode API) that will later be persisted (by the caller) as a feature spec file. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10363) Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10363?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFCORE-3843 to WFLY-10363: ------------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-10363 (was: WFCORE-3843) Component/s: Build System (was: Server) Affects Version/s: 12.0.0.Final (was: 5.0.0.Alpha7) > Generation of legacy feature pack licenses.xml output varies depending on whether -Pjboss-release is used > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-10363 > URL: https://issues.jboss.org/browse/WFLY-10363 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 12.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The legacy feature pack licenses.xml generation uses the maven-resources-plugin copy-resources goal to copy the core-feature-pack-licenses.xml file from a custom src location to a custom target location, and then runs the licenses-plugin insert-versions goal, using that target file as both an input and an output of that goal. > The problem is using the -Pjboss-release profile causes those executions to occur in a different order. With -Pjboss-release, the copy-resources happens after the insert-versions, removing all effect of the insert-versions. > There are a couple fixes that come to mind. One is moving the copy-resources from prepare-package phase to prepare-resources. The other is dropping the copy-resources altogether and just directly specifying the src file as the input to the insert-versions. > I think I'll go for the latter as the result seems simpler to understand in the future. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 May 2018