Tim Quinn wrote:
> You know, I just thought...
>
> If we are still planning to have admin changes be transactional,
> wouldn't that take care of this?
yes...
> The outer level would start the xn and after the top-level command it
> invoked had returned the outer level would commit the xn.
> Each command - and each container-specific deployer invoked by any
> command - would make its config changes all within the bounds of the
> xn. Each object - the command object and the deployer object and any
> others - knows what config changes it should make.
> Or did I miss something?
well we don't have the mechanism yet to propagate transactions to
subcommands but otherwise that would be the idea.
>
> - 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
>