Jerome Dochez wrote:
>
> On Mar 12, 2009, at 4:01 PM, Kedar Mhaswade wrote:
>
>> Hi Jerome,
>>
>> Didn't know that work was underway in this area.
>> But I am not sure if deployment is the only trigger
>> for this.
>>
>> My idea is analogous to Ubuntu, which doesn't just
>> break on a command missing from PATH, but helps the
>> user get to it if the command is something that it
>> knows about! Thus, svn/git/hg/... get a special treatment, but
>> a typo or an unknown program does not.
>>
>> Thus, something special is going on there. I suspect it is
>> communicating with the Debian package repo and doing something.
>> Need to investigate.
>>
>> 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).
I see. Yeah, deployment is a more frequent operation, I agree. But the issue
is whether or not deployment backend should delegate to implementation of this
facility when it realizes that it is not adequately equipped to service given
deployment request. I hope such delegation is possible because given deployment
not being possible (for the lack of a required container) for given install
is just a particular case of a facility not being available.
In other words, it is an outcome of leveraging certain package-specific
metadata that deployment backend has supposedly no knowledge of.
Think of ESB integration for example. In a plain GlassFish installation, no
ESB sniffer/container would exist. Still, an attempt to execute a command
like "asadmin deploy-jbi-service-assembly" should direct user to downloading
ESB container modules.
Thus, this generic implementation should "know" about all such probable modules
by interacting with update center or otherwise. I believe it is best to keep
deployment backend separate from it.
-Kedar
>
> jerome
>
>> When a user tries this, asadmin knows that s/he's aware of that
>> command (like svn) and hence we help the user get there.
>>
>> -Kedar
>>
>> Jerome Dochez wrote:
>>> On Mar 12, 2009, at 3:39 PM, Tim Quinn wrote:
>>>> Kedar,
>>>>
>>>> This seems like a very nice usability enhancement.
>>>> One possible frustration awaits users... If the system is smart
>>>> enough to tell me (as the user) what *I* should do to obtain the
>>>> missing piece, why doesn't it just ask me if I want *it* to do it
>>>> for me?
>>>>
>>>> EJB support is not currently installed. Would you like to download
>>>> and install it now? [y/n]
>>> unfortunately this is not possible through what Kedar is proposing
>>> since the generic deploy command would be the most likely trigger for
>>> that message. But I have to say this would be the most useful
>>> application of the concept "you are missing X, do you want X to be
>>> installed?". Sniffers would be a way to achieve that behaviour (that
>>> was my reason for coming up with Sniffer all together) but some work
>>> is needed to get there.
>>> jerome
>>>>
>>>> I remember with not much fondness a product I used back in the '80s
>>>> called TDMS from Digital (both long gone!). It had a definition
>>>> language in which the word "request" figured prominently. I
>>>> remember with great disgust that, encountering the misspelling
>>>> "reqeust" (I was a frequent offender) its diagnostic error would
>>>> complain something like
>>>>
>>>> Found "reqeust." Did you mean "request?"
>>>>
>>>> Infuriating.
>>>>
>>>> - Tim
>>>>
>>>> Lloyd Chambers wrote:
>>>>> It would be a nice touch.
>>>>>
>>>>> But what is the likelihood of using a command for something that is
>>>>> not installed on the server (perhaps intentionally)...isn't that
>>>>> putting the cart before the horse?
>>>>>
>>>>> Lloyd
>>>>>
>>>>> On Mar 12, 2009, at 3:12 PM, Kedar Mhaswade wrote:
>>>>>
>>>>>> Soliciting inputs from all of you regarding this interesting
>>>>>> problem I am seeing with modular nature of the server.
>>>>>>
>>>>>> The inspiration is drawn from Ubuntu. On my Ubuntu machine, when I
>>>>>> say "svn", it says:
>>>>>>
>>>>>> The program 'svn' is currently not installed. You can install it by
>>>>>> typing:
>>>>>>
>>>>>> sudo apt-get install *subversion*
>>>>>>
>>>>>> Thus, it knows the "intent" of the user and helps him/her to get
>>>>>> there.
>>>>>>
>>>>>> Wouldn't it be nice to have something similar for asadmin especially
>>>>>> since we are in a diverse environments of distributions like web
>>>>>> profile,
>>>>>> full Java EE 6 profile, cluster-aware installation/domain,
>>>>>> or just a domain that's missing certain "capabilities" that might be
>>>>>> available in update center? e.g. you do
>>>>>>
>>>>>> asadmin migrate-timers ... on a domain/installation that has no
>>>>>> EJB support and it comes back and says:
>>>>>>
>>>>>> EJB support is currently not installed. You can install it by typing
>>>>>> pkg install glassfish-v3-ejb (or whatever that is).
>>>>>>
>>>>>> I am tempted to add this as a requirement in CLI spec. What are your
>>>>>> thoughts? If we decide to do this, we need a lot of co-ordination
>>>>>> across
>>>>>> teams to do this.
>>>>>>
>>>>>> Thank you,
>>>>>> Kedar
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> Lloyd Chambers
>>>>> lloyd.chambers_at_sun.com
>>>>> GlassFish Team
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>