-
1. Re: JVM configuration in domain schema
aloubyansky Jul 12, 2010 9:12 AM (in response to brian.stansberry)Ok, I'll make the value optional for system properties.
And I'm fine with renaming jvm-properties. As to the name it could be environment-properties, environment-variables or just 'environment' with 'variable' child elements.
-
2. Re: JVM configuration in domain schema
aloubyansky Jul 14, 2010 12:25 PM (in response to aloubyansky)I've pushed the changes. Here is an example
{code:xml}<jvm>
<heap size="64m" max-size="512m"/>
<stack size="128k"/>
<environment-variables>
<variable name="var1" value="value1"/>
<variable name="var2"/>
</environment-variables>
<system-properties>
<property name="blah" value="blahblah"/>
<property name="justName"/>
</system-properties>
<jvm-options>
<option value="-server"/>
<option value="-ea"/>
</jvm-options>
</jvm>{code}
I've also moved xml examples from 'schema' to 'examples'.
-
3. Re: JVM configuration in domain schema
dmlloyd Jul 14, 2010 1:51 PM (in response to aloubyansky)Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
-
4. Re: JVM configuration in domain schema
trustin Jul 15, 2010 6:10 AM (in response to aloubyansky)Could we make the prepended hyphen in the <option/> tag optional? Or could we make it mandatory? Otherwise an ill-minded guy could put a class name or a piped command there. Just thinking out loud..
Actually, options can have names and values (e.g. -name <value> or --name=<value>) so the current <option/> tag doesn't look just right yet. Since we don't have much control over many JVM options, we could simplify it so that <jvm-options/> have a text?
<jvm-options> -server -ea -XX:foo="option that contains whitespaces" -XX:bar=\"option\ that\ contains\ whitespaces\ and\ quotes\" </jvm-options>
Escaping notation could be borrowed from that of *nix shell scripts.
No matter what we do about how jvm options are specified, we'll have to provide some application level validation to prevent the injection attack (or mistake).
-
5. Re: JVM configuration in domain schema
aloubyansky Jul 15, 2010 8:11 AM (in response to trustin)I personally so far don't see a good reason to come up with a more sophisticated way to specify a JVM option. After all it's just a JVM option. Perhaps, I am missing something but what's wrong with the following?
{code:xml}<option value="
-XX:foo=option that contains whitespaces
"/>{code}Talking about validation of the options, I think if they were specified separately (i.e. each in a separate element, not all in one text content) then it would be easier?
-
6. Re: JVM configuration in domain schema
trustin Jul 15, 2010 8:24 AM (in response to aloubyansky)The point is that the -XX:foo=bar is not a value but a combination of a name and a value (i.e. name: XX:foo, value: bar), hence a little bit of confusion. But I can't think of better attribute name either.
Talking about validation of the options, I think if they were specified separately (i.e. each in a separate element, not all in one text content) then it would be easier?
Yes, indeed. I guess I've gone too far.
One thing to note is that the following option should fail, as you already might have thought about:
<option value="-server -ea"/>"
-
7. Re: JVM configuration in domain schema
aloubyansky Jul 15, 2010 8:52 AM (in response to trustin)Trustin Lee wrote:
The point is that the -XX:foo=bar is not a value but a combination of a name and a value (i.e. name: XX:foo, value: bar), hence a little bit of confusion. But I can't think of better attribute name either.
Would the following be better?
{code:xml}<jvm-options>
<enable option="-server"/>
<enable option="
-XX:foo=bar"/></jvm-options>
{code}Trustin Lee wrote:
<option value="-server -ea"/>"
Should it? I am not sure it should be that strict. Again I maybe wrong but it doesn't seem to me like something people will want abuse on purpose. And even if it's not on purpose, it still doesn't look horrible.
-
8. Re: JVM configuration in domain schema
andy.miller Jul 15, 2010 11:11 AM (in response to dmlloyd)David Lloyd wrote:
Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
I don't understand something here. What is an environment-variable in the schema versus a system-property? The JVM itself calls the -D<name>=<value> a system property as shown in the help:
-D<name>=<value>
set a system propertySome OS platforms don't even have environment variables at all (mainframe comes to mind).
It's difficult to tell from the discussion what's the difference between these two.
-
9. Re: JVM configuration in domain schema
andy.miller Jul 15, 2010 11:16 AM (in response to aloubyansky)Alexey Loubyansky wrote:
Trustin Lee wrote:
The point is that the -XX:foo=bar is not a value but a combination of a name and a value (i.e. name: XX:foo, value: bar), hence a little bit of confusion. But I can't think of better attribute name either.
Would the following be better?
<jvm-options> <enable option="-server"/> <enable option="-XX:foo=bar"/> </jvm-options>
Trustin Lee wrote:
<option value="-server -ea"/>"
Should it? I am not sure it should be that strict. Again I maybe wrong but it doesn't seem to me like something people will want abuse on purpose. And even if it's not on purpose, it still doesn't look horrible.
It seems to me that allowing multiple options to be specified within the single option value tag goes against the schema itself, in that it is an option not options.
-
10. Re: JVM configuration in domain schema
dmlloyd Jul 15, 2010 11:17 AM (in response to andy.miller)Andrig Miller wrote:
David Lloyd wrote:
Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
I don't understand something here. What is an environment-variable in the schema versus a system-property? The JVM itself calls the -D<name>=<value> a system property as shown in the help:
-D<name>=<value>
set a system propertySome OS platforms don't even have environment variables at all (mainframe comes to mind).
It's difficult to tell from the discussion what's the difference between these two.
Every platform has environment variables, as far as ProcessBuilder and System.getenv() is concerned at least (what the actual platform behavior is doesn't really matter much, this stuff is all in the JDK). These are distinct from Java system properties. You'd set environment variables in the case where a specific server needs, for example, a specific "LD_LIBRARY_PATH".
-
11. Re: JVM configuration in domain schema
dmlloyd Jul 15, 2010 11:19 AM (in response to aloubyansky)Alexey Loubyansky wrote:
Trustin Lee wrote:
The point is that the -XX:foo=bar is not a value but a combination of a name and a value (i.e. name: XX:foo, value: bar), hence a little bit of confusion. But I can't think of better attribute name either.
Would the following be better?
<jvm-options> <enable option="-server"/> <enable option="-XX:foo=bar"/> </jvm-options>
Trustin Lee wrote:
<option value="-server -ea"/>"
Should it? I am not sure it should be that strict. Again I maybe wrong but it doesn't seem to me like something people will want abuse on purpose. And even if it's not on purpose, it still doesn't look horrible.
Yes. We should not tokenize these option values. Each one should be a separate element of the process builder argument list. Otherwise it would be impossible to express options with a space in them.
-
12. Re: JVM configuration in domain schema
andy.miller Jul 15, 2010 11:30 AM (in response to dmlloyd)David Lloyd wrote:
Andrig Miller wrote:
David Lloyd wrote:
Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
I don't understand something here. What is an environment-variable in the schema versus a system-property? The JVM itself calls the -D<name>=<value> a system property as shown in the help:
-D<name>=<value>
set a system propertySome OS platforms don't even have environment variables at all (mainframe comes to mind).
It's difficult to tell from the discussion what's the difference between these two.
Every platform has environment variables, as far as ProcessBuilder and System.getenv() is concerned at least (what the actual platform behavior is doesn't really matter much, this stuff is all in the JDK). These are distinct from Java system properties. You'd set environment variables in the case where a specific server needs, for example, a specific "LD_LIBRARY_PATH".
Thanks for the clarification David. Is this really needed though? Maybe I'm just missing something, but can't you just use -Djava.library.path=<path>:<path> to do the same thing, and not even have to have the distinction?
-
13. Re: JVM configuration in domain schema
dmlloyd Jul 15, 2010 11:36 AM (in response to andy.miller)Andrig Miller wrote:
David Lloyd wrote:
Andrig Miller wrote:
David Lloyd wrote:
Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
I don't understand something here. What is an environment-variable in the schema versus a system-property? The JVM itself calls the -D<name>=<value> a system property as shown in the help:
-D<name>=<value>
set a system propertySome OS platforms don't even have environment variables at all (mainframe comes to mind).
It's difficult to tell from the discussion what's the difference between these two.
Every platform has environment variables, as far as ProcessBuilder and System.getenv() is concerned at least (what the actual platform behavior is doesn't really matter much, this stuff is all in the JDK). These are distinct from Java system properties. You'd set environment variables in the case where a specific server needs, for example, a specific "LD_LIBRARY_PATH".
Thanks for the clarification David. Is this really needed though? Maybe I'm just missing something, but can't you just use -Djava.library.path=<path>:<path> to do the same thing, and not even have to have the distinction?
It's not the same thing. In fact with the module system we may not even need java.library.path. What LD_LIBRARY_PATH does is configure ld.so which is important when your native library has transitive dependencies of its own. The java library loader will not be able to find these transitive dependencies because ld.so loads them automatically.
-
14. Re: JVM configuration in domain schema
andy.miller Jul 15, 2010 11:55 AM (in response to dmlloyd)David Lloyd wrote:
Andrig Miller wrote:
David Lloyd wrote:
Andrig Miller wrote:
David Lloyd wrote:
Alexey Loubyansky wrote:
I've pushed the changes. Here is an example
<jvm> <heap size="64m" max-size="512m"/> <stack size="128k"/> <environment-variables> <variable name="var1" value="value1"/> <variable name="var2"/> </environment-variables> <system-properties> <property name="blah" value="blahblah"/> <property name="justName"/> </system-properties> <jvm-options> <option value="-server"/> <option value="-ea"/> </jvm-options> </jvm>
I've also moved xml examples from 'schema' to 'examples'.
Looks great!
I don't understand something here. What is an environment-variable in the schema versus a system-property? The JVM itself calls the -D<name>=<value> a system property as shown in the help:
-D<name>=<value>
set a system propertySome OS platforms don't even have environment variables at all (mainframe comes to mind).
It's difficult to tell from the discussion what's the difference between these two.
Every platform has environment variables, as far as ProcessBuilder and System.getenv() is concerned at least (what the actual platform behavior is doesn't really matter much, this stuff is all in the JDK). These are distinct from Java system properties. You'd set environment variables in the case where a specific server needs, for example, a specific "LD_LIBRARY_PATH".
Thanks for the clarification David. Is this really needed though? Maybe I'm just missing something, but can't you just use -Djava.library.path=<path>:<path> to do the same thing, and not even have to have the distinction?
It's not the same thing. In fact with the module system we may not even need java.library.path. What LD_LIBRARY_PATH does is configure ld.so which is important when your native library has transitive dependencies of its own. The java library loader will not be able to find these transitive dependencies because ld.so loads them automatically.
Ah... That's what I was missing ;-). Sounds good, and thanks.