I answered on the bug
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5197 but I think the problem here mostly is the UC has not been updated with the latest jars and is the TP2 version. If I try the latest workspace and copy the jsr109-impl-10.0-SNAPSHOT.jar in modules I could get name <web> I will follow Hong suggestion for userVisible maybe that is not implemented .
This brings up an important point that UC modules should be updated very frequently. Maybe we should push out the 109-impl jar every week to the UC so such situations do not occur?
Peter I will touchbase with you if you want to discuss more.
Regards,
Bhakti
Hong Zhang wrote:
> Hi, Peter
>
>>> <just-checking>
>>> Are you resorting to parsing domain.xml to get this data?
>>> Is that how you are determining what applications are deployed to
>>> the server?
>>> </just-checking>
>>>
>>
>> No. Our code calls list-applications. But when something like this
>> breaks, it's faster to glance at domain.xml than to fire up the
>> debugging or restart NB w/ high detail logging.
>>
>> Anyway, it looks like perhaps list-applications is broken by this as
>> well.
>>
>> A web app on TP2 + metro is being returned by list-applications as
>> "MyWebApp <>" instead of the expected "MyWebApp <web>". The engine
>> list of such an application is empty. It is supposed to contain
>> "web", since this is a web app. Please note that this web app DOES
>> NOT use web service in any way. Merely, the server in question has
>> the metro bundle downloaded.
>
> Yes, this seems broken! Downloading the metro bundle should not change
> the behavior of the web applications. I will take a look.
>
> - Hong
>
>>
>> I filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=5197
>>
>> I'm a little worried about the fact that an arbitrary container
>> provider (metro in this instance, but it could be anything installed
>> on the server) can effectively disable the visibility of the web
>> container (and thus presumably any other container) in such a manner.
>>
>> I do not see a way to enable the NetBeans tooling to defend against
>> this behavior.
>>
>> -Peter
>>
>>> What does "asadmin list-applications" return after you deploy app
>>> that uses metro?
>>>
>>> - Kedar
>>>
>>> ----- Original Message -----
>>> From: Peter Williams <Pete.Williams_at_Sun.COM>
>>> Date: Monday, June 23, 2008 3:08 pm
>>> Subject: Re: sniffers used to load an app?
>>> To: dev_at_glassfish.dev.java.net
>>>
>>>
>>>
>>>> Sorry, I was on vacation last week, so wasn't able to reply.
>>>>
>>>> Bhakti Mehta wrote:
>>>>
>>>>>> So I need more information. What are you going to do for ejb
>>>>>> jars
>>>>>
>>>>> that contain web services? Will the ejb sniffer also be taken
>>>>> over like this? We will have an EjbWebServicesSniffer though
>>>>> I have not worked on it much as need to discuss more with Mahesh
>>>>> about this.
>>>>>
>>>>
>>>> Any more information on this? I would really like to know how this
>>>> will be handled (or rather, how it will appear in domain.xml for
>>>> deployed applications).
>>>>
>>>> Also, what happens if a jruby app tries to use metro?
>>>>
>>>>>> What about other candidate modules for web services using metro?
>>>>>>
>>>>>
>>>>> I do not think any other sniffers will be there from our end
>>>>
>>>> atleast.
>>>>> We should be the ones looking at webservices and doing the needed
>>>>>
>>>>
>>>> tasks .
>>>>
>>>>>> Is it safe to say that any add-on module for glassfish v3 can
>>>>>> take over the responsibilities of a core sniffer such as
>>>>>> web and
>>>>>
>>>> eliminate
>>>>>> it's visibility like this?
>>>>>>
>>>>>
>>>>> I dont think the app cares which deployer is deploying it as long
>>>>> as the deployer can handle it , also I dont think we are
>>>>> hijacking the WebDeployer infact that is the one doing the
>>>>> actual work,maybe
>>>>
>>>> Jerome
>>>>> can add more here
>>>>>
>>>>
>>>> I don't follow your logic here. <web> deployer is removed and
>>>> replaced with <webservices>, as far as domain.xml is concerned. So
>>>> from my perspective you are definitely hijacking web deployer. I
>>>> assume your
>>>> code is following some sort of delegation scheme under the hood since
>>>> obviously the webs work.
>>>>
>>>> I may have to find a new solution to my problem (how to identify an
>>>> application in domain.xml).
>>>>
>>>> -Peter
>>>>
>>>>> Regards,
>>>>> Bhakti
>>>>>
>>>>>> Bhakti Mehta wrote:
>>>>>>
>>>>>>> Yes this is expected behaviour.
>>>>>>> When you download metro the WebServicessniffer also will sniff
>>>>>>> the war files.
>>>>>>> Is an application has a webapp version less than 2.5 in web.xml
>>>>>>>
>>>>>>
>>>> we
>>>>>>> delegate the deployment to the WebDeployer . Only if the version
>>>>>>>
>>>>>>
>>>> is
>>>>>>> greater than 2.5,109 deployment will kick in and look for
>>>>>>> webservices.
>>>>>>> So the underlying behaviour is still the same in your case even
>>>>>>> after you downloaded metro and it should just work for you.
>>>>>>> Regards,
>>>>>>> Bhakti
>>>>>>>
>>>>>>>
>>>>>>> Peter Williams wrote:
>>>>>>>
>>>>>>>> If I download TP2 and deploy a simple web (single JSP page),
>>>>>>>> the sniffers in domain.xml for the app will be
>>>>>>>> <web> and <security>.
>>>>>>>>
>>>>>>>> If I then use update center to add Metro, undeploy and redeploy
>>>>>>>>
>>>>>>>
>>>> the
>>>>>>>> app, the sniffers for the app become <webservices> and <security>.
>>>>>>>>
>>>>>>>> Is this expected? Where did <web> go? Why is <webservices>
>>>>>>>>
>>>>>>>
>>>> being
>>>>>>>> used to load an app that doesn't use any web services?
>>>>>>>>
>>>>>>>> Most importantly, how can I tell in the second case that the
>>>>>>>> application is a web application?
>>>>>>>>
>>>>>>>> -Peter
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>