5 Replies Latest reply on Nov 23, 2011 6:27 PM by fwelland

    @WebServiceRef and JB AS 7.1.x re-borked?


      So I know @WebServiceRef is borked in jboss as 7.0.2 (full).


      I also know that jb 7.1.o is said to have this fixed.    And that the first beta is 'any day now' with a target GA release late Jan 2012.  


      So I pulled a nightly about a  week ago from ci.jboss.org.   I forget the build number but the directory unrolled to "7.1.alpha1-snapshot" 


      I wrote a simple SLSB with WS annotations and that works just fine.


      Then I wrote a simple JSF web client  that had a backing bean that called a the simple WS and it had a @WebServiceRef annotation. ...That all seem to work well (same WAR and EJB jar would not work under 7.0.2 -- but we knew that already).


      Today I was hoping to get the 7.1.beta --  but I all could find was "7.1.alpha2.snapshot"; I pulled that.    This same WAR with @WebServiceRef now fails.


      So....I am hoping there is some simple config update for the later 7.1.alpha2 and this isn't a regression bug since last week. 


      Anybody have this issue?    Anybody have suggestions?  



      Yes I know don't use nightlies and wait for GA ...Project is due in Feb 2012 and I will be using ee6 stuff -- and in particular WS stuff and JSF 2.x -- and if the betas can allow me to do development now; reasonably affectively......and I can deploy to a GA in feb-ish then I can continue with jb as 7.1x   -- otherwise i'd probably need to consider a different AS.

        • 1. Re: @WebServiceRef and JB AS 7.1.x re-borked?

          Could you please try this against AS 7.1.0 Beta1 which was released today? If it doesn't work there, please post some relevant code.

          • 2. Re: @WebServiceRef and JB AS 7.1.x re-borked?

            It is working better.   I can probably do some tinkering around abit with my WAR structure, jax-ws-catalog.xml and how I reference my services  & come up with a solution that works for both jboss as 7.1 and GF and seems to follow the ee6 specs.


            The specific sticking point I have now is:


            my service wsdl is at, in the cannoical sense:  http://mycompany.com/HelloWSWorld/Hello/Hello?wsdl


            In "development mode", I have a webservice that honors this wsdl but at service end point address:  



            I have a jax-ws-catalog.xml that maps the wsdl reference like so: 


            <system systemId="http://mycompany.com/HelloWSWorld/Hello/Hello?wsdl" uri="wsdl/Hello.wsdl"/>


            The jax-ws-catalog.xml is in both WEB-INF and WEB-INF/classes/META-INF/ with a wsdl/Hello.wsdl file relatvie to both locations (of jax ws catalog).


            In my jsf managed bean, I have the following instance variable declarations:


                @WebServiceRef(wsdlLocation = "http://mycompany.com/HelloWSWorld/Hello/Hello?wsdl")

                private Hello_Service service;


                private goober.ws.Hello port;


            I also have a @PostContruct() method in this managed bean like this:



                private void init()


                    System.out.println("in post construct going to provide the overrides...");

                    if(null == service)


                        System.out.println("I am a sad goober; because service seems null, I will just crash...");




                        System.out.println("I am a happy goober, service is not null");



                             port = service.getHelloPort();

                             BindingProvider bp = (BindingProvider)port;






            I think you see the basic pattern:   we code assuming the cannoical location of our service and in development environments we override this service end point with a local one...etc etc etc.


            In GF (3.1.1) this strategy works.   In 7.1.0beta1, the @WebServiceRef seems to want to really resolve  "http://mycompany.com/HelloWSWorld/Hello/Hello?wsdl" instead of using the mapping specified in the jax-ws-catalog.xml.


            So now it seems (with jboss as 7.1.0beta1), if I have a resolvable location 'in' the   @WebServiceRef(wsdlLocation = "...")  annotation to  either file ref like "wsdl/Hello.wsdl"  or a run-time resolvable reference like:  "http://localhost:8080/HelloWSWorld/Hello/Hello?wsdl" then the @WebServiceRef seems ok (and presumably the end-point reassignment too ).


            So it is like the jax-ws-catalog is not being used in jboss as 7.1.0beta1.  




            I have the catalog  in the wrong location?

            My expectations are wrong for @WebServiceRef() and jax-ws-catalog.xml?

            There is a config issue in my WAR or in AS7 that I need to tinker with make the jax-ws-catalog work?


            Any advise on this would be much appreciated.

            • 3. Re: @WebServiceRef and JB AS 7.1.x re-borked?

              This is a bug. Could U create a JIRA here


              and provide simple test case that works on GF?

              • 4. Re: @WebServiceRef and JB AS 7.1.x re-borked?
                • 5. Re: @WebServiceRef and JB AS 7.1.x re-borked?

                  So the problem may even be deeper than just ignoring the jax-ws-catalog.xml file.


                  After taking what I learned from the sample WAR attached to the issue; I applied that to my real application.     Unlike the sample application whose, JSF managed bean is the class that uses @WebServiceRef() and makes the WS call...the real application does this:


                  JSF Managed bean delegates to a different class (call it 'dal')  that is @Inject() by the managed bean.   This dal class does the @WebServiceRef() and then makes the WS calls.


                  @WebServiceRef in this DAL doesn't seem to work at all in this case.   Even when I explictly refer to a WSDL like this (as :


                      @WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/TemplateService.wsdl")

                      private com.blah.blah.template.TemplateServiceService  service;


                  As mentioned in the issue,  A annotation like:  @WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/TemplateService.wsdl")  'in' the Managed Bean directly seems to work OK; but appearantly not in a deeper layers...