On Apr 15, 2010, at 12:35 AM, Bill Shannon wrote:
> Byron Nevins wrote on 4/14/10 10:55 PM:
>> Will 3.1 turn off all normal admin command processing for instances?
>
> I don't think so. asadmin commands sent to the DAS will be cascaded
> to the instances for execution there, using the same admin command
> mechanism.
>
>> There are a LOT of commands that assume the server is "server".
>
> As a default for "target"? If so, yes, there's a lot that needs to be
> fixed to support a different target. Perhaps we can do it in a generic
> way that reduces the amount of code needed for each command?
there is already that mechanism in place.
On startup the startup code determines which server and config are current for this instance and stores those configuration with a specific registration name in the habitat (ServerEnvironment.DEFAULT_INSTANCE_NAME).
Commands (or any code for that matter) that just want to apply a change to their configuration should never lookup config with a "server-config" name or server with a "server" name but should use the DEFAULT_INSTANCE_NAME as the parameter to the @Inject annotations.
look at org.glassfish.deployment.admin.EnableCommand for the correct usage of that pattern.
unfortunately some code did not follow that and we need to chase those @Inject(name="server") type of injection. A global replace should suffice.
>
> If they're using it for something else, what?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>