Lloyd L Chambers wrote:
> Jerome,
>
> Agreed. In V2, we would only substitute values under a <config> or
> <server> (or at least that's my understanding).
>
> But I can't see why any kind of resource or application might not use
> the same facility; after all a resource or application ultimately is
> associated with a <server>, just as a <config> can be referenced by more
> than one server.
>
> I might be missing something here, but in general it seems that anything
> applicable to more than one server would be a valid candidate for
> substitution. Other things, like those applying only to the DAS, would
> have no need.
Ummm. That might not be true. We had a situation where the user wanted to
replace things in classpath and that too DAS's classpath.
Our best bet here is to bite the bullet with having everything as String,
because that is what underlying config's capabilities are. Let's reflect
in public API what is true with config although it makes some constructs
(esp. with booleans) unusable.
>
> Lloyd
>
> On Apr 21, 2008, at 1:31 PM, Jerome Dochez wrote:
>> I wonder how can we define the boundary between substitutable and not
>> ? In theory, wouldn't we all attribute to be able to be substituted
>> under certain conditions at a customer site.
>>
>> I guess I am asking, do you have a good definition of an attribute
>> that can never be substituted ?
>>
>> jerome
>>
>>
>> On Apr 21, 2008, at 12:49 PM, Lloyd L Chambers wrote:
>>
>>> Jerome et al,
>>>
>>> We should have a discussion on where such substitutions are
>>> allowed...everywhere? Under certain elements only?
>>>
>>> It would be unfortunate to force all types to 'String' in AMX even
>>> when the substitution is not allowed.
>>>
>>> Lloyd
>>>
>>> On Apr 19, 2008, at 10:08 PM, Jerome Dochez wrote:
>>>>
>>>> On Apr 18, 2008, at 8:06 PM, Byron Nevins wrote:
>>>>
>>>>> Every config item automatically goes through the Translation
>>>>> class. So, e.g., all the injections are substituted.
>>>>> Using System Properties exclusively is unfortunate. But we can
>>>>> rectify that now that the D&P show is done...
>>>> right, we need to change this to stop relying on system properties,
>>>> there is a need to get system wide properties from a central
>>>> facility that can be fed from several sources (domain.xml, system
>>>> properties, etc...). ServerEnvironment would be my best guess here...
>>>>
>>>> let's plan for this after TP2.
>>>>
>>>> jerome
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lloyd L Chambers wrote:
>>>>>> Byron,
>>>>>>
>>>>>> Thanks. To my knowledge, there is no documentation as to how this
>>>>>> is specified to work. We should settle on something and make sure
>>>>>> it's implemented that way (eg we need an asarch meeting, etc).
>>>>>>
>>>>>> In my view, the substitution should be more widely available, or
>>>>>> made very explicit.
>>>>>>
>>>>>> Lloyd
>>>>>>
>>>>>> On Apr 18, 2008, at 3:15 PM, Byron Nevins wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Lloyd L Chambers wrote:
>>>>>>>> I'm hoping someone has extant knowledge about how our
>>>>>>>> variable-subsitution works.
>>>>>>>>
>>>>>>>> If a domain.xml attribute has a value like
>>>>>>>> ${com.sun.aas.installRoot} or ${foo.bar}, what is the algorithm
>>>>>>>> for resolving that to an actual value? (And where is the code
>>>>>>>> that does it?)
>>>>>>> org.glassfish.config.support.TranslatedConfigView
>>>>>>>> My assumption is that the algorithm looks for values in this
>>>>>>>> order, but I might be mistakeN:
>>>>>>>>
>>>>>>>> 1. System.getProperty( "com.sun.aas.installRoot" )
>>>>>>>>
>>>>>>>> 2. a <system-property name="com.sun.aas.installRoot "
>>>>>>>> value=..."> in an enclosing scope (eg <config> or <server> or
>>>>>>>> <domain>.
>>>>>>>>
>>>>>>> com.sun.enterprise.v3.server.SystemTasks
>>>>>>>> Right? Wrong? Something else also?
>>>>>>> Right. Wrong. SystemTasks looks in <server> and <config>. It
>>>>>>> does not look in <domain>. Should it?
>>>>>>>
>>>>>>> It does it in a non-ideal way -- it sets the <system-property>'s
>>>>>>> in d.x to System Properties
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Lloyd L Chambers
>>>>>>>> lloyd.chambers_at_sun.com
>>>>>>>> Sun Microsystems, Inc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell
>>>>>>> 650-784-4123 - Sun Microsystems, Inc.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Lloyd L Chambers
>>>>>> lloyd.chambers_at_sun.com
>>>>>> Sun Microsystems, Inc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> --
>>>>> Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell
>>>>> 650-784-4123 - Sun Microsystems, Inc.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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 L Chambers
>>> lloyd.chambers_at_sun.com
>>> Sun Microsystems, Inc
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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 L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>