Topic
  • 4 replies
  • Latest Post - ‏2013-05-29T16:11:24Z by tmparker
Pathogen67
Pathogen67
27 Posts

Pinned topic Wrong runtime.properties being used

‏2013-04-21T23:50:22Z |

 

I'm running HATS on Geronimo 2.2. I can start, stop, deploy and debug to the server from RAD.
 
I have a simple macro that goes to the host and fetches the screen back. From that, I created an IO. From the IO, I created the web service classes ...._Input_Properties.java and ...._Output_Properties.java as well as the main web service class, MyWebService.java
 
I followed the directions here to make a restful web service since I don't think you can create a restful webservice via the RAD WS Wizard for Geronimo, only SOAP.
 
I can hit the web service url but I get this exception:
 
com.ibm.hats.runtime.connmgr.ConnDiscarded: HPS5052 Cannot set up a connection to the host using the following session properties:
  {WFSharedConnection=false, screenSize=2, WFConnectionUniqueId=, WFEnabled=false, port=23, codePage=037, History=false, TNEnhanced=true, autoConnect=false, codePageKey=KEY_US, SESSION_QUIETMODE=true, sessionID=HodConn:#1, SSL=false, sessionType=1, host=, autoReconnect=false} (CONNECTION_ACTIVE)
 
I don't understand this. My runtime.properties in my .ear has the host, port (2023, not 23) etc. filled out. Those same items are in my .hco and the terminal has no problem using them to connect. Geronimo itself, under where the .ear is deployed has these same properties in runtime.properties
 
So, where is it getting these other, wrong "default" properties from? I don't know where else to look...
 
Thanks very much!
  • tmparker
    tmparker
    519 Posts
    ACCEPTED ANSWER

    Re: Wrong runtime.properties being used

    ‏2013-05-03T06:53:00Z  

    Anybody have any ideas?

    Thank you for any help!

    Just in case anyone else runs into this issue I'll post what I found about this.  What is happening is the ServletContext is not getting set correctly when you switch from using the standard Axis engine for normal web services to the CXF engine for the RESTful web services.  The internal API that exists for the Axis runtime allows me to get the servlet context dynamically at runtime.  However, the CXF engine doesn't provide a way to get the servlet context in the same way.  So I did some debugging and found a simple way that allows me to set the context in the code.

    Here is what they can change to try and make the web service run:
    After this line in their web service Java file where the helper object is created:
    TestMacro_Helper helper = new TestMacro_Helper();

    add the following code:
    helper.oServletContext = ((HttpServletRequest)wsContext
    .getMessageContext().get(Messa
    geContext.SERVLET_REQUEST)).ge tSession().getServletContext() ;

    I will look into this further to see if I can find a way to set this dynamically as I did for the normal Axis web services but for now hopefully this will solve the issue.

    Thanks

    Tim

  • Pathogen67
    Pathogen67
    27 Posts

    Re: Wrong runtime.properties being used

    ‏2013-04-22T21:59:52Z  

    Anybody have any ideas?

    Thank you for any help!

  • tmparker
    tmparker
    519 Posts

    Re: Wrong runtime.properties being used

    ‏2013-05-03T06:53:00Z  

    Anybody have any ideas?

    Thank you for any help!

    Just in case anyone else runs into this issue I'll post what I found about this.  What is happening is the ServletContext is not getting set correctly when you switch from using the standard Axis engine for normal web services to the CXF engine for the RESTful web services.  The internal API that exists for the Axis runtime allows me to get the servlet context dynamically at runtime.  However, the CXF engine doesn't provide a way to get the servlet context in the same way.  So I did some debugging and found a simple way that allows me to set the context in the code.

    Here is what they can change to try and make the web service run:
    After this line in their web service Java file where the helper object is created:
    TestMacro_Helper helper = new TestMacro_Helper();

    add the following code:
    helper.oServletContext = ((HttpServletRequest)wsContext
    .getMessageContext().get(Messa
    geContext.SERVLET_REQUEST)).ge tSession().getServletContext() ;

    I will look into this further to see if I can find a way to set this dynamically as I did for the normal Axis web services but for now hopefully this will solve the issue.

    Thanks

    Tim

  • Pathogen67
    Pathogen67
    27 Posts

    Re: Wrong runtime.properties being used

    ‏2013-05-16T14:49:27Z  
    • tmparker
    • ‏2013-05-03T06:53:00Z

    Just in case anyone else runs into this issue I'll post what I found about this.  What is happening is the ServletContext is not getting set correctly when you switch from using the standard Axis engine for normal web services to the CXF engine for the RESTful web services.  The internal API that exists for the Axis runtime allows me to get the servlet context dynamically at runtime.  However, the CXF engine doesn't provide a way to get the servlet context in the same way.  So I did some debugging and found a simple way that allows me to set the context in the code.

    Here is what they can change to try and make the web service run:
    After this line in their web service Java file where the helper object is created:
    TestMacro_Helper helper = new TestMacro_Helper();

    add the following code:
    helper.oServletContext = ((HttpServletRequest)wsContext
    .getMessageContext().get(Messa
    geContext.SERVLET_REQUEST)).ge tSession().getServletContext() ;

    I will look into this further to see if I can find a way to set this dynamically as I did for the normal Axis web services but for now hopefully this will solve the issue.

    Thanks

    Tim

    Thanks very much Tim!

  • tmparker
    tmparker
    519 Posts

    Re: Wrong runtime.properties being used

    ‏2013-05-29T16:11:24Z  

    Thanks very much Tim!

    I added a code change that should fix this problem in HATS 8.5 and future releases.  The fix will be available in the next fix pack once it's released.  I don't know when that is scheduled for at this time but you can use the workaround I showed above for now.

    Thanks

    Tim