Package org.apache.axis2.jaxws.spi

Class ServiceDelegate

  • public class ServiceDelegate
extends ServiceDelegate
    The ServiceDelegate serves as the backing implementation for all of the methods in the Service API. This is the plug point for the client implementation.

    • Method Detail

      • setServiceMetadata

        public static void setServiceMetadata​(DescriptionBuilderComposite composite)
        NON-STANDARD SPI! Set any metadata to be used on the creation of the NEXT Service by this thread. NOTE that this uses ThreadLocal to store the metadata, and that ThreadLocal is cleared after it is used to create a Service. That means: 1) The thread that sets the metadata to use MUST be the thread that creates the Service 2) Creation of the Service should be the very next thing the thread does 3) The metadata will be set to null when the Service is created, so to create another service with the same metadata, it will need to be set again prior to creating the service 4) The metadata can be set prior to creating both generic Service and generated Service instances. This allows creating a generic Service (javax.xml.ws.Service) or a generated Service (subclass of javax.xml.ws.Service) specifying additional metadata via a sparse composite. This can be used by a runtime to create a Service for a requester using additional metadata such as might come from a deployment descriptor or from resource injection processing of @Resource or @WebServiceRef(s) annotations. Additional metadata may include things like @WebServiceClient.wsdlLocation or a @HandlerChain specification.
        Parameters:
        composite - Additional metadata (if any) to be used in creation of the service
        See Also:
        Service.create(QName), Service.create(URL, QName)

      • setPortMetadata

        public static void setPortMetadata​(DescriptionBuilderComposite composite)
        NON-STANDARD SPI! Set any metadata to be used on the creation of the NEXT Port by this thread. NOTE that this uses ThreadLocal to store the metadata, and that ThreadLocal is cleared after it is used to create a Port. That means: 1) The thread that sets the metadata to use MUST be the thread that creates the Port 2) Creation of the Port should be the very next thing the thread does 3) The metadata will be set to null when the Port is created, so to create another Port with the same metadata, it will need to be set again prior to creating the Port 4) The metadata can be set prior to creating Port which specifies a QName via Service.getPort(QName, Class) or one that only specifies the SEI class via Service.getPort(Class) 5) Metadata can not be specified for dynamic ports, i.e. those added via Service.addPort(...). 6) Metadata can not be specfied when creating a dispatch client, i.e. via Service.createDispatch(...) 7) The Service used to create the port can be the generic service or a generated service. This allows creating Port specifying additional metadata via a sparse composite. This can be used by a runtime to create a Port for a requester using additional metadata such as might come from a deployment descriptor or from resource injection processing. Additional metadata might include things like a @HandlerChain specification.
        Parameters:
        composite - Additional metadata (if any) to be used in creation of the port
        See Also:
        Service.getPort(Class), Service.getPort(QName, Class)

      • getServiceDescription

        public ServiceDescription getServiceDescription()
        Get the ServiceDescription tree that this ServiceDelegate

      • releaseService

        public static void releaseService​(Service service)
        PROPRIETARY METHOD TO RELEASE RESOUCES. USE OF THIS METHOD IS NOT JAX-WS COMPLIANT AND IS NON-PORTABLE! This method can be called by client code to try to release resources associated with the Service instance parameter. These resources include the JAX-WS metadata objects (e.g. ServiceDescription, EndpointDescription) and the associated Axis2 objects (e.g. AxisService and realted objects). Note that these resources can be shared across multiple service delegates, and so they will not actually be released until the last service delegate using them is closed. Note that it is not necessary to call this method since the service delegate finalizer will also release the resources as appropriate. However, finalizers are not necessarily run in a timely fashion and the timing varies across JVMs. To predictibly release resources to prevent large memory requirements and/or OutOfMemory errors, this proprietary release method can be called.
        Parameters:
        service - Instance of the Service for which resources may be released.