Hi Kedar,
Thanks for suggestion. I understand system properties is one of the
area that needs improvement in GUI. I will think about this and get
input from our HIE person as well.
Our usual iteam is on Tues (today) at 2pm, you are welcome to join.
thanks
Anissa
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
>