3 Replies Latest reply on Jun 1, 2005 5:00 PM by starksm64

    WebServiceDeployer integration as deployment interceptor

    thomas.diesler

      The deployers for EJB, EJB3, WAR have been modified to use inlined xmbean desriptors that allow for deployment interceptors. The WebServiceInterceptor delegates to the appropriate WS endpoint deployer to do the additional work to get the endpoint up and running.

      With JSR181 a WS endpoint may be annotated with @WebService for that I need to read the annotation from the endpoint implementation class. Currently, this is done by loading the endpoint class and inspecting the annotations on java.lang.Class

      With java service endpoints (JSE) the web app context classloader only becomes available after the web app has started. This is too late.

      I can see two solutions to the problem:

      1. the annotations are obtained from the *.class file without loading the class
      2. the classloader is made available during the create step

      Generally, at what point of the deployment lifecycle should annotation meta data be available?

      This has been assigned to

      http://jira.jboss.com/jira/browse/JBWS-236

        • 1. Re: WebServiceDeployer integration as deployment interceptor
          bill.burke

           

          "thomas.diesler@jboss.com" wrote:
          The deployers for EJB, EJB3, WAR have been modified to use inlined xmbean desriptors that allow for deployment interceptors. The WebServiceInterceptor delegates to the appropriate WS endpoint deployer to do the additional work to get the endpoint up and running.

          With JSR181 a WS endpoint may be annotated with @WebService for that I need to read the annotation from the endpoint implementation class. Currently, this is done by loading the endpoint class and inspecting the annotations on java.lang.Class


          EJB3 can override the annotation within XML (or provide definition for @WebService. I hope that annotations are NOT required in J2EE 5 for web services, are they?


          With java service endpoints (JSE) the web app context classloader only becomes available after the web app has started. This is too late.

          I can see two solutions to the problem:

          1. the annotations are obtained from the *.class file without loading the class

          Not sure if this would solve your problem as you still need a classloader to obtain Javassist structures (or any structure for that matter). Javassist does ClassLoader.getResource() to obtain access to the raw bytecode.


          • 2. Re: WebServiceDeployer integration as deployment interceptor
            dimitris

            So the xmbean interceptor idea for the deployers seems to work after all, that's great!

            I see in the WebServiceInterceptor that you conditionally forward the call to a delegate mbean.

            A more dynamic approach is to plugin to the xmbean-ized deployer (e.g. EJB, EJB3, ...) the DynamicInterceptor which is just a placeholder that allows the dynamic registration/unregistration of interceptors, over the MBeanServer interface.

            This has the benefit of not having to alter the xmbean descriptor for every interceptor added, the interceptors attach and detach dynamically (e.g. if you don't have webservices at all) and there can be a better seperation of modules, so the WebServiceInterceptor would live in the webservices module.

            That was described here:

            http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57296

            I might try to refactor this, now that there is a good use-case. I'll also port the DynamicInterceptor stuff to 4.0, soon I hope.

            • 3. Re: WebServiceDeployer integration as deployment interceptor
              starksm64

              The metadata should be created during the create step. Since the tomcat web app class loader is not available at this time, another could be created to load resources. This already exists for loading the descriptors. The web app version could add the WEB-INF/{classes,lib} to its path. The new step that is needed is to merge the annotation and xml level metadata.

              A concern here is whether loading annotations as classes through a temporary class loader is going to cause problems. I guess there really should not be any annotations that would be defined by the web app class loader since these are not application level classes.