If you're *ever* using an "Impl" class directly, you're probably
doing the wrong thing.
In this case, use CommandRunner.
Vijay Ramachandran wrote on 06/03/2010 02:15 PM:
> CommandRunnerImpl is one way; Supplemental commands may also work for
> you - lets have a quick chat so that I can understand your scenario better.
>
> Vijay
>
> On 6/3/10 1:42 PM, Joe Di Pol wrote:
>> Tim Quinn wrote:
>>> I'm not sure if this is the "recommended" way, but it's what we've
>>> done for DeployCommand.
>>
>> Thanks Tim, this is good info. I'll take a closer look at it.
>>
>> Just to clarify my Case #1. What I'm looking for is a way for
>> command code in the DAS to execute another pre-existing command
>> in the DAS -- for example start-cluster looping over the instances
>> and calling start-instance for each instance.
>>
>> I see there is a CommandRunner (CommandRunnerImpl) -- maybe
>> I should look at how AdminAdapter uses CommandRunner?
>>
>> Joe
>>
>>>
>>> Define a supplemental command using the annotations Vijay described
>>> on the wiki page:
>>>
>>> http://wiki.glassfish.java.net/Wiki.jsp?page=CLIDeveloperGuide
>>>
>>> The supplemental command will be run after (by default) the command
>>> it identifies in its @Supplemental annotation. Then have the
>>> supplemental command do what it needs to. If you look at these
>>> classes I recently checked in (deployment/admin module) you'll see
>>> what's happening.
>>>
>>> DeployCommand - a few changes to populate a data structure shared
>>> with the supplemental command; marked for DAS execution only
>>>
>>> PostDeployCommand - the supplemental command, also for DAS execution
>>> only; uses some infrastructure classes to execute a separate, remote
>>> command on the instances implied by the target.
>>>
>>> DeployCommandSupplementalInfo - the shared data structure class I
>>> alluded to earlier
>>>
>>> InstanceDeployCommand - the non-DAS, instance-only command that is
>>> run on the remote instances. (It's a no-op for the most part so far.)
>>>
>>> I think this approach will work well for your case 1. As used in the
>>> deployment case the infrastructure will actually take care of
>>> invoking the other remote command on the correct instances for you.
>>>
>>> For your case 2, why not refactor (as needed) the implementation of
>>> the other local command so your first local command and the other
>>> refactored local command just invoke the same common code?
>>>
>>> - Tim
>>>
>>> On Jun 3, 2010, at 3:00 PM, Joe Di Pol wrote:
>>>
>>>>
>>>> I'm looking for a little push in the right direction.
>>>> If there are existing commands that do this feel free
>>>> to point me at them.
>>>>
>>>> Case 1
>>>> ------
>>>> I have a remote command that as part of it's processing
>>>> wants to invoke another remote command. For example
>>>> start-cluster will likely loop through the instances
>>>> and call start-instance on each instance.
>>>>
>>>> What is the suggested way to have a remote command
>>>> execute another remote command locally? Seems like I
>>>> want a variation of enterprise.admin.cli.remote.RemoteCommand
>>>> that operates directly on the command class (instead
>>>> of remotely over HTTP).
>>>>
>>>> Case 2
>>>> -------
>>>> Same as Case 1 except I want to call a local command.
>>>> For example start-instance may want to call
>>>> start-local-instance if the instance is local to the DAS.
>>>>
>>>> Thanks,
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> <mailto:admin-unsubscribe_at_glassfish.dev.java.net>
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>> <mailto:admin-help_at_glassfish.dev.java.net>
>>>>
>>>
>>>
>>>
>>> Oracle <http://www.oracle.com>
>>> Tim Quinn | GlassFish | +1.847.604.9475
>>> Oracle Software Development
>>> Lake Forest, IL
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>