12 Replies Latest reply on Jun 30, 2008 7:38 AM by fbrubbo

    Two WSRP question

    fbrubbo

      I'm pretty new with JBoss Portal. Actually, I'm also pretty new with Portlets and WSRP. So, If I'm asking something stupid, please fell free to warn me. :)

      My company is planning to migrate an in house implementation of remote portlets to WSRP. Because of that, we are experimenting many different solutions and jboss portal is one of them.

      Question 1:
      I'm getting an exception with the following url:
      wsrp_rewrite?.../wsrp_rewrite&param1=value1&param2=value2
      the exception says something like: ".. does not end with /wsrp_rewrite"

      The thing is, in wsrp spec v1 I did not find anything that disallow this kind of URL. Actually, what I want from the consumer it to rewrite part of the URL (excluding the parameters).

      There is a way to do that? Is it an issue?
      I've tested it in openportal solution and it works fine there.

      Question 2:
      I saw that Jboss portal bridge does not support struts framework. What are you guys using to migrate struts applications to portlets in Jboss portal environment? apache struts-bridge? is it stable?

      thanks a lot,
      Fernando

        • 1. Re: Two WSRP question
          claprun

          According to the specification:


          All portlet URLs (i.e. those the Consumer needs to rewrite) are demarcated in the markup by a token (wsrp_rewrite) both at the start (with a "?" appended to clearly delimit the start of the name/value pairs) and end (proceeded by a "/" to form the end token) of the URL declaration.


          The URLs that are targeted for rewrite are portlet URLs, not arbitrary ones. As a result, they have to follow a specific format and cannot handle arbitrary parameter passing. Note also that you shouldn't have to worry about generating any such URLs as the producer should take care of this for you.

          Could you specify the use case a little bit?

          As for question 2, we recommend using the Apache Struts bridge. However, the Struts action model does not port well to the portlet world so you might experience problems with it, depending on your application...

          • 2. Re: Two WSRP question
            fbrubbo

            Hi..
            First of all, thanks for your response

            About the url..
            I have the wsrp_rewrite? .. /wsrp_rewrite in that url. I just want to append some parameter in it. In our app, we have many URLs that are built by JS. How can I append extra parameters in it?

            Also, I could not make work a submition of a form using method GET (Only using POST works for me).


            We use use an in house solution for remote portlets. Actually, we have a portlet adapter that opens a http connection with the back end. In the back end we have many different frameworks being used, but most of them are using struts.

            Actually, we do not need a portal to do that, we could use a framework to publish our apps as WSRP producer. The thing is, I only know a solution from IBM to do that. Moreover, this solution is for the WAS 6.1 and we have WAS 5.1-6.0, Tomcat and .Net as producers.

            Do you have/know some solution/framework to publish a normal web app as WSRP producer?

            Thanks in advance
            Fernando

            • 3. Re: Two WSRP question
              claprun

              For the URLs, the URLs that are being rewritten should be under the control of the producer... I'll see what is feasible but I would recommend avoiding manipulating URLs directly like that. Moreover, it is likely that the state that is passed around with the parameters should actually be in the navigational state.

              We currently do not support forms using the GET methods in WSRP.

              I do not know any solution to publish a normal web app as a WSRP producer. I am not sure that it's possible to have a generic solution to that problem.

              • 4. Re: Two WSRP question
                fbrubbo

                About the URL
                The problem here is that we are not creating new applications. we are planning to migrate them and this kind of code already exists in our pages.
                So, We need as less effort as possible.

                About wsrp producer
                Yes.. I took a better look on IBM product and it exposes JSR-168 portlets. Sorry.

                WSRP only take place in Jboss Portal or it is in Portlet Container as well?

                Thanks

                • 5. Re: Two WSRP question
                  claprun

                  URLs: I will see what I can do...

                  Portlet container: we are planning on extracting WSRP so that it only depends on Portlet Container. However, at this point, WSRP is only available in Portal. Note also that Portlet Container is NOT supported, only Portal is.

                  • 6. Re: Two WSRP question
                    fbrubbo

                    Thanks for your quick answer.

                    About the URL.
                    In openportal it works with both
                    wsrp-rewrite? ... /wsrp-rewrite&param1=value1&param2=value2
                    and
                    wsrp-rewrite? ... &param1=value1&param2=value2/wsrp-rewrite

                    I know the second one is incorrect according wsrp spec.. but WebSphere WSRP only support the second one.

                    Again,
                    Thanks

                    • 7. Re: Two WSRP question
                      claprun

                      I'll add this to the list of things allowed by the relaxed validation mode (which I still need to document).

                      • 8. Re: Two WSRP question
                        claprun

                        Could you please specify your use case in greater details so that I can see how to best address it (as I am still not clear about what you are trying to accomplish)?

                        • 9. Re: Two WSRP question
                          fbrubbo

                          Hi Chris

                          At few months ago I've started to work in a Portal project. In this project, we have a large number of applications that are accessed remotely by a portal adapter. As I told you before, we have an in house solution that uses http connection to access the backend applications.

                          We are starting to develop our new portlets using WSRP and we are thinking to migrate the current ones. For that, we are working in a prof-of-concept checking different vendors and configurations to see which one fits better our necessity. Finished that POC, we will need point out a portal vendor as our preferred solution for WSRP producer.

                          Actually, we would like that every new application be developed as WSRP producer, but we have found that things are not so simple as it seems to be. Unfortunately, WSRP do not work well in our current reality, which is different vendors for consumer and producer.

                          Currently we have WPS 5.1 (using portlet adapter http connections) accessing apps from WPS 5.1, WPS 6.0, WPS 6.1, Tomcat, .Net and some php apps. For WSRP we have WPS 5.1 and WPS 6.0 as consumer, and NetUnit as producer.

                          Thanks,
                          Fernando

                          • 10. Re: Two WSRP question
                            fbrubbo

                            only a little fix.

                            Currently we have WPS 5.1 (using portlet adapter http connections) accessing apps from WAS 5.1, WAS 6.0, WAS 6.1, Tomcat, .Net and some php apps. For WSRP we have WPS 5.1 and WPS 6.0 as consumer, and NetUnit as producer.

                            thanks

                            • 11. Re: Two WSRP question
                              claprun

                              Implemented in SVN.

                              • 12. Re: Two WSRP question
                                fbrubbo

                                Great,

                                I'll try it as soon as I can.

                                Thanks,
                                Fernando