Hi Mark
I see you are getting deep now...
So we don't "deploy" the EjbWebServiceServlet, it is registered at
runtime when we start the ejb endpoint. The webservice engine provides
notification when endpoints are created and deleted (look into
appserv-commons/src/java/com/sun/enterprise/webservice/monitoring,
implementation is in appserv-core). The
com.sun.enterprise.web.EjbWebServiceRegistryListener picks up these
notification and register the servlet context root and tunnel all
incoming request to the endpoint implementation
(registerAdHocPathAndSubtree method).
Jerome
Mark Hansen wrote:
> Where/how is EjbWebServiceServlet deployed when you deploy an EJB
> endpoint. I can see how in the servlet case, a web.xml gets generated
> to deploy the JAXWSServlet. But, in the EJB case, I do not see any
> such deployment happening in the
> gf_home/domains/domain1/generated/xml/j2ee-modules/<module-name>
> area. Nor do I see any evidence of a EjbWebServiceServlet deployed
> when I look at the Server Admin Console.
>
> Thanks for any help on this,
>
> Mark
>
> Vijay Ramachandran wrote:
>
>> For a servlet endpoint : All requests are routed through JAXWSServlet
>> (for JAXWS endpoints) or JAXRPCServlet (for JAXRPC endpoints). The
>> code is @ appserv-core/src/java/com/sun/enterprise/webservice. At the
>> time of deployment, we generate a web.xml which does this redirection
>> of a request to the endpoint to this JAXWSServlet / JAXRPCServlet.
>> You will see this if you deploy a WAR with servlet endpoint and
>> checjk
>> gf_home/domains/domain1/generated/xml/j2ee-modules/<module-name>/WEB-INF/*.xml
>>
>>
>> For EJB endpoints : The requests come to
>> appserv-core/src/java/com/sun/enterprise/webservice/EjbWebServiceServlet
>> and from there we get the proper EjbMessageDispatcher to pass it on
>> to the appropriate endpoint
>>
>> Hope this given you an idea
>>
>> Vijay
>>
>> Mark Hansen wrote:
>>
>>> I'm trying to understand what is getting deployed that actually
>>> receives the SOAP messages at the web service's endpoint URL. My
>>> understanding is that this must be a servlet. So, I am assuming
>>> that the container generates a servlet wrapper for the @WebService
>>> annotated class and that the servlet is deployed at the endpoint
>>> URL, receives the SOAP messages on HttpRequests, and then passes the
>>> SOAP message to some kind of context creator, that then hands the
>>> context off to the protocol binding associated with the
>>> @WebService. Am I way off?
>>>
>>> -- Mark
>>>
>>> Vijay Ramachandran wrote:
>>>
>>>> I am not sure I understand your query. Can you please elaborate ?
>>>>
>>>> Mark Hansen wrote:
>>>>
>>>>> Thanks. Very helpful.
>>>>>
>>>>> If it is a WAR being deployed, is a javax.servlet.http.HttpServlet
>>>>> wrapper generated to send/receive SOAP over HTTP?
>>>>>
>>>>> -- Mark
>>>>>
>>>>> Vijay Ramachandran wrote:
>>>>>
>>>>>> Take a look at
>>>>>> appserv-commons/src/java/com/sun/enterprise/deployment/annotation/handlers/WebServiceHandler
>>>>>>
>>>>>>
>>>>>> During deployment of a service, all deployment descriptors (if
>>>>>> any) will be loaded and then the annotations are processed. On
>>>>>> seeing an @WebService, the annotation framework call
>>>>>> WebServiceHandler which processes the annotation. While
>>>>>> processing the annotation, we check if there a deployment desc
>>>>>> entry already available and if so, the annotation values will not
>>>>>> override the equivalent defined in the descriptor. At the end of
>>>>>> the annotation processing phase, we have all the information
>>>>>> required with which we generate WSDLs and other portable
>>>>>> artifacts (if not packaged).
>>>>>>
>>>>>> Hope this helps
>>>>>>
>>>>>> Vijay
>>>>>>
>>>>>> Mark Hansen wrote:
>>>>>>
>>>>>>> I'd like to better understand how Glassfish processes the
>>>>>>> @WebService
>>>>>>> annotation (and other JSR-181 annotations) to create and deploy an
>>>>>>> annotated class as a runnable web service. Can anyone suggest what
>>>>>>> packages/classes to start looking at? Could anyone maybe just
>>>>>>> sketch
>>>>>>> out how it works in general.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>