Tom,
As you alluded to earlier, I think, we will need to be a little
cautious in how we deal with this. There are probably various aspects
of server behavior that, up until now, have been grouped into "DAS"
vs. "non-DAS." Various bits of code which use xxx.isDas() or other
techniques might actually be interested in different of these aspects.
For example, is this server capable of deploying an app? While in the
past only the DAS could do that, there could be ways in which that is
relaxed going forward so non-DAS servers might be able deploy apps -
although perhaps only to themselves rather than to the whole domain.
So, in fact, perhaps some piece of code really needs to distinguish
between "can deploy to domain" vs. "can deploy only to self."
Ideally, we'd understand at each bit of code precisely what
characteristic of DAS-ness or non-DAS-ness the code was really
interested in and then expose that in some coherent way, whether it's
on ServerEnvironment or in some other way.
- Tim
On Apr 21, 2011, at 3:09 PM, Hong Zhang wrote:
> Hi, Tom
> We have been using ServerEnvironment.isDas API, the underlying
> implementation is checking the server type.
>
> - Hong
>
> On 4/21/2011 3:57 PM, Tom Mueller wrote:
>> I've been looking into how a DAS determines that it's a DAS, and
>> I'm seeing some different approaches:
>>
>> 1. Calling Server.isDas() - this method looks at the instance name;
>> if it's "server" then return true.
>>
>> 2. Using the "-type" argument that is passed when the JVM is
>> launched. start-domain passes in DAS, start-local-instance passes
>> in INSTANCE.
>>
>> 3. Calling Server.getName() and doing the comparison to "server"
>> directly, rather than calling isDas().
>>
>> Do you know of other ways that code determines whether it is
>> running on the DAS?
>>
>> I'd like to move in the direction of consolidating this behavior,
>> so that we have exactly one way of determining the role that the
>> server is filling. Thoughts?
>>
>> Thanks.
>> Tom
>>