8 Replies Latest reply on Jan 9, 2008 4:37 AM by asoldano

    JBWS-1858 + JBWS-1797: when to generate wsdl?

    asoldano

      I'm analyzing the http://jira.jboss.org/jira/browse/JBWS-1858 which is related to JBWS-1797. The main concern is generating and exposing the wsdl contract after the eventual servlet context-param properties have been read and the metadata has changed accordingly. As a matter of fact they can influence the wsdl (.NET friendly Endpoint...).

      Actually the wsdl creation is triggered during the create phase of the UnifiedMetaDataDeploymentAspect; either a new wsdl or the user provided one is selected, then the PublishContractDeploymentAspect publishes it. The new wsdl creation could be performed at some later stage, as far as I can see this would imply running the PublishContractDeploymentAspect and EagerInitializeDeploymentAspect later too, since they rely on the WSDLDefinition.
      This however is not going to solve the JBWS-1797 with AS42: currently the EndpointServlet gets the context-params from the its context during the first call to the endpoint, however at that time the endpoint has already been started (at the end of the deployment, by the EndpointLifeCycleDeploymentAspect).

      Thus according to me the main point here is not moving the wsdl generation later, it's instead reading the servlet context-params earlier, during the deployment. Of course we could do both the changes, but having those params available (for example as properties in the DeploymentInfo) before the UMDM is generated would be enough (and is required before the EndpointLifeCycleDeploymentAspect is run).
      What do you think about this?

        • 1. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
          heiko.braun

          IMO any container (or deployment) dependent meta data should be processed and massaged into the SPI artifacts before transitioning into the actual stack. So I'd say what you suggest makes perfect sense. Process those bits earlier and find a good representation in the SPI artifacts. I didn't look at it myself, but the stack shouldnt deal with container meta data directly at all:

          Container | SPI | Stack
          


          Any pipe represents a transformation step of the meta data involved and a clear boundary.


          • 2. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
            ropalka

             

            "alessio.soldano@jboss.com" wrote:

            Thus according to me the main point here is not moving the wsdl generation later, it's instead reading the servlet context-params earlier, during the deployment. Of course we could do both the changes, but having those params available (for example as properties in the DeploymentInfo) before the UMDM is generated would be enough (and is required before the EndpointLifeCycleDeploymentAspect is run).
            What do you think about this?


            Hi Alessio,

            this is the cite from JBWS-1799 (Thomas investigation about this issue):

            In AS42 the servlet context params are not exposed through the AS WebMetaData and are hence not available when during deploy time the wsdl is generated. For these containers and maybe generally it needs to be investigated whether we can generate the wsdl at Endpoint.start(). At that point the config-name has been corrected in ServerEndpointMetaData


            according to this you should first investigate whether you are able to access context parameters during the deployment phase (using JBossAS deployment metadata objects). If it is doable, you will have no problems ;-)

            Richard

            • 3. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
              ropalka

              Sorry,

              I was talking about JBWS-1797 ;-)

              RIchard

              • 4. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
                asoldano

                OK, back to this issue after the vacation...

                "heiko.braun@jboss.com" wrote:
                IMO any container (or deployment) dependent meta data should be processed and massaged into the SPI artifacts before transitioning into the actual stack. So I'd say what you suggest makes perfect sense. Process those bits earlier and find a good representation in the SPI artifacts. I didn't look at it myself, but the stack shouldnt deal with container meta data directly at all:


                I agree with you Heiko. Unfortunately after checking the code, I think the most proper place to read those bits is in the ContainerMetaDataDeploymentAspect that is part of the 4.0 & 4.2 AS code base; this of course could also be performed in another aspect (even an existing one, for example in the UnifiedMetaDataDeploymentAspect, before actually building the MD), but I don't like the idea of parsing the web.xml there... even if I tried it and of course it fixes JBWS-1797 with AS 4.2 ( I save the config name/file in 2 properties using the org.jboss.wsf.spi.deployment.Deployment then read them in the JAXWSServerMetaDataBuilder in case the same info is not available through the JSEArchiveMetaData)

                How should we proceed in this case? We can't change the AS4.2 code now, right?
                Please also consider that we could of course forget about JBWS-1797 with AS4.2 (as a matter of fact it is marked as resolved), but in that case I think JBWS-1858 should be marked as won't fix since generating the wsdl later is useless at least as far as the only reason for doing so is related to the endpoint config.



                • 5. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
                  heiko.braun

                   


                  We can't change the AS4.2 code now, right?


                  You can, but it will follow the AS release cycle. Just make sure there is no dependency on a particular container integration, so we can safely ship the stack without having to wait for the AS. Actually that's the whole idea about the SPI ;)



                  • 6. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
                    asoldano

                    Ok, thanks. I've commited a change to the ContainerMetaDataAdapter in the 4.2 branch of the AS codebase; it reads the jbossws configuration from the web.xml and enriches the container independent JSEArchiveMetaData with the missing information. This way no changes has to be done neither on the spi or on the native stack code base.

                    • 7. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
                      dimitris

                      Can you please create a JBAS jira to track this change with fix version AS 4.2.3.GA?

                      • 8. Re: JBWS-1858 + JBWS-1797: when to generate wsdl?
                        asoldano