9 Replies Latest reply on Dec 6, 2016 2:23 PM by Jason Glass

    JBoss EAP 7 - erroneous trace on Injected Resources

    Jason Glass Newbie

      This was asked on StackExchange, then migrated to StackOverflow as I am a Stack newb - though have been using it for years for answers - but had never asked a question.  Anyways, If I can find the answer, I'll solve it in StackExchange giving whomever helps Kudos!

       

      http://stackoverflow.com/questions/40774708/jboss-eap-7-erroneous-trace-on-injected-resources

       

      Any thoughts, troubleshooting steps would help, thank you for your time!  And sorry, I dont see a "code" element to format the code pretty... If you'd like to see pretty code tags, please use the above link!

       

      I have run into an issue that I thought I might see if anyone knows the answer to. It's not too big a problem as the resources are actually being injected - however the console is showing and informational warning that the resources failed to resolve.

      This problem doesn't occur in EAP 5.1.2. I was just curious if anyone else has run into the problem and possibly I'm not doing things properly in EAP 7 and thus there's a workaround.

      Background:

      1. EJB Web Service packaged in a EAR. EAR has no application.xml or jboss-deployment-structure.xml

      Note: though I did try adding a jboss-deployment-structure.xml just to see if it helped.

      1. Stateless EJB is a webservice

      Here's a snippet from the ejb-jar.xml file:

         <env-entry>
        
      <description>Variable to distinguish between prod, uat and qa environments</description>
        
      <env-entry-name>net.mycompany.mypackage.mysubpackage.MyWSService.isUAT</env-entry-name>
        
      <env-entry-type>java.lang.Boolean</env-entry-type>
        
      <env-entry-value>false</env-entry-value>
        
      </env-entry>

        
      <env-entry>
        
      <description>Variable to distinguish between prod, uat and qa environments</description>
        
      <env-entry-name>isQA</env-entry-name>
        
      <env-entry-type>java.lang.Boolean</env-entry-type>
        
      <env-entry-value>false</env-entry-value>
        
      </env-entry>

       

      As you can see, I tried it both ways, e.g. with full package and class name in env-entry-name as well as just the plain old env entries name

      Here's the Web Service code snippet:

      @SuppressWarnings("unused")
      @Stateless
      @Local(IMyWSService.class)
      @WebService
      public class MyWSService implements IMyWSService {

        
      @Resource(name = "isUAT")
        
      private boolean isUAT;
        
      @Resource
        
      private boolean isQA;

        
      @WebMethod
        
      @ResponseWrapper(localName="doSomethingResponse", className="Response", targetNamespace="http://model.mysubpackage.mypackage.net")
        
      public Response doSomething
        
      (@WebParam(name="param1", mode=Mode.IN) String param1
        
      , @WebParam(name="param2", mode=Mode.IN) String param2
        
      , @WebParam(name="param3", mode=Mode.IN) String param3) {

        
      //more and more code
        
      .
        
      .
        
      .
        
      //pertinent method
        initAndSetEnvEntrieVars
      ();
        
      .
        
      .
        
      .
        
      //the method which actually utilizes the environment variables
        
      private void initAndSetEnvEntrieVars() {
        
      //setup env-entry related vars
        
      if(isUAT){
        
      System.out.println("We're in UAT");

        
      }else if(isQA){
        
      System.out.println("We're in QA");
        
      }
        
      }

      Note: and again, the values are actually being injected and theres about 15 that I removed from code for brevity.

      Heres the output in JBoss console:

       

      12:43:34,919 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) WFLYDS0004: Found MyUseful.ear in deployment directory. To trigger deployment create a file called MyUseful.ear.dodeploy
      12:43:34,925 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "MyUseful.ear" (runtime-name: "MyUseful.ear")
      12:43:34,968 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "MyUsefulService.jar")
      12:43:35,017 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment MyUseful.ear
      12:43:35,030 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment MyUsefulService.jar
      12:43:35,032 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-3) WFLYEJB0473: JNDI bindings for session bean named 'MyWSService' in deployment unit 'subdeployment "MyUsefulService.jar" of deployment "MyUseful.ear"' are as follows:

      java
      :global/MyUseful/MyUsefulService/MyWSService!net.mycompany.mypackage.mysubpackage.IMyWSService
      java
      :app/MyUsefulService/MyWSService!net.mycompany.mypackage.mysubpackage.IMyWSService
      java
      :module/MyWSService!net.mycompany.mypackage.mysubpackage.IMyWSService

      12:43:35,034 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0006: Starting Services for CDI deployment: MyUseful.ear
      12:43:35,036 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0009: Starting weld service for deployment MyUseful.ear
      12:43:35,056 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 71) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
      12:43:35,057 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 71) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
      12:43:35,057 INFO  [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=MyWSService
      address
      =http://localhost:8080/MyUsefulService/MyWSService
      implementor
      =net.mycompany.mypackage.mysubpackage.MyWSService
      serviceName
      ={http://model.mysubpackage.mypackage.net/}MyWSServiceService
      portName
      ={http://model.mysubpackage.mypackage.net/}MyWSServicePort
      annotationWsdlLocation
      =null
      wsdlLocationOverride
      =null
      mtomEnabled
      =false
      12:43:35,058 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 71) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
      12:43:35,058 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 71) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
      12:43:35,068 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 71) WFLYCLINF0002: Started client-mappings cache from ejb container
      12:43:35,080 INFO  [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://model.mysubpackage.mypackage.net/}MyWSServiceService from class net.mycompany.mypackage.mysubpackage..MyWSService
      12:43:35,144 INFO  [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/MyUsefulService/MyWSService
      12:43:35,146 INFO [org.apache.cxf.common.injection.ResourceInjector] (MSC service thread 1-7) failed to resolve resource isUAT
      12:43:35,147 INFO [org.apache.cxf.common.injection.ResourceInjector] (MSC service thread 1-7) failed to resolve resource isQA
      12:43:35,183 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/C:/jboss-eap-7.0/standalone/data/wsdl/MyUseful.ear/MyUsefulService.jar/MyWSServiceService.wsdl
      12:43:35,198 INFO [org.jboss.as.webservices] (MSC service thread 1-4) WFLYWS0003: Starting service jboss.ws.endpoint."MyUseful.ear"."MyUsefulService.jar".MyWSService
      12:43:35,378 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 71) WFLYUT0021: Registered web context: /MyUsefulService
      12:43:35,403 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "MyUseful.ear" (runtime-name : "MyUseful.ear")

       

      Again, this is more of just a nuisance, but I felt I'd run it by all of you just in case someone else gets stuck researching it for hours.

       

      Thank you!

      Jay Glass

        • 1. Re: JBoss EAP 7 - erroneous trace on Injected Resources
          jaikiran pai Master

          Jason Glass wrote:

           

          I have run into an issue that I thought I might see if anyone knows the answer to. It's not too big a problem as the resources are actually being injected - however the console is showing and informational warning that the resources failed to resolve.

          ....

          Note: and again, the values are actually being injected and theres about 15 that I removed from code for brevity.

          Heres the output in JBoss console:


          12:43:35,080 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://model.mysubpackage.mypackage.net/}MyWSServiceService from class net.mycompany.mypackage.mysubpackage..MyWSService
          12:43:35,144 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/MyUsefulService/MyWSService
          12:43:35,146 INFO [org.apache.cxf.common.injection.ResourceInjector] (MSC service thread 1-7) failed to resolve resource isUAT
          12:43:35,147 INFO [org.apache.cxf.common.injection.ResourceInjector] (MSC service thread 1-7) failed to resolve resource isQA
          12:43:35,183 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/C:/jboss-eap-7.0/standalone/data/wsdl/MyUseful.ear/MyUsefulService.jar/MyWSServiceService.wsdl
          12:43:35,198 INFO [org.jboss.as.webservices] (MSC service thread 1-4) WFLYWS0003: Starting service jboss.ws.endpoint."MyUseful.ear"."MyUsefulService.jar".MyWSService
          12:43:35,378 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 71) WFLYUT0021: Registered web context: /MyUsefulService
          12:43:35,403 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "MyUseful.ear" (runtime-name : "MyUseful.ear")

           

          Again, this is more of just a nuisance, but I felt I'd run it by all of you just in case someone else gets stuck researching it for hours.

           

          Thank you!

          Jay Glass

           

           

          So, as you note, it looks like a logging related issue coming from the WebServices integration library, where it logs this message even when the injection (probably via EJB container) is successful. Maybe asoldano would be able to help.

          1 of 1 people found this helpful
          • 2. Re: JBoss EAP 7 - erroneous trace on Injected Resources
            Jason Glass Newbie

            Thanks jaikiran pai! asoldano any ideas, again, not a biggie - but spent a little time troubleshooting what appeared to be red herring traces when in fact the resources were injected, just dont want to see others face a similar problem.  Thanks All!  Jay

            1 of 1 people found this helpful
            • 3. Re: JBoss EAP 7 - erroneous trace on Injected Resources
              Alessio Soldano Master

              Hi,

              I'd need to go and check the code to confirm, but I think what's happening there is that the WS layer basically goes through different mechanism for having the values there injected. First it tries letting Apache CXF layer resolve the values, if that fails (with the log shown here) it uses the internal JBoss mechanism, which is what is actually getting the values from the ejb-jar.xml descriptor here.

              • 4. Re: JBoss EAP 7 - erroneous trace on Injected Resources
                Jason Glass Newbie

                Thanks Soldano!  Thanks as well for getting back to me!  So should i inject the values using the " Apache CXF layer" and what type of file would that be?  I looked here but nothing of value:
                http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-ResourceInfoApache CXF -- JAX-RS Basics

                 

                I also see now someone with a similar issue that you were involved in:

                Cannot inject resource in jax-ws handler on jboss AS 7


                Though note, my resources are actually injected, I just get that weird trace.  Do you think I should be using Fuse (blueprint or Spring) or CDI even though I'm just injecting simple boolean, int and String values not actual objects

                • 5. Re: JBoss EAP 7 - erroneous trace on Injected Resources
                  Alessio Soldano Master

                  jasonglass no, simply ignore that message in the log and you're done. It's basically an internal thing, the log comes from apache cxf so there's not much we can do in this case to avoid it.

                  The thread you linked is related to a slightly different scenario which was caused by a bug (well, a missing feature at that time), but that's solved.

                  • 6. Re: JBoss EAP 7 - erroneous trace on Injected Resources
                    Jason Glass Newbie

                    Thanks asoldano!  Also thanks jaikiran pai! for the initial help!

                     

                    BTW:  I'm probably going to "rehash" the discussion on JBoss web service endpoints in generated WSDL, e.g.

                    SOAP Addres Rewrite for Endpoint loadbalancing

                    Setting soap address location for JBoss based EJB webservice

                    JBoss 7.0.2 soap rewrite issue

                    Issue with soap:address generated (https)

                     

                    I had a few other links where you personally responded but not find them now...  Basically we have a company sending to our F5 load balancer on 443, the F5 decrypts the request to HTTP (No ssl) and send it to server on 8080 - but the generated WSDL has http://mydomain.com:8080 and the servers not allowed to run on 443 as its a privileged port.  I'm wondering if on the last thread if some of that might work?  Or is there now a better way to specify the endpoint?  I know I saw talk of patches from years ago ;-)

                     

                    Thanks again man!

                     

                    Jay

                    • 7. Re: JBoss EAP 7 - erroneous trace on Injected Resources
                      Jason Glass Newbie

                      Update: for the @WebContext annotation, I added "transportGuarantee="CONFIDENTIAL"" which did indeed add https and 443 to the soap address endpoint in the generated WSDL - however now the server redirects the request to 8443 O_o, makes sense, but unfortunate so now I'm wondering is it possible to have the 8443 connector redirect back to 8080 and not use HTTPS?  Or should I just give up the fight and try and embed the WSDL file in the EJB META-INF directory (i believe that was supported) or point to an address on the server?  I PROMISE, If I get this working I'll write a darn article on what worked and didnt work ;-)

                      • 8. Re: JBoss EAP 7 - erroneous trace on Injected Resources
                        Jason Glass Newbie

                        Another Update (sorry):after adding the above, I had a thought and changed the http 8080 connector to the following

                        <!-- A HTTP/1.1 Connector on port 8080 -->

                              <Connector  protocol="HTTP/1.1" port="8080" address="${jboss.bind.address}"

                                       scheme="https" secure="true"

                                        connectionTimeout="20000" redirectPort="8080" />

                         

                        Which worked, but it's a bit of a kludge and we're not really wanting HTTPS to be needed between the load balancer appliance and the JBoss servers so any other thoughts recommendations would be appreciated!