1 2 Previous Next 29 Replies Latest reply on Apr 21, 2008 9:07 AM by heiko.braun Go to original post
      • 15. Re: webservices ejb3 api usage
        heiko.braun

        Taking a closer look shows that we can use the KernelController to lookup the bean container:

         KernelController houston = KernelLocator.getKernel().getController();
         if (houston.getInstalledContext( objectName.getCanonicalName() ) == null)
         throw new WebServiceException("Cannot find service endpoint target: " + objectName);
        


        This leaves us with a lookup by ObjectName, in which I don't see a problem. The MC API could be considered stable I think.

        - Any objections regarding the use of SessionContainer.localInvoke(...)?


        • 16. Re: webservices ejb3 api usage
          wolfc

          Define an interface for the SessionContainer.localInvoke. This interface is part of ejb3-ws-spi and is implemented by ejb3-core.

          How do you get the correct ObjectName?

          For WebServiceContext injection I'm also in favor of 2.2, but it should be a requirement for the new (MC?) JavaEE injection component.

          • 17. Re: webservices ejb3 api usage
            heiko.braun

             


            Define an interface for the SessionContainer.localInvoke.


            Right, I already did that. Currently I am playing with two integration interfaces. One for deployment and another one for invocation. Both need to be implemented by the Ejb3Deployment and SessionContainer respectively. A generic way to access injectable properties (2.2) is covered by the later as well:

            Deployment handling:

            
            /**
            * Access web service decl. within an EJB3 deployment.
            */
            public interface WebServiceDeployment {
            
             java.util.List<spi.integration.WebServiceDeclaration> getServiceEndpoints();
            }
            
            public interface WebServiceDeclaration
            {
             /* aka bean name */
             String getComponentName();
            
             /* aka bean impl */
             String getComponentClassName();
            
             /* generic meta data retrieval */
             <T extends java.lang.annotation.Annotation> T getAnnotation(Class<T> t);
            }
            


            Invocation handling:
            
            /**
            * Invoke a web service implementation hosted by a StatelessSession container.
            */
            public interface ServiceEndpointContainer {
            
             java.lang.Class getServiceImplementationClass();
            
             java.lang.Object invokeEndpoint(Method method, Object[] objects,
             spi.InvocationContextCallback invocationContextCallback)
             throws java.lang.Throwable;
            }
            
            /**
             * Callback for invocation context properties that may be injected
             * in the service endpoint prior to actual method invocation.
             */
            public interface InvocationContextCallback
            {
             <T> T get(Class<T> propertyType);
            }
            
            


            • 18. Re: webservices ejb3 api usage
              wolfc

              Deployment handling should be done by an intermediate deployer. How does the webservice meta data merge with the ejb3 meta data?

              You should be able to pick up the merged ejb3 meta data and instantiate some meta data for the web deployer to initiate your endpoint.

              As for injection. That should have happened before method invocation. I was thinking about a ThreadLocalStack construction which is injected during construction and set during invocation.

              • 19. Re: webservices ejb3 api usage
                heiko.braun
                • 20. Re: webservices ejb3 api usage
                  heiko.braun

                  The current tracking issue is
                  http://jira.jboss.org/jira/browse/JBWS-2083.

                  I've implemented and released the API with jbossws-spi 1.0.2.GA.
                  It already implemented in EJB3 trunk (EJBTHREE-1247).
                  The only pieces missing pieces are


                  a) http://jira.jboss.org/jira/browse/JBMETA-12
                  (SPI update in meta data project)

                  b) http://jira.jboss.org/jira/browse/JBWS-2086
                  (Make the WS container integration use the new API)

                  c) http://jira.jboss.org/jira/browse/EJBTHREE-1248
                  (Automate the WS integration test runs as part of the EJB3 release QA)

                  • 21. Re: webservices ejb3 api usage
                    anil.saldhana

                    Please provide the following dependency in the maven repository.

                    
                    Missing:
                    ----------
                    1) org.jboss:jbossws-spi:jar:1.0.2.GA
                    
                    


                    • 22. Re: webservices ejb3 api usage
                      heiko.braun

                      yep, it's there

                      • 23. Re: webservices ejb3 api usage
                        heiko.braun

                         


                        Deployment handling should be done by an intermediate deployer. How
                        does the webservice meta data merge with the ejb3 meta data?


                        IMO there is no such thing as dedicated WS metadata. It's all part of the Ejb3 meta data. So this will be handled by whatever component parses the Ejb3 meta data. The WebServiceDeclaration interface addresses this.
                        You can move it around, deprecate your sources or implement a new metadata representation. Just make sure the interface is offered to WS deployers.


                        As for injection. That should have happened before method invocation. I was thinking about a ThreadLocalStack construction which is injected during construction and set during invocation.


                        Right, that makes sense. Let's regard two pieces:

                        1) a web service invocation (SOAP, hit's jbossws)
                        2) an endpoint (i.e. EJB3) invocation that derives from 1

                        Currently the ws invocation model offers a callback (InvocationContexCallback) to access WS injection properties. This is passed on to the StatelessContainer (implements ServiceEndpointContainer). To me the order of injection vs. method invocation is an implementation detail of the EJB3 domain.

                        If I understand you correctly we speak about dependency injection before the bean becomes method-ready, right?
                        So I'd say leave ServiceEndpointContainer interface in place and get Ejb3 problems sorted internally. Up to now I don't see why this should affect the WS-EJB3 API in place.


                        • 24. Re: webservices ejb3 api usage
                          heiko.braun

                          In general the reason why the code resides with the EJB3 project is that WS just specifies the requirements (a bunch of interfaces) and _initially_ implements it in the EJB3 code base. Subsequent changes however should be implemented and verified (WS test suite) by the EJB3 team.

                          Maybe I don't understand you correctly, but I still don't see a reason why any of the upcoming changes, may it be deployment or injection should affect the API in place.

                          If you still see something missing please document the lacking features in terms of test cases.

                          • 25. Re: webservices ejb3 api usage
                            wolfc

                             

                            "heiko.braun@jboss.com" wrote:
                            To me the order of injection vs. method invocation is an implementation detail of the EJB3 domain.

                            If I understand you correctly we speak about dependency injection before the bean becomes method-ready, right?

                            Yes and it's not an EJB 3 problem:
                            "JAX-WS 2.1 5.2.1" wrote:
                            Endpoint implementors MAY use the WebServiceContext facility (see 5.3) to access the message context and other information about the request currently being served. Injection of the WebServiceContext, if requested, MUST happen the first time the endpoint is published. After any injections have been performed and before any requests are dispatched to the implementor, the implementor method which carries a javax.annotation.PostConstruct annotation, if present, MUST be invoked. Such a method MUST satisfy the requirements for lifecycle methods in JSR-250 [31].


                            You need the intermediate deployer to access any EJB 3 meta data. WebServiceDeployment and WebServiceDeclaration should not be implemented by any runtime container or even exist in the first place.

                            As for the WebServiceContext. The InvocationContextCallback should not exist. You should specify an WebServiceContext injection handler on the injection component which injects a WebServiceContext which delegates to a thread local WebServiceContext. That thread local should be set before the invokeEndPoint.

                            The only problem is that the injection component is in the works and will probably not be integrated with EJB 3 before AS 5.1. So for the moment we could keep the InvocationContextCallback and I'll handle the thread local stuff (as in EAP 4.x).

                            • 26. Re: webservices ejb3 api usage
                              heiko.braun

                               


                              You need the intermediate deployer to access any EJB 3 meta data. WebServiceDeployment and WebServiceDeclaration should not be implemented by any runtime container or even exist in the first place.


                              I don't get it. How is an intermediate deployer different from what we already do to Ejb3Deployment? Those interfaces just specify our requirements towards EJB3 meta data. If I am going to put another deployer in between, I still need to work on Ejb3Deployment.

                              • 27. Re: webservices ejb3 api usage
                                heiko.braun

                                 


                                The InvocationContextCallback should not exist.


                                OK, I am going to deprecate it and let you know how to pick up the WebServiceContext from a ThreadLocal. Carlo is going to provide the WebServiceContext proxy that will be injected into the bean before it becomes method ready.


                                • 28. Re: webservices ejb3 api usage
                                  wolfc

                                   

                                  "heiko.braun@jboss.com" wrote:
                                  I don't get it. How is an intermediate deployer different from what we already do to Ejb3Deployment? Those interfaces just specify our requirements towards EJB3 meta data. If I am going to put another deployer in between, I still need to work on Ejb3Deployment.

                                  Ejb3Deployment won't be there anymore, you need to work on JBossMetaData. To get that you need to create a deployer which has as input:
                                  addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);


                                  • 29. Re: webservices ejb3 api usage
                                    heiko.braun

                                    I need some more information on the way we retrieve meta data in the future: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145492#4145492

                                    1 2 Previous Next