Kedar,
Kedar et al,
Changing to all String has more implications than just the data type.
It means that everything requires two steps.
AMXConfig config = <...any AMXConfig...>;
if ( config.getSomeBoolean() ) { // V2, broken if it's a ${...}
...
}
vs:
AMXConfig config = <...any AMXConfig...>;
if ( TemplateResolverHelper.resolveBoolean( config,
config.getSomeBoolean() ) ) {
...
}
or possibly:
if ( TemplateResolverHelper.resolveBoolean( config, "SomeBoolean" ) ) }
...
}
Keep in mind that the pain is present for *all* attributes, not just
booleans:
String classpath = config.getAbc(); // V2, semi-broken if it's a $
{...}
vs:
String value = TemplateResolverHelper.resolve( config.getAbc() );
In short, our semantics DEMAND that the value *always* has to be
resolved to be of any use. Of course, we could also allow something
like:
SomeAMXConfig rwConfig = <...any AMXConfig...>;
SomeAMXConfig r = ProxyFactory.getReadOnlyResolver( rwConfig );
if ( Boolean.parseBoolean(r.getSomeBoolean()) ) { // still declared as
String, gotta use parseBoolean()
...
}
Is that what we want?
Lloyd
On Apr 21, 2008, at 4:19 PM, Kedar Mhaswade wrote:
> 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
>
>
> ---------------------------------------------------------------------
> 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