December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFCORE-296: ------------------------------------ Ah I didn't see that one. Thanks, you're way ahead of me. > Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-296 > URL: https://issues.jboss.org/browse/WFCORE-296 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > From [~dmlloyd] > {quote} > When we have multi-layer protocol going on, the URI scheme we should use > is like this: > outer+middle+inner:// > {quote} > Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > The existing schemes will be needed for backwards compatibility but somehow deprecated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2456: ---------------------------------------- Please use the forums for your questions not Jira. > Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found" > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-2456 > URL: https://issues.jboss.org/browse/WFLY-2456 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user. > c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat > What type of user do you wish to add? > a) Management User (mgmt-users.properties) > b) Application User (application-users.properties) > (a): a > * Error * > JBAS015234: No mgmt-groups.properties files found. > Press any key to continue . . . > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME% > C:\usr\local\wildfly-8.0.0.Beta1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME% > C:\java\jdk1.7.0_45 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME% > C:\usr\local\Maven\3.1.1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version > Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2 > 2-0400) > Maven home: C:\usr\local\Maven\3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: C:\java\jdk1.7.0_45\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" > c:\usr\local\wildfly-8.0.0.Beta1\bin> -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1521) Deployment runtime-name is not being handled properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1521?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1521: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 964446|https://bugzilla.redhat.com/show_bug.cgi?id=964446] from ON_QA to VERIFIED > Deployment runtime-name is not being handled properly > ----------------------------------------------------- > > Key: WFLY-1521 > URL: https://issues.jboss.org/browse/WFLY-1521 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 8.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.0.0.Alpha4 > > > In case archive is deployed with runtime name that does not match archive name, it breaks CLI/GUI commands. > [standalone@localhost:9999 /] deploy --runtime-name=nnn.ear /home/baranowb/redhat/git/jboss-as-quickstart/ejb-in-ear/ear/target/jboss-as-ejb-in-ear-ear-xxxx.ear > [standalone@localhost:9999 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear/subdeployment=jboss-as-ejb-in-ear-ejb.jar/subsystem=ejb3/stateful-session-bean=GreeterEJB:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > 14:05:23,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014612: Operation ("read-attribute") failed - address: ([ > ("deployment" => "jboss-as-ejb-in-ear-ear-xxxx.ear"), > ("subdeployment" => "jboss-as-ejb-in-ear-ejb.jar"), > ("subsystem" => "ejb3"), > ("stateful-session-bean" => "GreeterEJB") > ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."jboss-as-ejb-in-ear-ear-xxxx.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START not found > at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:448) [jboss-msc-1.0.4.GA.jar:1.0.4.GA] > at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [jboss-as-controller-7.2.2-internal-SNAPSHOT.jar:7.2.2-internal-SNAPSHOT] > at org.jboss.as.ejb3.subsystem.deployment.AbstractRuntimeMetricsHandler.executeRuntimeStep(AbstractRuntimeMetricsHandler.java:69) > at > .... > However some seem unaffected: > [standalone@localhost:9990 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear:read-resource > { > "outcome" => "success", > "result" => { > "content" => [{"hash" => bytes { > 0x5c, 0x22, 0x14, 0x99, 0xff, 0x23, 0x45, 0xfc, > 0x15, 0xaf, 0x1b, 0x97, 0x8c, 0x14, 0x75, 0x06, > 0xa2, 0xeb, 0xfb, 0x58 > }}], > "enabled" => true, > "name" => "jboss-as-ejb-in-ear-ear-xxxx.ear", > "persistent" => true, > "runtime-name" => "nnn.ear", > "subsystem" => undefined, > "subdeployment" => { > "jboss-as-ejb-in-ear-web.war" => undefined, > "jboss-as-ejb-in-ear-ejb.jar" => undefined > } > } > } > [standalone@localhost:9990 /] -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-859) Authentication failure due to a login module misconfiguration is not reported if principal is null

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-859?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-859: -------------------------------------------------- Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 927064|https://bugzilla.redhat.com/show_bug.cgi?id=927064] from ON_QA to ASSIGNED > Authentication failure due to a login module misconfiguration is not reported if principal is null > -------------------------------------------------------------------------------------------------- > > Key: SECURITY-859 > URL: https://issues.jboss.org/browse/SECURITY-859 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5 > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_1_0.Beta1, PicketBox_4_9_0.Beta3 > > > Any misconfiguration of a login module leading to authentication failure used to be reported at trace level for anonymous user (principal == null) until SECURITY-660. Right now it is reported at debug level, but only if principal != null. > I am going to propose a fix to report the cause of such a failure at debug level despite the principal value. So that customers can see for example "javax.security.auth.login.LoginException: unable to find LoginModule class: ..." in their logs instead of "PBOX000016: Access denied" only. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"

by Vishal Sharma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ] Vishal Sharma commented on WFLY-2456: ------------------------------------- Did you get an answer for this? I also ran into the same problem even though I am running as an administrator or using sudo to run the add-user command. > Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found" > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-2456 > URL: https://issues.jboss.org/browse/WFLY-2456 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user. > c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat > What type of user do you wish to add? > a) Management User (mgmt-users.properties) > b) Application User (application-users.properties) > (a): a > * Error * > JBAS015234: No mgmt-groups.properties files found. > Press any key to continue . . . > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME% > C:\usr\local\wildfly-8.0.0.Beta1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME% > C:\java\jdk1.7.0_45 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME% > C:\usr\local\Maven\3.1.1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version > Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2 > 2-0400) > Maven home: C:\usr\local\Maven\3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: C:\java\jdk1.7.0_45\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" > c:\usr\local\wildfly-8.0.0.Beta1\bin> -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1904. ---------------------------- Resolution: Done Added attribute resend_last_seqno (default: false) > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > ** {{xmit_interval}} can be reused as interval > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > ** When the current seqno hasn't changed for N times, don't send the highest seqno > * When messages are sent, the task should not run either > * It should also be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-670) Using "attribute" tag causes injection of null values

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-670?page=com.atlassian.jira.plugin.s... ] Tomasz Adamski reopened WFLY-670: --------------------------------- > Using "attribute" tag causes injection of null values > ----------------------------------------------------- > > Key: WFLY-670 > URL: https://issues.jboss.org/browse/WFLY-670 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Assignee: Tomasz Adamski > Priority: Minor > Fix For: Awaiting Volunteers > > > Using "attribute" tag in "jboss-service.xml" in a SAR archive causes injection of null values. Even if your code can handle this it makes it impossible to use primitive datatypes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-670) Using "attribute" tag causes injection of null values

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/WFLY-670?page=com.atlassian.jira.plugin.s... ] Darryl Miles commented on WFLY-670: ----------------------------------- Is this behavior by specification? Can you cite the chapter/section (so it is clear to others what they are doing wrong) ? If not mandated by specification, please get it put into the specification, or better: Surely when injecting a primitive or a well-known immutable type, the setter should be skipped on undeployment, since no memory leak can occur. What if @NotNull is annotated for the property ? Does it obey validation requirements ? Even better liaise with the JMX specification and use annotation @PreDestroy for any actions on undeploy, where no @PreDestroy exists have some default behaviour mandated by specification, if @PreDestroy exists the container does not call any setter during undeploy ? > Using "attribute" tag causes injection of null values > ----------------------------------------------------- > > Key: WFLY-670 > URL: https://issues.jboss.org/browse/WFLY-670 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Assignee: Tomasz Adamski > Priority: Minor > Fix For: Awaiting Volunteers > > > Using "attribute" tag in "jboss-service.xml" in a SAR archive causes injection of null values. Even if your code can handle this it makes it impossible to use primitive datatypes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4081) Do not force that the exploded directory ends with ".war"

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/WFLY-4081?page=com.atlassian.jira.plugin.... ] Geoffrey De Smet commented on WFLY-4081: ---------------------------------------- Submitted an issue to IntelliJ's tracker: https://youtrack.jetbrains.com/issue/IDEA-133729 Please vote that one up :) > Do not force that the exploded directory ends with ".war" > --------------------------------------------------------- > > Key: WFLY-4081 > URL: https://issues.jboss.org/browse/WFLY-4081 > Project: WildFly > Issue Type: Enhancement > Reporter: Geoffrey De Smet > Assignee: Jason Greene > > In a standard webapp, maven creates the following directory and file: > // Exploded directory > target/mywebapp-1.0/ > // War file > target/mywebapp-1.0.war > *Unfortunately, WildFly forces that exploded directories should have the suffix ".war"*. At least the IntelliJ JBoss app server plugin enforces this, if that's no longer the case, they should fix it asap. This has 2 side effects: > 1) Every noob fails to deploy an exploded dir to WildFly in IntelliJ. By the time they realize that it's because they haven't adjusted the exploded artifact's output path, they're already using Jetty or Tomcat (which "just work" in IntelliJ). > 2) As a result, maven and IntelliJ are potentially incompatible for WildFly: > If you just suffix the exploded directory with ".war", the exploded directory clashes with maven's war file. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from POST to MODIFIED > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014