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
>