November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2129) Schema generation fails on JDK9

by Radoslav Husar (JIRA)

Radoslav Husar created JGRP-2129: ------------------------------------ Summary: Schema generation fails on JDK9 Key: JGRP-2129 URL: https://issues.jboss.org/browse/JGRP-2129 Project: JGroups Issue Type: Component Upgrade Reporter: Radoslav Husar Assignee: Bela Ban Priority: Minor Not going to be a problem for a while until base is compiled with JDK9 by default, but just in case. {noformat} main: [mkdir] Created dir: /Users/rhusar/git/jgroups/target/schema [java] java.lang.ExceptionInInitializerError [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194) [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771) [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221) [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135) [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108) [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537) [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) [java] at org.apache.tools.ant.Task.perform(Task.java:348) [java] at org.apache.tools.ant.Target.execute(Target.java:390) [java] at org.apache.tools.ant.Target.performTasks(Target.java:411) [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368) [java] at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327) [java] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) [java] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) [java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) [java] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) [java] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) [java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537) [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) [java] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) [java] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) [java] Caused by: java.lang.ExceptionInInitializerError [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:56) [java] at org.jgroups.protocols.ASYM_ENCRYPT.<clinit>(ASYM_ENCRYPT.java:55) [java] at java.lang.Class.forName0(java.base@9-ea/Native Method) [java] at java.lang.Class.forName(java.base@9-ea/Class.java:291) [java] at org.jgroups.util.XMLSchemaGenerator.getClasses(XMLSchemaGenerator.java:127) [java] at org.jgroups.util.XMLSchemaGenerator.generateProtocolSchema(XMLSchemaGenerator.java:106) [java] at org.jgroups.util.XMLSchemaGenerator.main(XMLSchemaGenerator.java:80) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537) [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217) [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152) [java] ... 38 more [java] Caused by: java.lang.NullPointerException [java] at org.jgroups.conf.ClassConfigurator.init(ClassConfigurator.java:229) [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:53) [java] ... 50 more [java] Java Result: -1 {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7555) Upgrade Infinispan to 8.2.5.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7555?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-7049 to WFLY-7555: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7555 (was: JBEAP-7049) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR8) > Upgrade Infinispan to 8.2.5.Final > --------------------------------- > > Key: WFLY-7555 > URL: https://issues.jboss.org/browse/WFLY-7555 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > Version including backports by ISPN-6751. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky commented on WFCORE-1809: ------------------------------------------- We could. But before doing anything about it I would like to see a real customer demand first and address that. This issue was, in fact, inspired by a customer case. The customer was confused and didn't actually realize we didn't patch the configuration. Once that was cleared out, the customer didn't have any requests. So before implementing this feature and taking the responsibility for it, I want to receive an actual customer request. > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Ingo Weiss commented on WFCORE-1809: ------------------------------------ > I actually meant custom config directory locations. But even if you limit it to the files inside the default directory, the user can add/remove/edit them. We can't even assume that any XML file in there is a valid server configuration file. > We neither patch nor update configuration files from the patch tool except optional reset during rollback. Understood. Could we then try and introduce an option where you could specify the configuration(s) to be backed up based on {{$JBOSS_HOME}}? > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ] Alexey Loubyansky commented on WFCORE-1809: ------------------------------------------- > Hold on. When you say configurations you mean all configuration files on that configuration directory, correct? I actually meant custom config directory locations. But even if you limit it to the files inside the default directory, the user can add/remove/edit them. We can't even assume that any XML file in there is a valid server configuration file. > Correct. The server knows the configuration location through jboss.server.config.dir. It would be up to the patching mechanism to look for the remaining .xml files and patch them as needed. We neither patch nor update configuration files from the patch tool except optional reset during rollback. > JBoss CLI patch command doesn't honor custom configuration location > ------------------------------------------------------------------- > > Key: WFCORE-1809 > URL: https://issues.jboss.org/browse/WFCORE-1809 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 3.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7512) Elytron resources runtime updates without reload

by Dmitrii Tikhomirov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7512?page=com.atlassian.jira.plugin.... ] Dmitrii Tikhomirov commented on WFLY-7512: ------------------------------------------ [~darranl] what us your opinion ? should we do that ? > Elytron resources runtime updates without reload > ------------------------------------------------ > > Key: WFLY-7512 > URL: https://issues.jboss.org/browse/WFLY-7512 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Dmitrii Tikhomirov > > When updating elytron resources, server ends up in {{reload-required}} state. For example > {code} > [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Make it possible for all (most - some may be impossible) resources to support runtime updates. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1973) Remove unused org.jboss.as.version.Usage

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-1973: ----------------------------------------- Summary: Remove unused org.jboss.as.version.Usage Key: WFCORE-1973 URL: https://issues.jboss.org/browse/WFCORE-1973 Project: WildFly Core Issue Type: Task Components: Server Affects Versions: 3.0.0.Alpha12 Reporter: Rostislav Svoboda Assignee: Rostislav Svoboda Rostislav Svoboda https://github.com/wildfly/wildfly-core/blob/master/version/src/main/java.... ... a bit old code, but ... 'tooLong = tooLong.substring(0, width-5);' ? Brian Stansberry that whole class is unused and can be removed -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not

by Stefan Lindner (JIRA)

Stefan Lindner created WFLY-7554: ------------------------------------ Summary: Singleton: @AccessTimeout and @Lock on superclass method not Key: WFLY-7554 URL: https://issues.jboss.org/browse/WFLY-7554 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final, 9.0.2.Final Environment: Win7_64, Oracle Java 8/102 Reporter: Stefan Lindner {code:java} @AccessTimeout(value=54321) class MySuperclass { @AccessTimeout(value=1200000000000L) public void whileBlocked() {....} } @Singleton @Startup @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) @DependsOn("BenutzerControllerImpl") @AccessTimeout(value=54321) @Lock(LockType.READ) class MyClass extends MySuperclass { @Lock(LockType.WRITE) public void myBlocker() {....} } {code} Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS The standard says: {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass). {quote} In short: # @AccessTimeout annotations on bean's class or method work as expected # Annotations on superclass do not -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7512) Elytron resources runtime updates without reload

by Dmitrii Tikhomirov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7512?page=com.atlassian.jira.plugin.... ] Dmitrii Tikhomirov reassigned WFLY-7512: ---------------------------------------- Assignee: Dmitrii Tikhomirov > Elytron resources runtime updates without reload > ------------------------------------------------ > > Key: WFLY-7512 > URL: https://issues.jboss.org/browse/WFLY-7512 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Dmitrii Tikhomirov > > When updating elytron resources, server ends up in {{reload-required}} state. For example > {code} > [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Make it possible for all (most - some may be impossible) resources to support runtime updates. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7176) Review x500-attribute-principal-decoder resource in Elytron subsystem

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7176?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7176: ---------------------------------- And where can I found state of stability of resource?? :D > Review x500-attribute-principal-decoder resource in Elytron subsystem > --------------------------------------------------------------------- > > Key: WFLY-7176 > URL: https://issues.jboss.org/browse/WFLY-7176 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 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 November 2016