On Jun 4, 2010, at 10:02 AM, Vijay Ramachandran wrote:
> On 6/4/10 9:46 AM, Jerome Dochez wrote:
>> On Jun 3, 2010, at 3:57 PM, Bill Shannon wrote:
>>
>>
>>> If you're *ever* using an "Impl" class directly, you're probably
>>> doing the wrong thing.
>>>
>>> In this case, use CommandRunner.
>>>
>>>
>> Yes !
>>
>> Good for Vijay I was in the plane ;-) I would have been mad
>>
>
> :( hope yo saw my immediate response !!!!
yes and since I saw all of these messages after the fact, I actually never got mad :)
>
>> CommandRunner is absolutely THE answer, as it should also take care if the invoked command should run on the DAS and/or instances.
>>
>> jerome
>>
>>
>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>