July 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-10199?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFLY-10199: ------------------------------------------------ Sandro Bonazzola <sbonazzo(a)redhat.com> changed the Status of [bug 1550120|https://bugzilla.redhat.com/show_bug.cgi?id=1550120] from VERIFIED to CLOSED > Using jboss-modules loading outside WildFly 12 is broken > -------------------------------------------------------- > > Key: WFLY-10199 > URL: https://issues.jboss.org/browse/WFLY-10199 > Project: WildFly > Issue Type: Bug > Affects Versions: 12.0.0.Final > Reporter: Martin Perina > Assignee: David Lloyd > > oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11: > {code} > export JAVA_MODULEPATH="<PATH TO OUR MODULES>" > exec "${JAVA_HOME}/bin/java" \ > -jar "${JBOSS_HOME}/jboss-modules.jar" \ > -dependencies org.ovirt.engine.core.tools \ > -class org.ovirt.engine.core.cryptotool.Main \ > "$@" > {code} > where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool. > When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception: > {code} > Exception in thread "main" java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:460) > at java.util.Properties.setProperty(Properties.java:166) > at java.lang.System.setProperty(System.java:796) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.modules.Main.main(Main.java:390) > {code} > When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error: > {code} > org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools > at org.jboss.modules.Module.addPaths(Module.java:1221) > at org.jboss.modules.Module.link(Module.java:1577) > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296) > at org.jboss.modules.Main.main(Main.java:426) > {code} > I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions? > Thanks > Martin -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-281) Upgrade Clusters to OpenShift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-281?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-281: ----------------------------------------------- Guide to update it: https://docs.openshift.com/container-platform/3.10/upgrading/automated_up... > Upgrade Clusters to OpenShift 3.10 > ---------------------------------- > > Key: SWSQE-281 > URL: https://issues.jboss.org/browse/SWSQE-281 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Update Clusters to Openshift 3.10 in order to match Istio 1.0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-281) Upgrade Clusters to OpenShift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-281?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-281: ----------------------------------------------- Faced some bugs on the upgrade process Bugs Related: - https://bugzilla.redhat.com/show_bug.cgi?id=1576088 - https://bugzilla.redhat.com/show_bug.cgi?id=1575822 - https://bugzilla.redhat.com/show_bug.cgi?id=1575507 - https://bugzilla.redhat.com/show_bug.cgi?id=1579676 Solutions: - https://access.redhat.com/solutions/3547831 Errata: -https://access.redhat.com/errata/RHBA-2018:1816 > Upgrade Clusters to OpenShift 3.10 > ---------------------------------- > > Key: SWSQE-281 > URL: https://issues.jboss.org/browse/SWSQE-281 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Update Clusters to Openshift 3.10 in order to match Istio 1.0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3891: --------------------------------------- When using a {{formatter}} attribute a default {{org.jboss.logmanager.formatters.PatternFormatter}} is created with it's configuration name being the same as the handler. For these cases a unique name should be generated so it doesn't conflict with a possible name of another formatter. > Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3891 > URL: https://issues.jboss.org/browse/WFCORE-3891 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Nikoleta Žiaková > Assignee: James Perkins > > When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails: > {code} > [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log}) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"", > "rolled-back" => true > } > {code} > Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails: > {code} > [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log}) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"", > "rolled-back" => true > } > {code} > The same scenario works for e.g. {{pattern-formatter}}: > {code} > [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log}) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add > {"outcome" => "success"} > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3797) Logging Subsystem test failures on IBM jdk

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3797?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3797: --------------------------------------- It looks like the IBM implementation of the {{java.lang.management.ManagementFactory.getRuntimeMXBean()}} instantiates a logger via the {{NotificationBroadcasterSupport}} in the {{com.ibm.lang.management.internal.ExtendedRuntimeMXBeanImpl}} implementation. This causes the log manager to be accessed before the system property is set. The {{org.apache.maven.surefire.booter.ForkedBooter}} is what invokes the {{ManagementFactory.getRuntimeMXBean()}}. The workaround would be to put set the property on the surefire {{<argLine/>}} as well as add the jboss-logmanager to the boot class path. This does seem to produce an odd message indicating: {code} [WARNING] ForkStarter IOException: 132 INFO [org.jboss.msc] JBoss MSC version 1.4.2.Final 173 INFO [org.jboss.threads] JBoss Threads version 2.3.2.Final. See the dump file /home/jperkins/projects/jboss/wildfly/wildfly-core/logging/target/surefire-reports/2018-07-31T15-47-10_865-jvmRun1.dumpstream {code} The file contains: {code} ForkStarter IOException: 849 INFO [org.jboss.msc] JBoss MSC version 1.4.2.Final 890 INFO [org.jboss.threads] JBoss Threads version 2.3.2.Final. org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException: 849 INFO [org.jboss.msc] JBoss MSC version 1.4.2.Final 890 INFO [org.jboss.threads] JBoss Threads version 2.3.2.Final at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.<init>(ThreadedStreamConsumer.java:58) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.<init>(ThreadedStreamConsumer.java:110) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:596) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:868) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290) at org.apache.maven.cli.MavenCli.main(MavenCli.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) {code} This still seems to report success and failures correctly so it seems the workaround should be suitable. > Logging Subsystem test failures on IBM jdk > ------------------------------------------ > > Key: WFCORE-3797 > URL: https://issues.jboss.org/browse/WFCORE-3797 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 5.0.0.Alpha1, 5.0.0.Alpha2, 5.0.0.Alpha3, 5.0.0.Alpha4 > Environment: {noformat} > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) > Maven home: /usr/lib/maven > Java version: 1.8.0_161, vendor: IBM Corporation > Java home: /usr/lib/java/ibm-java-8.0-5.11/jre > {noformat} > Reporter: Petr Kremensky > Assignee: James Perkins > > WildFly: Logging Subsystem unit tests fails on IBM jdk with: > {noformat} > java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager" > at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:168) > at org.jboss.as.subsystem.test.TestModelControllerService.preBoot(TestModelControllerService.java:158) > at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:264) > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:419) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372) > at java.lang.Thread.run(Thread.java:811) > {noformat} > The test works fine with *4.0.0.Final*, starts failing in *5.0.0.Alpha1*. > This doens't look like a functional issue to me as I was able to workaround the issue by either running the test with the older surefire instance ( -Dversion.surefire.plugin=2.19 is the last working ) or by extending {{surefire.system.args}} in pom.xml with {{-Djava.util.logging.manager=org.jboss.logmanager.LogManager}}. The other however produces the following warnings upon test execution > {noformat} > ... > [WARNING] The system property java.util.logging.manager is configured twice! The property appears in <argLine/> and any of <systemPropertyVariables/>, <systemProperties/> or user property. > [INFO] > [INFO] ------------------------------------------------------- > [INFO] T E S T S > [INFO] ------------------------------------------------------- > [INFO] Running org.jboss.as.logging.HandlerLegacyOperationsTestCase > [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /home/pkremens/devel/wildfly-core/logging/target/surefire-reports/2018-05-03T13-49-32_779-jvmRun1.dumpstream > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-75) it's not possible to enable Hibernate Bytecode Transformer using j-d-s.xml

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFWIP-75?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on WFWIP-75: ----------------------------------- Currently, we can use the globally with system property -DHibernate51CompatibilityTransformer=true or the j-d-s.xml, I'm not sure if it is safe to enable the transformer via both options at the same time, which is why I started working on the [https://github.com/scottmarlow/wildfly/tree/WFLY-10520_pr_hack_Transforme...] change. > it's not possible to enable Hibernate Bytecode Transformer using j-d-s.xml > -------------------------------------------------------------------------- > > Key: WFWIP-75 > URL: https://issues.jboss.org/browse/WFWIP-75 > Project: WildFly WIP > Issue Type: Bug > Components: JPA > Reporter: Martin Simka > Assignee: Scott Marlow > Priority: Blocker > > based on testing with https://github.com/scottmarlow/wildfly/tree/WFLY-10520_pr_hack > it's not possible to enable transformer for application in {{jboss-deployment-structure.xml}}. > there are probably more issues > # application has to have dependency on module {{org.hibernate.bytecodetransfomer}} (which is ok, users must edit j-d-s.xml anyway) / or {{org.hibernate.bytecodetransfomer}} must be global module > # transformer has private constructor so {{ClassFileTransformerProcessor}} cannot instantiate it -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-75) it's not possible to enable Hibernate Bytecode Transformer using j-d-s.xml

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFWIP-75?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on WFWIP-75: ----------------------------------- https://github.com/scottmarlow/wildfly/tree/WFLY-10520_pr_hack_Transforme... contains an attempt to add a marker interface but it fails the test so must be missing something. > it's not possible to enable Hibernate Bytecode Transformer using j-d-s.xml > -------------------------------------------------------------------------- > > Key: WFWIP-75 > URL: https://issues.jboss.org/browse/WFWIP-75 > Project: WildFly WIP > Issue Type: Bug > Components: JPA > Reporter: Martin Simka > Assignee: Scott Marlow > Priority: Blocker > > based on testing with https://github.com/scottmarlow/wildfly/tree/WFLY-10520_pr_hack > it's not possible to enable transformer for application in {{jboss-deployment-structure.xml}}. > there are probably more issues > # application has to have dependency on module {{org.hibernate.bytecodetransfomer}} (which is ok, users must edit j-d-s.xml anyway) / or {{org.hibernate.bytecodetransfomer}} must be global module > # transformer has private constructor so {{ClassFileTransformerProcessor}} cannot instantiate it -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2811) Enrich FEEL Test parameter for translation mode

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2811?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-2811: ----------------------------------- Description: Currently @parametrized test make it difficult to execute both in AST-interpreted Vs Java-Translated mode, because Parameters are used both for Data and Configuration. It would be advisable to use Parameters only for configuration, and split data in different Test-Methods instead, also to make it easier to execute a specific, single test without having to rely to much on IDE toolings. The scope of this however is to start introduce an additional Configuration parameter automatically, so to execute the test in two mode, AST first and then execute all test again in Java mode > Enrich FEEL Test parameter for translation mode > ----------------------------------------------- > > Key: DROOLS-2811 > URL: https://issues.jboss.org/browse/DROOLS-2811 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Currently @parametrized test make it difficult to execute both in AST-interpreted Vs Java-Translated mode, because Parameters are used both for Data and Configuration. > It would be advisable to use Parameters only for configuration, and split data in different Test-Methods instead, also to make it easier to execute a specific, single test without having to rely to much on IDE toolings. > The scope of this however is to start introduce an additional Configuration parameter automatically, so to execute the test in two mode, AST first and then execute all test again in Java mode -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-351) Update B16 to Openshift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-351?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-351: ------------------------------------------ Summary: Update B16 to Openshift 3.10 (was: Update B18 to Openshift 3.10) Team: (was: Infrastructure) - Openshift 3.10 has changed a lot - comparing to openshift 3.9 > Update B16 to Openshift 3.10 > ---------------------------- > > Key: SWSQE-351 > URL: https://issues.jboss.org/browse/SWSQE-351 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2811) Enrich FEEL Test parameter for translation mode

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2811?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-2811: ----------------------------------- Tester: Tibor Zimányi > Enrich FEEL Test parameter for translation mode > ----------------------------------------------- > > Key: DROOLS-2811 > URL: https://issues.jboss.org/browse/DROOLS-2811 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 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 July 2018