Jerome Dochez wrote:
>
> 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 ?
To this implementation, which determines missing piece(s).
>
>> 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.
Hmmm. I don't fully get it, but are you saying that sniffers for all kinds
of applications will be available in all distributions by default?
Also, I am looking at it from a missing command stand-point, not a missing
container stand-point. I think these cases are different.
>
>> 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).
For one, it is not in our hands. ESB might come with these commands. They
might have to support multiple app servers and might want to keep their
command set the same. Secondly, we have already released these commands,
so it is a compatibility issue. There are at least 40 ESB commands in
asadmin in V2.
Also, please, please look at it also from a non-deployment stand-point.
If someone just does "asadmin list-jbi-service-engines" what are we
going to do?
>>
>>
>> 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 ?
Generic implementation that decides the missing components and lets the
user know what to do. IMO, this is a generic implementation because
it just involves searching for certain metadata at the given install
or at a remote repository.
Just try "svn" on Ubuntu 8.0.4 and you'll know.
-Kedar
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>