Jerome Dochez wrote:
>
> On Mar 12, 2009, at 4:01 PM, Kedar Mhaswade wrote:
>
>>
>>
>> Also, how would deploy command help when user tries
>> something like "asadmin create-cluster" or "create-node-agent"?
> it would not, clearly what you are proposing would be the only way to
> solve it.
> All I was saying is that, agreeing with Tim, it would be nice to
> support :
>
> asadmin deploy myejb.jar
> > the ejb container is not installed, do you want to install it ?
>
> and that's what deployment backend has some hooks and facilities for.
> This would not be something you would be able to solve with your
> proposal unless you would have some miracle logic. The two
> technologies are complementary.
>
> I also think that solving the example above has a lot of value,
> because a lot of users would get into such scenario, let's face it,
> deploy and undeploy are probably to most used commands (with
> start-domain of course).
The discussion we started in e-mail a few days ago - where I outlined a
general approach for allowing admin commands to "call back" to the
client to do various things - could be used to support this for any
admin command. Although currently the Payload implementation is used
only for uploads of user applications during deployment and downloads of
generated app client artifacts (coming very soon), the current
implementation would support any kind of callback from any admin command
- such as, oh, prompting the user with a question and accepting a
response.
For this to work, we'd need two things: the generic callback-and-reply
framework in the server and the admin client, and the "proxy" or "stub"
commands which don't actually execute the intended operation but rather
advertise the existence of the full implementation and know something
about how to retrieve and install the full implementation.
GlassFish could come with a subclass of AdminCommand (CommandProxy?)
which knows how to do this except perhaps for the specific question to
ask and information about how to download and install the full
implementation. Individual command authors could extend that
CommandProxy, supplying the implementation for the question and the
download logic. Done right, CommandProxy could do almost all of the
work, making this very easy for module developers. If the full module
were available via the Update Center, well then so much the
better...CommandProxy could handle those details too with just some data
differing from one CommandProxy to the next.
In fact, module developers might see good value in having their proxy
commands shipped with the standard GlassFish distribution(s) so their
full modules would be only a mouse click or a "return" key press away
for the user.
- Tim