JBoss Portal
  1. JBoss Portal
  2. JBPORTAL-1667

Problems for connecting a Weblogic 10 Portal WSRP Producer

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Rejected
    • Affects Version/s: 2.6 Final, 2.6.1 Final
    • Fix Version/s: 2.6.2 Final, 2.8 Final
    • Component/s: Portal WSRP
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Environment:
      Microsoft Windows 2000
      Sun JDK 1.5.06
      JBoss Portal 2.6.1 Final
      JBoss Portal 2.6 Final
    • Similar Issues:
      Show 10 results 

      Description

      I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message

      'ERROR [CallImpl] Call invocation failed with SOAPFaultException
      javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
      java.lang.NumberFormatException: null'

      I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

      When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.

      Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

      Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at WLP 10, but we are getting this exception.

      I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

      The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

      Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

      I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

      1. fullstacktrace.txt
        24 kB
        Mehmet Salgar
      2. jboss_portal_wlp_10_refresh_soap.txt
        7 kB
        Mehmet Salgar
      3. jboss_portal_wlp_92MP2_refresh_soap.txt
        8 kB
        Mehmet Salgar
      4. jboss_portal_wlp10_wsdl_binding_tcp_mon.txt
        77 kB
        Mehmet Salgar
      5. jboss_portal_wlp10_wsdl_tcp_mon.txt
        137 kB
        Mehmet Salgar
      6. jboss_portal_wlp92_wsdl_tcp_mon.txt
        137 kB
        Mehmet Salgar
      7. jboss_portal_wlp92MP_wsdl_binding_tcp_mon.txt
        76 kB
        Mehmet Salgar
      8. WLP_self_registration.txt
        6 kB
        Mehmet Salgar
      9. wsrp_2_servicedescription.txt
        156 kB
        Mehmet Salgar

        Activity

        Hide
        Chris Laprun
        added a comment -

        "The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem. Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves."

        Why do you assume that it's JBoss Portal's fault? I could make modifications to both our consumer and producer in such a way that it would not be conform to the specification and yet work perfectly well with each other but break with every other products out there... The fact that WLP works with itself is not conclusive evidence that its implementation is correct.

        That said I will look into the problem. Could you please attach the ServiceDescription sent by WLP 10?

        Show
        Chris Laprun
        added a comment - "The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem. Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves." Why do you assume that it's JBoss Portal's fault? I could make modifications to both our consumer and producer in such a way that it would not be conform to the specification and yet work perfectly well with each other but break with every other products out there... The fact that WLP works with itself is not conclusive evidence that its implementation is correct. That said I will look into the problem. Could you please attach the ServiceDescription sent by WLP 10?
        Hide
        Mehmet Salgar
        added a comment -

        You are probably right that this can be a Weblogic Bug or just compatiblity problem.

        If it is a Weblogic bug, we have an support account and I will report this as a bug to them.

        To be able to help you to understand the problem, I placed a tcp monitor between JBoss Portal 2.6.1 and WLP 10 and additional I monitored the SOAP Message traffic between JBoss - WLP during the Refresh operation in admin portlet.

        In file jboss_portal_wlp10_wsdl_tcp_mon.txt and jboss_portal_wlp10_wsdl_binding_tcp_mon.txt you can find the service descriptions. Please mark that with WLP 10 in default producer?wsdl it also contains definitions for wsrp-2.0 (WLP had implemented some feature of it). To be sure that is not causing the problem I explecitely used the url for version wsrp-1. I would also additionaly include the version wsrp-2 part of the wsdl.

        In the file jboss_portal_wlp_10_refresh_soap.txt, you can see the SOAP traffic between JBoss and WLP10.

        To be sure that JBoss is not acting differently between the JBoss 2.6.1 and WLP9.2MP2, I also monitored the messages between these versions.

        The files jboss_portal_wlp92_wsdl_tcp_mon.txt and jboss_portal_wlp92MP_wsdl_binding_tcp_mon.txt contains the service descriptions for WLP92 and jboss_portal_wlp_92MP2_refresh_soap.txt SOAP Messages in the refresh process.

        As far as I can see JBoss behaves identitically and for some reason WLP is not happy with the SOAP message:

        <?xml version="1.0" encoding="UTF-8"?>

        <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

        <env:Header/>

        <env:Body>

        <ns1:getServiceDescription xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

        <ns1:registrationContext xsi:nil="1"/>

        <ns1:desiredLocales>en-US</ns1:desiredLocales>

        <ns1:desiredLocales>en</ns1:desiredLocales>

        </ns1:getServiceDescription>

        </env:Body>

        </env:Envelope>

        which is identical between WLP92 and WLP10.

        So I don't know is Weblogic or JBoss has something problematic, but if you tell me this is Weblogic problem, I would force the issue there.

        Regards

        Show
        Mehmet Salgar
        added a comment - You are probably right that this can be a Weblogic Bug or just compatiblity problem. If it is a Weblogic bug, we have an support account and I will report this as a bug to them. To be able to help you to understand the problem, I placed a tcp monitor between JBoss Portal 2.6.1 and WLP 10 and additional I monitored the SOAP Message traffic between JBoss - WLP during the Refresh operation in admin portlet. In file jboss_portal_wlp10_wsdl_tcp_mon.txt and jboss_portal_wlp10_wsdl_binding_tcp_mon.txt you can find the service descriptions. Please mark that with WLP 10 in default producer?wsdl it also contains definitions for wsrp-2.0 (WLP had implemented some feature of it). To be sure that is not causing the problem I explecitely used the url for version wsrp-1. I would also additionaly include the version wsrp-2 part of the wsdl. In the file jboss_portal_wlp_10_refresh_soap.txt, you can see the SOAP traffic between JBoss and WLP10. To be sure that JBoss is not acting differently between the JBoss 2.6.1 and WLP9.2MP2, I also monitored the messages between these versions. The files jboss_portal_wlp92_wsdl_tcp_mon.txt and jboss_portal_wlp92MP_wsdl_binding_tcp_mon.txt contains the service descriptions for WLP92 and jboss_portal_wlp_92MP2_refresh_soap.txt SOAP Messages in the refresh process. As far as I can see JBoss behaves identitically and for some reason WLP is not happy with the SOAP message: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <ns1:getServiceDescription xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns1:registrationContext xsi:nil="1"/> <ns1:desiredLocales>en-US</ns1:desiredLocales> <ns1:desiredLocales>en</ns1:desiredLocales> </ns1:getServiceDescription> </env:Body> </env:Envelope> which is identical between WLP92 and WLP10. So I don't know is Weblogic or JBoss has something problematic, but if you tell me this is Weblogic problem, I would force the issue there. Regards
        Hide
        Mehmet Salgar
        added a comment -

        I had made little bit more research hier is a working request from WLP to register itself as WLP Producer.

        I am copying here part of the request.... Complete request I would add as attachement in file WLP_self_registration.txt for WLP10.

        <env:Body>

        <v1:getServiceDescription xmlns:v1="urn:oasis:names:tc:wsrp:v1:types">

        <v1:registrationContext xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>

        </v1:getServiceDescription>

        </env:Body>

        and here is the JBoss request

        <env:Body>

        <ns1:getServiceDescription xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

        <ns1:registrationContext xsi:nil="1"/>

        <ns1:desiredLocales>en-US</ns1:desiredLocales>

        <ns1:desiredLocales>en</ns1:desiredLocales>

        </ns1:getServiceDescription>

        </env:Body>

        Only differences I can see the expression of the namespace 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' in registrationContext command and '<ns1:registrationContext xsi:nil="1"/>'.

        And off course there is a difference of "true" to "1" could these can be the reason of the problem?????

        Show
        Mehmet Salgar
        added a comment - I had made little bit more research hier is a working request from WLP to register itself as WLP Producer. I am copying here part of the request.... Complete request I would add as attachement in file WLP_self_registration.txt for WLP10. <env:Body> <v1:getServiceDescription xmlns:v1="urn:oasis:names:tc:wsrp:v1:types"> <v1:registrationContext xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/> </v1:getServiceDescription> </env:Body> and here is the JBoss request <env:Body> <ns1:getServiceDescription xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns1:registrationContext xsi:nil="1"/> <ns1:desiredLocales>en-US</ns1:desiredLocales> <ns1:desiredLocales>en</ns1:desiredLocales> </ns1:getServiceDescription> </env:Body> Only differences I can see the expression of the namespace 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' in registrationContext command and '<ns1:registrationContext xsi:nil="1"/>'. And off course there is a difference of "true" to "1" could these can be the reason of the problem?????
        Hide
        Chris Laprun
        added a comment -

        Thanks a lot for all the hard work. Today was a holiday here in the US, I will look at everything in greater detail tomorrow. From what I see, I think the problem might indeed come from nil="1" as the problem reported by WLP is that the registrationHandle is null which seems to indicate that WLP considers that the registrationContext we give is NOT null. According to http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean, 1 is a valid value for xsi:nil (which is of simple datatype boolean). At this point, it seems to point to a BEA problem, especially since our consumer was working with WLP 9.2. I will try to confirm that this is the case.

        Show
        Chris Laprun
        added a comment - Thanks a lot for all the hard work. Today was a holiday here in the US, I will look at everything in greater detail tomorrow. From what I see, I think the problem might indeed come from nil="1" as the problem reported by WLP is that the registrationHandle is null which seems to indicate that WLP considers that the registrationContext we give is NOT null. According to http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean , 1 is a valid value for xsi:nil (which is of simple datatype boolean). At this point, it seems to point to a BEA problem, especially since our consumer was working with WLP 9.2. I will try to confirm that this is the case.
        Hide
        Mehmet Salgar
        added a comment -

        I think, I have a problem. Usage of '1' instead 'true' is dictated I guess with the org.jboss.portal.wsrp.core.GetServiceDescription class which is a generated proxy for JAX-RPC Standard Implementation (1.1.3, build R1).

        That means I would have no influence to change this from '1' to 'true'....

        I think, when WLP receives a number it automatically thinks this is RegistrationContext and try to convert to a handle

        Show
        Mehmet Salgar
        added a comment - I think, I have a problem. Usage of '1' instead 'true' is dictated I guess with the org.jboss.portal.wsrp.core.GetServiceDescription class which is a generated proxy for JAX-RPC Standard Implementation (1.1.3, build R1). That means I would have no influence to change this from '1' to 'true'.... I think, when WLP receives a number it automatically thinks this is RegistrationContext and try to convert to a handle
        Hide
        Chris Laprun
        added a comment -

        "That means I would have no influence to change this from '1' to 'true'.... "

        Indeed and neither do I. :/

        "I think, when WLP receives a number it automatically thinks this is RegistrationContext and try to convert to a handle "

        I don't think that's what is going on. The problem is probably more in the unmarshalling side of WLP which seems to fail to understand xsi:nil="1" == xsi:nil="true" which in turns causes it to not realize that the RegistrationContext we give it is null and therefore tries to look for the mandatory registrationHandle and when it doesn't find it (because it doesn't exist) throws the exception.

        You mentioned you have a Weblogic service account, try to see with them what they think.

        Show
        Chris Laprun
        added a comment - "That means I would have no influence to change this from '1' to 'true'.... " Indeed and neither do I. :/ "I think, when WLP receives a number it automatically thinks this is RegistrationContext and try to convert to a handle " I don't think that's what is going on. The problem is probably more in the unmarshalling side of WLP which seems to fail to understand xsi:nil="1" == xsi:nil="true" which in turns causes it to not realize that the RegistrationContext we give it is null and therefore tries to look for the mandatory registrationHandle and when it doesn't find it (because it doesn't exist) throws the exception. You mentioned you have a Weblogic service account, try to see with them what they think.
        Hide
        Chris Laprun
        added a comment -

        Closing this issue for now as it doesn't seem to be an issue on JBoss Portal's side. I will re-open it if needed.

        Show
        Chris Laprun
        added a comment - Closing this issue for now as it doesn't seem to be an issue on JBoss Portal's side. I will re-open it if needed.

          People

          • Assignee:
            Chris Laprun
            Reporter:
            Mehmet Salgar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: