[I have keyboard problems and accidentally sent the earlier reply
prematurely]
Kedar Mhaswade wrote:
> Can autodeployer call into DeployCommand instead?
It already does so. It's that way today because that's the only choice
available and it seems natural to do it that way going forward.
But in an earlier message in this thread I think you suggested that the
object (AdminAdapter in that example) that calls DeployCommand would
change the config or persist config changes that had happened as
DeployCommand ran. My point earlier was that there needs to be a single
common point where AdminAdapter and the autodeployer (and any future
possible client class) call in to do everything that's required,
including whatever config-related logic you had in mind. Otherwise that
config-related logic has to be duplicated in - or at least called
explicitly from - both the autodeployer and the AdminAdapter after they
have called the DeployCommand. We do not want that. Better for the
config logic to be inside DeployCommand. Or if there are compelling
reasons for DeployCommand.execute to not update the config, there should
be some other umbrella class that itself invokes DeployCommand and then
does whatever config-related logic is needed. Then AdminAdapter and
autodeployer can use that umbrella class.
> DeployCommand needs to be made target-aware. I don't know if it is
> target-aware at the moment.
DeployCommand is not currently target-aware because, I presume, we
support only the DAS. Obviously that will have to change when we support
other instances.
- Tim
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>