Can autodeployer call into DeployCommand instead?
DeployCommand needs to be made target-aware. I don't know if it is
target-aware at the moment.
Tim Quinn wrote:
> Remember that the admin adapter is not the only logic that invokes
> DeployCommand and UndeployCommand. The just-added autodeployer also
> uses these classes.
> I think it will be cleanest - I thought this was the design - for each
> arriving request to AdminAdapter to trigger a single call to the
> appropriate xxxCommand which would handle all details except, of course,
> converting the result of the work into a response to go back to the
> AdminAdapter client.
>
> So, for example, the arrival of a deploy request with --target=a,b,c (we
> should allow multiple values for this option by the way) would invoke
> DeployCommand.execute once and that would be all that AdminAdapter needs
> to do.
> DeployCommand's execute method in this case would itself use
> DeployToDASCommand once, CreateApplicationRefCommand three times, etc.
> (A command should be able to invoke other commands this way.)
> As for managing the configuration changes and what code knows about what
> config changes...
>
> Each command should its config changes to a sequence of accumulated
> config changes from preceding work done as part of whatever top-level
> command is running. Each command could support two variants of the
> execute method, one that accepts a pre-existing command sequence object
> and one that does not. The variant that does not take a sequence
> argument represents the case when this command is the "top-level" entry
> point. Each command would implement not execute but doExecute (or
> changes the names to suit you):
>
> public abstract AdminCommandAdapter extends ApplicationLifeCycle
> implements AdminCommand {
>
> private boolean applyConfigOnExit; // records whether this
> protected abstract doExecute();
>
> public final void execute(AdminCommandContext ctx) {
> execute(null);
> }
>
> private List<ConfigChange> prepareConfigSequence(List<ConfigChange>
> changes) {
> if (changes == null) {
> applyConfigOnExit = true;
> changes = new List<ConfigChanges>();
> } else {
> applyConfigOnExit = false; // assign each time for correct
> serial reuse of the command object
> }
> return changes;
> }
>
> public final void execute(AdminCommandContext ctx, List<ConfigChange>
> configChanges) {
> doExecute(ctx, prepareConfigSequence(configChanges));
> if (applyConfigOnExit) {
> // apply config changes now
> }
> }
>
> This is similar in some ways to how v2 works. We did see some cases in
> which some config changes resulting from a command needed to take effect
> right away, not wait for the accumulated sequence to be applied. (I
> think one example was enabling or disabling one app during some other
> processing if I remember correctly.) This situation could be handled
> easily. The command that knows a subcommand's changes should take
> effect immediately simply invokes that subcommand's execute(ctx) method
> instead of execute(ctx, configChangeSeq).
>
> - Tim
>
> Kedar Mhaswade wrote:
>>
>>
>> Jerome Dochez wrote:
>>>
>>> On Feb 8, 2008, at 2:16 PM, Kedar Mhaswade wrote:
>>>
>>>>
>>>>>>>> I was referring to something like DeployCommand.java to do this.
>>>>>>>> AdminAdaptor
>>>>>>>> will end up calling DeployCommand for deployment purpose, right?
>>>>>>> yes. but the deployment command does not have all the meta data
>>>>>>> that would eventually be stored in the configuration, it's
>>>>>>> calculated along the way of deployment,
>>>>>>
>>>>>> The minimum data required is:
>>>>>> - name
>>>>>> - location
>>>>>> - whether the app/module is enabled
>>>>>>
>>>>>> That should be available for any deployment, I believe.
>>>>>>
>>>>>> Is there other meta-data that you were thinking of persisting to
>>>>>> domain.xml?
>>>>> list of containers, extra properties per container at least, so far.
>>>> Hmmm. Can these properties be "managed"? If not, is it better if we
>>>> persist them elsewhere? If a developer/administrator needs to know them
>>>> (even from a read-only perspective) it's OK to persist them there, but
>>>> I am not sure.
>>>>
>>>> Anyway, the minimal set is different from complete set. I think we
>>>> should
>>>> add the application/module's name/location/enable-status as a
>>>> minimum to
>>>> domain.xml and admin code should do that. If you don't object to it,
>>>> I will
>>>> make that change.
>>> I do object... I want only one location to update the tree, otherwise
>>> you end up
>>> in having to have two different parts changing the config and having
>>> to synchronize them manually
>>>
>>> what are you trying to solve here ?
>>
>> I am all for making one portion of the code change the config tree,
>> not multiple
>> places.
>>
>> But I am making a case for it to happen at least once. All I am asking
>> is whether I can make the change that, upon deployment, adds an entry
>> like:
>> <application name="foo" location="${com.sun.aas.instanceRoot}/apps
>> ..." enabled="true">
>>
>> ...
>>
>> <application-ref> foo </application-ref>
>>
>> in domain.xml.
>>
>> Let me know if you are ok with it.
>>
>>
>>>
>>> Jerome
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>