[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-306:
-----------------------------------------
This task should wait until we switch to the new file system security realm by default - once we switch to that realm updates can be performed using management operations so it will make more sense to be a part of the CLI especially where we can embed the server in the CLI.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-306:
----------------------------------
Assignee: Jean-Francois Denise (was: Darran Lofthouse)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-306:
------------------------------------
Assigning to [~jdenise] as he has reworked CLI to be more plugalabe by custom commands.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1010) standalone.sh hard codes boot log
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1010?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1010.
-------------------------------
Fix Version/s: 2.2.0.Final
Resolution: Out of Date
> standalone.sh hard codes boot log
> ---------------------------------
>
> Key: WFCORE-1010
> URL: https://issues.jboss.org/browse/WFCORE-1010
> Project: WildFly Core
> Issue Type: Patch
> Components: Scripts
> Reporter: Philippe Marschall
> Assignee: James Perkins
> Fix For: 2.2.0.Final
>
>
> The {{standalone.sh}} file hard codes the {{org.jboss.boot.log.file}} property to {{server.log}}. This is inconvenient because it overrides the dynamic configuration in {{logging.properties}} which is set to ${org.jboss.boot.log.file:boot.log}. Maybe the value in logging.properties should instead default to {{server.log}}.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-643) On Windows, setting the JAVA_OPTS variable is not
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-643?page=com.atlassian.jira.plugin... ]
Tomaz Cerar closed WFCORE-643.
------------------------------
Fix Version/s: 2.2.0.Final
Resolution: Out of Date
> On Windows, setting the JAVA_OPTS variable is not
> -------------------------------------------------
>
> Key: WFCORE-643
> URL: https://issues.jboss.org/browse/WFCORE-643
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 1.0.0.Beta4
> Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
> Hardware specs:
> CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
> RAM: 16.0 GB
> GPU: NVIDIA Quadro K1000M
> Others upon request.
> Reporter: Tom Kelley
> Priority: Minor
> Fix For: 2.2.0.Final
>
>
> {warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn}
> My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this:
> {code}
> @rem Delete current log file
> del /F /Q ..\standalone\log\server.log
> @rem Set Java Opts because I want to
> set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
> @rem Set the new Java Home
> set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
> @rem Run Jboss
> standalone.bat -c=standalone-full.xml --debug
> {code}
> I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x%JAVA_OPTS%" == "x" (
> echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
> goto JAVA_OPTS_SET
> )
> {code}
> This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x"%JAVA_OPTS% == "x" (
> echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
> goto JAVA_OPTS_SET
> )
> {code}
> You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own.
> As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this:
> {code}
> Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
> "JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
> JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
> JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> ===============================================================================
> Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
> {code}
> The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-...], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things:
> 1. Maven clean
> 2. Call build.bat
> 3. Set a JAVA_OPTS system variable
> 4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
> I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1389) Align domain.sh and standalone.sh logic about adding -server
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1389?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1389.
-------------------------------
Fix Version/s: 2.2.0.Final
Resolution: Out of Date
> Align domain.sh and standalone.sh logic about adding -server
> ------------------------------------------------------------
>
> Key: WFCORE-1389
> URL: https://issues.jboss.org/browse/WFCORE-1389
> Project: WildFly Core
> Issue Type: Task
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 2.2.0.Final
>
>
> The domain.sh script has a number of JVM vendor checks it uses to decide whether to add -server to the jvm launch command. In standalone.sh it's simpler; it simply checks for OSX.
> I can't see any reason this logic should be significantly different between the two cases, either the JVM vendor checks are needed in both or they aren't needed in either.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months