Hi Dhiru,
Thanks. That clears things up a bit. I see that is the
@WebServiceProvider annotation is used *without* a web.xml to provide a
<servlet-name>, then you need a unique name in order to reference the
endpoint internally within GlassFish. However, when @WebServiceProvider
is used *with* a web.xml to provide a <servlet-name>, then I think that
this should take precedence over the (internally generated>
<servlet-link>. That is the behavior I have observed with GlassFish in
the @WebService case.
> No in the scenario where there is only the @WebServiceProvider
annotation without a webservices.xml file this is required.
> Keep in mind in J2EE 1.4 and JSR-109 1.1, <servlet-link> in
webservices.xml must be the servlet-name of a JAX-RPC
> Service Endpoint in the same WAR file. In Java EE 5 and JSR -109 1.2,
since the webservices.xml file is optional, fully
> qualified name of the SIB is used as <servlet-link>. This is done to
have uniqueness of the name. (You could have more
> than one Web Service endpoints in a WAR file)
OK, that makes sense, but: (1) it seems to me like that is letting the
GlassFish implementation drive the JSR-109 server programming model.
I.e., the behavior of the *internally generated* webservices.xml should
not determine the programmer's use of the web.xml <servlet-name>; and
(2) it is not consistent with the behavior of GlassFish in the
@WebService case.
I appreciate your attention to this somewhat obscure technical point! I
think its worth clarifying the spec/GlassFish implementation issues,
however, because they bear on the "ease of use" issue. The different
behavior of @WebService and @WebServiceProvider - when using web.xml and
no webservices.xml - is confusing.
Thanks,
Mark
Dhiru Pandey wrote:
> Hello Mark,
>
> Mark Hansen wrote:
>
>> Thanks, Dhiru - one more question ...
>>
>> > What is described is for the case when only the @WebServiceProvider
>> annotation is used without a webservices.xml file.
>>
>> So, is this really meant to be guidance to implementors with
>> containers that are generating the webservices.xml?
>
> No in the scenario where there is only the @WebServiceProvider
> annotation without a webservices.xml file this is required. Keep in
> mind in J2EE 1.4 and JSR-109 1.1, <servlet-link> in webservices.xml
> must be the servlet-name of a JAX-RPC Service Endpoint in the same WAR
> file. In Java EE 5 and JSR -109 1.2, since the webservices.xml file is
> optional, fully qualified name of the SIB is used as <servlet-link>.
> This is done to have uniqueness of the name. (You could have more than
> one Web Service endpoints in a WAR file)
>
>> In that case, why should the spec require this? And even if it does
>> require a constraint on <servlet-link>, should this be described in
>> Section 5 which is addressing the server programming model and not
>> JSR-109 implementation issues?
>>
>> -- Mark
>>
>>
>> Dhiru Pandey wrote:
>>
>>> Hello Mark,
>>>
>>> What is described is for the case when only the @WebServiceProvider
>>> annotation is used without a webservices.xml file.
>>> One could certainly provide this file along with the annotation and
>>> then <servlet-link> could be specified to be whatever the developer
>>> wants.
>>>
>>> I think the language in the spec. is confusing and should be fixed
>>> to clear this up.
>>>
>>> Thanks,
>>> -Dhiru
>>>
>>>
>>> Mark Hansen wrote:
>>>
>>>> Thanks Dhiru (and also Vijay) for pointing out the JSR-109
>>>> requirement. I don't know how I missed that!
>>>>
>>>> > You should be able to override this if the webservices.xml file
>>>> is used
>>>>
>>>> But, Dhiru, how can I override if JSR-109 *requires* <servlet-link>
>>>> in the webservices.xml to be the fully qualified name of the SIB?
>>>>
>>>> -- Mark
>>>>
>>>> Dhiru Pandey wrote:
>>>>
>>>>> If you are not using a deployment descriptor (webservices.xml)
>>>>> file then this is true.
>>>>>
>>>>> Please see section 5.3.2.2 on WebServiceProvider annotation
>>>>> (JSR-109):
>>>>>
>>>>> "For Servlet based endpoints using this annotation, fully
>>>>> qualified name of the Service Implementation Bean class
>>>>> must be used as the <servlet-link> element in the deployment
>>>>> descriptor to map the Port component to the actual
>>>>> Servlet."
>>>>>
>>>>> This implies that the servlet name (which is the same as the
>>>>> <servlet-link>) should be fully qualified name of the Service
>>>>> Implementation Bean class
>>>>>
>>>>> You should be able to override this if the webservices.xml file is
>>>>> used
>>>>>
>>>>> -Dhiru
>>>>>
>>>>> Mark Hansen wrote:
>>>>>
>>>>>> It seems to be a requirement in GlassFish that when deploying an
>>>>>> @WebServiceProvider along with an web.xml, that the
>>>>>> <servlet-name> must be equal to the fully qualified name of the
>>>>>> provider class (i.e., the class with the @WebServiceProvider
>>>>>> annotation). Is that correct? Is this a requirement specified
>>>>>> anywhere in JSR-109 or JSR-181, because if it is, I cannot find
>>>>>> such a requirement.
>>>>>>
>>>>>> Thanks for any insight on this.
>>>>>>
>>>>>> -- Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>