Hi Peter,
Please ignore the previous "empty" e-mail.
Sorry, I didn't know the output also impacts NB plugin.
The previous confusion with deploy and redeploy was related to command
syntax changes. Since this is a public interface, I agree that it needs
to be notified in the alias.
I did not know that the output also impacts NB plugin. Furthermore, I
did not know that NB plugin is relying on a Manifest object format which
is not a public interface. I thought only asadmin uses the Manifest
object to display the output so I didn't send an e-mail to the alias.
I need to understand what exactly does NB plugin depends on.
The changes to the Manifest object is to fix IT 4247
<
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4247>. asadmin
was displaying cryptic message with the way Manifest object was storing
the string. SQE tests were failing with these messages.
Perhaps we can meet to understand what is the NB plugin requirements.
Moving forward, are we going to support Manifest object as a public
interface? If yes, then we need to agree on a standard format to follow.
I understand your frustration. Let's work together and try to get this
to work.
Here are some answers to your questions:
* How do I find out what the path of a directory deployed module is now?
You don't need to find out if you use redeploy command "--name". The
path is retrieved from domain.xml
* I'm told that now applications can reference multiple containers (in
the previous format this was not possible and my code was depending on
this constraint). Is this true?
I have no idea. Jerome?
* What does it mean and how do I determine what the type of an
application is if this can no longer be inferred from the type of
container?
The type of application is displayed along with the application name:
i.e.
hello1 <web>
This is the same format used in v2.
In the Manifest object, this is stored as:
getMainAttributes().getValue()...
Can we talk tomorrow around 10:00am?
Jane
Jane Young wrote:
> Peter Williams wrote:
>
>> The mailing list apparently didn't send this message properly.
>> Resending...
>>
>> -------- Original Message --------
>> Subject: Re: list-applications VS list-components
>> Date: Mon, 31 Mar 2008 13:27:04 -0700
>> From: Peter Williams <pete.williams_at_sun.com>
>> To: dev_at_glassfish.dev.java.net
>> References: <1133FCE8-CA5E-4D8C-ADEF-83E04D553B30_at_sun.com>
>> <47ED5F53.2080203_at_sun.com>
>>
>>
>>
>> I haven't yet digested this change fully but it has caused a number
>> of problems with the NetBeans plugins as Ludo has already mentioned.
>>
>> * All our NetBeans V3 plugins were broken by the manifest format
>> changes, so now we have table our other work and fix them ASAP.
>>
>> * The format change was unannounced and unexpected. A heads up email
>> would have been nice. An "I need to change the format of this, is
>> that ok" email would have been even better. Didn't we just have this
>> discussion wrt/ deploy/redeploy changes a few weeks ago?
>>
>> * Names now include extra appended data and will have to be parsed.
>> Parsing is computationally more expensive and fragile. One of the
>> goals of the Manifest format was to send machine readable data that
>> didn't need to be parsed. This goal is now been broken. Why?
>>
>> * At first glance, it seems the path information for a directory
>> deployed module was removed. My code was depending on this (and in
>> fact, was told to depend on it when we had the big discussion about
>> deploy/redeploy). How do I find out what the path of a directory
>> deployed module is now?
>>
>> * I'm told that now applications can reference multiple containers
>> (in the previous format this was not possible and my code was
>> depending on this constraint). Is this true? What does it mean and
>> how do I determine what the type of an application is if this can no
>> longer be inferred from the type of container?
>>
>> -Peter
>>
>> Jane Young wrote:
>>
>>> Hi, Jerome.
>>>
>>> I added the list-components command and display the warning message
>>> in list-applications since we didn't want to support two commands
>>> that do the same thing. To be compatible with v2, we need to have
>>> the list-components command. But since there may be confusion with
>>> add-on components, maybe we should deprecate list-components command
>>> and officially support list-applications command instead of
>>> displaying a warning message that this command will be removed.
>>> What do you think?
>>>
>>> The ListApplicationsCommand.java is actually calling
>>> ListComponentsCommand.java so there is no duplicate code. I think
>>> adding @Alias would be nice.
>>>
>>> Kedar, Bryon and I actually came up with a proposal to allow user to
>>> create command aliasing using asadmin. See:
>>> http://wiki.glassfish.java.net/Wiki.jsp?page=ProvidingScriptsInBinFolder2HideDomains#section-ProvidingScriptsInBinFolder2HideDomains-CommandAliasing
>>>
>>>
>>> Let me know your thoughts.
>>>
>>> Thanks,
>>> Jane
>>>
>>>
>>> Jerome Dochez wrote:
>>>
>>>> so somehow we changed the list-applications into list-components
>>>> and issue warnings when doing a list-applications.
>>>>
>>>> can't we just alias the commands, seems to me that
>>>> list-applications is a *lot* more natural command name than
>>>> list-components which could soon be confused with add-on
>>>> components related commands.
>>>>
>>>> I would love to see an official aliasing in place in the asadmin
>>>> adapter, maybe we could have a new annotation @Aliases
>>>>
>>>> so we could have something in that spirit
>>>>
>>>> @Service(name="list-components")
>>>> @Alias("list-applications")
>>>> pubic class ListComponentsCommand implements AdminCommand {
>>>>
>>>> }
>>>>
>>>> what do people think ?
>>>>
>>>> Jerome
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>