Jane Young wrote:
> Hi Peter,
>
> Please ignore the previous "empty" e-mail.
>
> Sorry, I didn't know the output also impacts NB plugin.
No worry, we are all developing in parallels multiple connected things.
> 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.
It is easy to fix: Nb should be the default development env for
developing Gf v3, right?
From there, it is easy to install the GF V3 Nb plugin from Update
Center, and before doing commit, run a few tests like:
start/stop the server via Nb
Start in Debug mode the server via Nv
Get the list of deployed apps and undeploy them (from the services tab)
via Nb
Create Web apps and deploy/redeploy to V3....via Nv
This will activate 99.99% of what the plugin is using in terms of api.
This list of tests take at most 5 minutes to execute since starting V3
and deploying Web Apps to it takes not time :-)
(ps: if you are using Eclipse, you can use the uptodate Eclipse V3
plugin as well)
Remember that most of the downloads of GF are from a Tools Bundle, so
this is what developers are using in majority.
Using asadmin as CLI or vi+jar is not a common use case anymore.
> 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.
The manifest format was designed specifically for Tools like NetBeans or
Eclipse or any tools that want to interact with the server via http.
> 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?
We need a format that is easily parsable from tools. This format is not
the same as the html one for users displayed in a browser.
Manifest format was the easiest to express things and collection of
things without involving XML.
The bug you are refering to it a bug in the client of this manifest
interface. Manifest format should be treated as a binary format, never
displayed to users, only processed by tools.
The bug has to be reopen since the output:
D:\gf\v3\admin\cli>cli deploy hello.war
properties=(name=hello)
ERRORLEVEL: 0
D:\gf\v3\admin\cli>cli list-components
hello <web>
ERRORLEVEL: 0
is not user friendly at all. Not sure what <web> means there or
ERROLEVEL in capital letters, or properties=(name=hello) for a user...
Thanks,
Ludo
> 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
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>