It's there in AMX; creating a <system-property> is just
createChild( "system-property", ...);
Lloyd
On Jun 9, 2009, at 10:10 AM, Kedar Mhaswade wrote:
> Anissa,
>
> Ideally, the backend should have an API to create the system property
> (aka token or variable that's substituted) at all the "levels",
> namely:
> - server
> - cluster
> - config
> - domain
> - Java system property,
>
> in the order of decreasing precedence. So, if you don't have that from
> AMX, ask Lloyd to provide it.
>
> Now, assuming you get that API, I would want
> to have an intuitive UI as far as these tokens are concerned. Please
> make
> it as intuitive on the GUI as possible because this is a rather
> difficult
> concept in GlassFish admin and we need all you can do here, to make it
> easy to understand/change. There is no point in making it analogous to
> CLI here, because CLI's capabilities are limited here and I might
> actually
> fix the current problem with it.
>
> Sorry to be direct, but V2's GUI for system properties was
> confusing. So,
> here are my suggestions:
> - Try to publicize these as Variable Substitution or simply, token.
> Calling
> them as system-properties just confuses it beyond comprehension,
> because
> people think that they are Java system properties (-D's) which they
> are not.
>
> - On any property sheet, *detect* that a value represents a token. A
> token is
> always represented as: "^{[^\{\}]+}$". Once you detect that, it
> should be
> possible to see its resolved value, coming from one of the above 5.
> This
> can be done by providing a link next to the text-box that represents
> the unresolved value.
>
> - To create tokens, there should be an intuitive screen that asks for
> name, value and target. The target should be a drop-down.
> Similarly, for
> delete. It is this screen that the link from above bullet point
> links to.
>
> We can talk more about this in your iteam meeting, if you'd like.
> But remember,
> this is our opportunity to fix this for v3.
>
> -Kedar
>
>
>
> Anissa Lam wrote:
>> Thanks Kedar and Sankar for the answer.
>> I am asking because i am working on the UI to support system-
>> properties. In V2, system-properites is shown as a tree-node
>> under configuration, and thus, system-property will be created
>> under <config>. Thats the case for both PE and EE. For EE,
>> each server instance (clusterd & standalone) have a tab to show
>> its system property as well.
>> I want to keep the same layout in v3 as in v2, which means system
>> properties will be under config. However, if user is using the
>> CLI to create/list/delete system-properties, they will NOT be
>> able to see those system property in GUI. Thats the issue.
>> We have 3 options here to align GUI with CLI:
>> 1. leave system-properties under config tree node and have CLI
>> to support creating system-property under <config> and make that
>> the default.
>> 2. leave system-properties under config tree node, and also add a
>> tab for the application server. This tab will show the system
>> property that user works on using CLI.
>> 3. remove system-properties under config and only have the tab for
>> the application server.
>> I am thinking option 2 above. The only disadvantage is that
>> system-property is more visible under config as a tree node, and
>> they may have a hard time finding those property they just created
>> using CLI as it is 'hidden' as a tab in application server.
>> Please let me know what you think.
>> thanks
>> Anissa.
>> Kedar Mhaswade wrote:
>>> Correct.
>>> And for single instance product (i.e. what GFv3 is going to be), the
>>> boundaries between a "server" and its "config" should be as blur
>>> as possible.
>>>
>>> Over the years, I have gathered that, people have difficulties
>>> understanding the
>>> subtle relationship between "server", its "config" and the
>>> reference mechanism.
>>>
>>> -Kedar
>>>
>>> Sankar Neelakandan wrote:
>>>> Hi Anissa,
>>>> There is no other command to create system properties. I guess
>>>> if the --target allows server-config as a valid target then it
>>>> can be created under server-config. Right now the command doesn't
>>>> support server-config as a valid target. Since "server" is the
>>>> only instance using the server-config what other advantage do you
>>>> gain with creating system properties under server-config ?.
>>>>
>>>> thanks
>>>> Sankar
>>>>
>>>> for this command then
>>>>
>>>>
>>>> Anissa Lam wrote:
>>>>> Hi,
>>>>> I have a question regarding the CLI create-system-properties
>>>>> command in v3.
>>>>>
>>>>> NAME
>>>>> create-system-properties - adds or updates one or more
>>>>> system properties of the domain, configuration, cluster, or
>>>>> server instance
>>>>>
>>>>> SYNOPSIS
>>>>> create-system-properties
>>>>> [--terse={true|false}][ --echo={true|false} ]
>>>>> [ --interactive={true|false} ] [ --host host]
>>>>> [--port port] [--secure| -s ] [ --user admin_user]
>>>>> [--passwordfile filename] [--help]
>>>>> [ --target target_name]
>>>>> [name=value)[:name=value]*]
>>>>>
>>>>> This only create the system property under <server>. I can't
>>>>> figure out a way to create it under <server-config>. Can
>>>>> someone help me ?
>>>>> Am i suppose to use another CLI command to create system-
>>>>> property under config ?
>>>>>
>>>>> thanks
>>>>> Anissa.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team