11 Replies Latest reply on May 17, 2007 1:55 PM by Jon Whitmore

    Please explain the Portal URL - /portal/portal

    Tom Hampton Newbie

      Version: JBoss Portal 2.2.1SP1

      When I install the portal and run it the URL looks like this

      http://localhost/portal/portal/default/default

      I understand part of this but not the second /portal

      http:///<context root>/<what's this>/<portal name>/<page name>

      I don't understand where the second /portal is comming from. It's causing real problems for me. I need to use the context root because I have other apps (not Java) running on my apache web server. So I can't forward all traffic to JBoss.

      If I change the context root / for the portal then the URL looks ok until I try to use some of the portlets (i.e. User Portlet). The links in the UserPortlet won't have /portal in them at all. Those link become /auth instead of /portal/auth. because the context root is gone. This means that I can't redirect /portal/* stuff from apache to JBoss. /portal/auth is not the only url that I've noticed so I'm affraid redirecting /auth/* isn't enough.

        • 1. Re: Please explain the Portal URL - /portal/portal
          Viet Master

          Hello,

          the second portal word is because the url decoder needs to make the different between :

          1/ page / window urls
          2/ cms content

          so 1 is mounted on /portal and 2 is mounted on / content.

          I don't understand your problem with apache. Could you explain more ?

          • 2. Re: Please explain the Portal URL - /portal/portal
            Tom Hampton Newbie

            I have a number of other applications (CGI/Perl, PHP, etc.) running on my apache web servers and use ModJk to loadbalance/forward certain URLs to my JBoss app servers.

            I have URL's like the following

            http://my.host.com/cgi_program
            http://my.host.com/php_program
            http://my.host.com/portal/myportal (this is what I want anyway)


            I have ModJk configurations like this

            JkMount /portal
            JkMount /portal/*


            This is to forward/loadbalance the portal request from apache servers to my jboss servers for scalability and failover. If I change the context root to "/" instead of "/portal" then that works fine for page URLs, but action urls such as the ones in the UserPortlet don't work. Apache isn't forwarding those request to the jboss server because the "/portal" context root is gone.

            Look at the URL for the "Standard Login" link in UserPortlet. If the context root is "/portal" (the default) this link looks like this.

            http://localhost/portal/auth/index.html.......


            If you change the context root to "/" then that link looks like this.

            http://localhost/auth/index.html.......


            Notice that the "/portal" appears nowhere.

            If I put port 8080 in my url explicitly and don't forward through apache it works, but I can't do that in production. The problem is that I have to have a context root to base my ModJk redirects on. I can't use a ModJK config that looks like this because that would redirect all URLs to the app servers and my other applications won't work.

            JkMount /
            JkMount /*


            My first thought was, "fine I'll just put /auth in the ModJk config" but that's not going to work either because /auth isn't the only URL. Look at the "create one" link in the UserPortlet.

            With context root /portal this is the URL

            http://localhost/portal/index.html......
            

            With context root / this is the URL

            http://localhost/index.html......


            If I don't have a context root then I can't do anything with this URL. It just doesn't work without a context root if I'm forwarding from apache.



            • 3. Re: Please explain the Portal URL - /portal/portal
              Tom Hampton Newbie

              On a separate but related thought.....


              Why don't you use a different context root for the CMS instead of mangling the URLs ?

              http://localhost/portal/....
              http://localhost/cms/....

              Just a thought.

              • 4. Re: Please explain the Portal URL - /portal/portal
                Tom Hampton Newbie

                Sorry to keep going on, but...


                Why is the CMS part of the portal ? It should be a completely separate product and not part of the portal.

                Content Management is a completely different thing from a Portlet Server.

                I don't see any value in coupling these two products.

                • 5. Re: Please explain the Portal URL - /portal/portal
                  Roy Russo Master

                   

                  "hamptont" wrote:
                  Why is the CMS part of the portal ? It should be a completely separate product and not part of the portal.

                  Content Management is a completely different thing from a Portlet Server.

                  I don't see any value in coupling these two products.


                  You are in the minority. The addition of the CMS to the portal was made, so people don't download a blank portal server and have nothing to see and interact with. A CMS is also a natural complement to a portal server, providing the ability to manage and serve content from a RDBM or FS.

                  If you don't want the CMS in your portal, then you can unplug it.

                  • 6. Re: Please explain the Portal URL - /portal/portal
                    Tom Hampton Newbie

                    Julian, I would love to hear your thoughts on this ?

                    I agree that it is useful to use a CMS along with a Portlet Server. I just don't see the need for the two to be the same product.

                    The CMS should be a service that can be used to implenent Portlets to manage the CMS. Why do those CMS management portlets need to be coupled to the Portlet Server to do that.

                    I think an architecture that decouples the CMS from the portal server but provides a set of CMS Management portlets would be better.

                    Why is it necessary to couple the CMS with the Portlet Server ? What extra functionality can you provide that couldn't otherwise be achieved ?

                    And if the CMS is so integral to the portal server why do you need a separate namespace for it. /context/portal vs. /context/cms. That looks like separate apps to me.

                    I don't care so much if the CMS is in the portal or not, since I'm not going to use it anyway. But I do care that the portal URLs are being mangled to get it there and that is causing me issues with a production system.

                    • 7. Re: Please explain the Portal URL - /portal/portal
                      Chris Laprun Master

                      Which steps did you follow to change the context?

                      • 8. Re: Please explain the Portal URL - /portal/portal
                        Tom Hampton Newbie

                        I did 2 things.

                        1) Changed deploy\jboss-portal.sar\portal-server.war\WEB-INF\jboss-web.xml file to change the value of the <context-root> from /portal to /

                        2) Removed the deploy\jbossweb-tomcat55.sar\ROOT.war directory.

                        Now #2 really shouldn't affect my config because I'm running apache in front of JBoss and forwarding the /portal/* URLs to JBoss so Apache handles all other request.

                        The problem is that I need the context root, which is the first /portal to configure apache. It's the second /portal that is causing problems, that's the new part and isn't consitently used. The links inside the UserPortlet don't have this second /portal but the page urls do.

                        • 9. Re: Please explain the Portal URL - /portal/portal
                          Viet Master

                          About the CMS integration with Portal. I agree with you that those are two separate concerns.

                          However JBoss Portal as a *product* ships with a CMS.

                          It is totally possible to remove the CMS and only keep the aggregation capabilities of the portal if you don't need CMS :

                          1/ delete portal-cms.war
                          2/ remove cms related stuff : portlets, instances and portlet windows

                          If you look at jboss-service.xml you can even change how the URL decoding is performed :

                          1/ remove the PrefixDelegatingCommandMapper
                          2/ set the PortalObjectCommandMapper as the next of the DefaultPortalCommandMapper service

                          this way you should have /a/b/c act the same as /portal/a/b/c

                          • 10. Re: Please explain the Portal URL - /portal/portal
                            salva vilarrasa Newbie

                            Hi julien,
                            Could you please explain in more depth how to remove the url checking in the services, or is there a solution for the apache redirection problem, I am experiencing the same issue as hampton, thanks for all folks!

                            • 11. Re: Please explain the Portal URL - /portal/portal
                              Jon Whitmore Newbie

                              Hello all

                              I am picking up where hamptont has left off. We are just finishing our upgrade to portal 2.4.1 and I'm addressing our issues with the context-root and URL prefixing/mapping. When I began the upgrade our context-root was '/' and our URLs were being prefixed with 'portal'. My goal is to make the context-root 'portal' and remove the prefixes all together. (Our motivation is still the same and explained above by hamptont.)

                              The below suggestion

                              If you look at jboss-service.xml you can even change how the URL decoding is performed :

                              1/ remove the PrefixDelegatingCommandMapper
                              2/ set the PortalObjectCommandMapper as the next of the DefaultPortalCommandMapper service

                              this way you should have /a/b/c act the same as /portal/a/b/c


                              Deals with classes found in 2.2. The seemingly relevant mbeans in 2.4 are listed here. You can see that I've tried setting the prefix to '/' but that hasn't lead to the desired result.

                              <mbean
                               code="org.jboss.portal.core.command.mapper.CommandFactoryDelegate"
                               name="portal:commandFactory=Delegate,prefix=portal"
                               xmbean-dd=""
                               xmbean-code="org.jboss.portal.common.system.JBossServiceModelMBean">
                               <xmbean/>
                               <attribute name="Prefix">/</attribute>
                               <depends
                               optional-attribute-name="DelegatingFactory"
                               proxy-type="attribute">portal:commandFactory=Delegating</depends>
                               <depends
                               optional-attribute-name="DelegateFactory"
                               proxy-type="attribute">portal:commandFactory=PortalObject</depends>
                               </mbean>
                               <mbean
                               code="org.jboss.portal.core.model.portal.PortalObjectURLFactory"
                               name="portal:urlFactory=PortalObject"
                               xmbean-dd=""
                               xmbean-code="org.jboss.portal.common.system.JBossServiceModelMBean">
                               <xmbean/>
                               <attribute name="Prefix">/</attribute>
                               <depends
                               optional-attribute-name="Factory"
                               proxy-type="attribute">portal:urlFactory=Delegating</depends>
                               </mbean>



                              Have I made a wrong assumption about the prefix attribute? (it would seem so) Is there an analogous edit to the XML as explained above for 2.2?

                              Any help appreciated, thanks.


                              Nollie