Forum Stats

  • 3,873,432 Users
  • 2,266,573 Discussions
  • 7,911,533 Comments

Discussions

Portal 10.2 wsrp interceptor

669362
669362 Member Posts: 80
edited Nov 10, 2008 1:12PM in WebLogic Portal
Hi,

how can i gracefuly handle connection error to the remote producer in order to display a custom message inside my remote portlet ?
Thx
Emmanuel

Best Answer

  • 650850
    650850 Member Posts: 843
    Answer ✓
    Hello again,

    One other thing to try would be to modify the WebContent\framework\features\proxyportleterror.jsp in the look and feel to change the way an error is displayed for a proxy portlet. This may give you the functionality you want without having to do anything with the interceptors.

    It has been pointed out that you may be receiving the 404 error during the WSDL fetch phase, which has no interceptor for it at this time. The WSDL fetch happens once when the consumer first tries to access the producer, and is cached after that. So if the producer is down when you start up your consumer and try and hit it the first time, the interceptors will not be able to catch this error. However, if the producer is up when the consumer starts and when the first portlet is retrieved from it, the interceptors would then work properly if the producer were to stop responding, We are looking at ways to improve this functionality for the next release, but that won't help you at the moment.

    The only work-around for the WSDL issue at this time would be to copy the producer's WSDL to a file in your webapp, then use file URLs when configuring the producer, pointing at your local copy of the WSDL. This is certainly not an ideal situation, as if the producer's WSDL changes you will still be pointing at a static copy of the old WSDL, but it would let you get to the point where your interceptor(s) would work every time.

    Kevin

Answers

  • 650850
    650850 Member Posts: 843
    Hello,

    The documentation at http://edocs.bea.com/wlp/docs102/federation/Chap-Interceptors.html#wp1031141 includes an example interceptor for handling faults. If you modify that example to move the code in the onFault() method into the onIOFailure() method, you should have the functionality you are looking for.
  • 669362
    669362 Member Posts: 80
    Hello,

    thx for your reply.
    I tried it but it seems that a request is sent to the producer BEFORE the interceptor is active. I get the following exception in my portlet a java.io.FileNotFoundException: Response: '404: Not Found' for url... and i'm not able to handle it with the interceptor.
    Any idea ? (the interceptor works fine when the producer is reachable)

    Emmanuel
  • 650850
    650850 Member Posts: 843
    Hello again,

    The onIOFailure() method of the interceptor should be getting invoked after the attempt to contact the producer is being made-- only after the contact fails will onIOFaiolure() get called.

    There are many different WSRP operations which can fail due to the producer not responding- InitCookie is the first operation that usually happens, to "set up" a session with the producer. You may need to implement the IInitCookieInterceptor interface and implement its onIOFailure() method, That way, you can detect the first failure, then track that and use the preInvoke() method on the GetMarkupInterceptor to abort the attempt to contact the producer at all.

    Kevin
  • 650850
    650850 Member Posts: 843
    Answer ✓
    Hello again,

    One other thing to try would be to modify the WebContent\framework\features\proxyportleterror.jsp in the look and feel to change the way an error is displayed for a proxy portlet. This may give you the functionality you want without having to do anything with the interceptors.

    It has been pointed out that you may be receiving the 404 error during the WSDL fetch phase, which has no interceptor for it at this time. The WSDL fetch happens once when the consumer first tries to access the producer, and is cached after that. So if the producer is down when you start up your consumer and try and hit it the first time, the interceptors will not be able to catch this error. However, if the producer is up when the consumer starts and when the first portlet is retrieved from it, the interceptors would then work properly if the producer were to stop responding, We are looking at ways to improve this functionality for the next release, but that won't help you at the moment.

    The only work-around for the WSDL issue at this time would be to copy the producer's WSDL to a file in your webapp, then use file URLs when configuring the producer, pointing at your local copy of the WSDL. This is certainly not an ideal situation, as if the producer's WSDL changes you will still be pointing at a static copy of the old WSDL, but it would let you get to the point where your interceptor(s) would work every time.

    Kevin
This discussion has been closed.