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
>