On Mar 13, 2009, at 11:04 AM, Kedar Mhaswade wrote:
>
>
> 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.
delegate to who ?
> 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.
>
so far, sniffers need to be installed but nothing else (no container)
for that type of plugability to happen, since you need to recognize
the bits in some ways.
> 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.
but such a command should not exist, they should just do "deploy". If
you start adding a dedicated administrative command for each plugable
container, you will confuse the people (for instance how should you
deploy a converged or composite application).
>
>
> 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.
generic implementation of what ?
jerome
>
>
> -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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>