You know, I just thought...
If we are still planning to have admin changes be transactional,
wouldn't that take care of this?
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?
- 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
>