Hi Jane,
Comments inline.
Jane Young wrote:
> 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.
So the format of a command is public, but the output of the command is not?
In this context, where the command is an HTTP URL sent with
Agent="hk2-agent", and the output format is an object stream that is not
HTML, I don't follow that logic. The response must be public documented
API otherwise the entire command structure is utterly useless.
In fact I started a thread on this topic on 31 January. See
http://www.nabble.com/spec-for-REST-api-for-v3--to15220016.html#a15220016
and in particular, this unanswered message:
http://www.nabble.com/spec-for-REST-api-for-v3--to15220016.html#a15220016.
> 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>.
I disagree with your reasoning in that issue report. I don't see the
connection between renaming/rewriting this command and resolving a
cryptic error message. Furthermore, list-applications is a new
command. It has no backwards compatibility requirements with V2.
> 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?
This is a question for Jerome? I assume the answer is yes since he and
Ludo agreed on this concept last year when this project was conceived
and that is also what I've been led to believe. If the answer is no,
then the framework in the NetBeans V3 Plugin that communicates with the
server will need to be redesigned ASAP.
Whatever the answer, it needs to be decided ASAP and formally
communicated to the entire Glassfish Dev team, as there are apparently a
number of people who are not aware of this or the impact.
> 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
So how does the NB plugin know that the web app named "Foo" deployed on
the server currently (assume it's from a prior session) is the same
"Foo" that the user is deploying now? There is no way to know and
redeploy will silently do the wrong thing.
In fact, IIRC, this argument was brought up as a justification for
deleting the redeploy command in the first place, back when we had that
little problem.
>
> * 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()...
This gets back to the 3rd point in my previous message - "Names now
include extra appended data and will have to be parsed. ..." Why send
data that must be parsed in a key value structure when we could simply
add a few extra keys to handle the extra data. No parsing, less chance
of misinterpretation, faster.
Why does this have to be compatible with V2? You already said this was
an internal format in V2.
This thread is headed the same direction as the deploy vs redeploy
discussion -- GlassFish V3 is a new server with improvements to
streamline and fix problems from earlier servers. Now some of those
improvements are being deleted and the problems being put back in place,
usually with the justification of "V2 compatibility" regardless of
whether or not such compatibility is even warranted. I don't understand
this logic either.
>
> Can we talk tomorrow around 10:00am?
Afternoon would be better. 11:00 am is the earliest I can manage if it
has to be morning.
-Peter
>
> 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
>