[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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 updated JGRP-1904:
---------------------------
Description:
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
was:
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.
* 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 messages are sent, the task should not run either
* It should also be possible to trigger the sending programmatically, or via JMX
> 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)
11 years, 7 months
[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 updated JGRP-1904:
---------------------------
Description:
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.
* 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 messages are sent, the task should not run either
* It should also be possible to trigger the sending programmatically, or via JMX
was:
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.
* 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)
* It should also be possible to trigger the sending programmatically, or via JMX
> 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.
> * 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 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)
11 years, 7 months