-
1. Re: Please explain the Portal URL - /portal/portal
julien1 Jul 19, 2006 9:56 AM (in response to hamptont)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
hamptont Jul 19, 2006 11:25 AM (in response to hamptont)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 followinghttp://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 thisJkMount /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 URLhttp://localhost/portal/index.html......
With context root / this is the URLhttp://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
hamptont Jul 19, 2006 11:29 AM (in response to hamptont)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
hamptont Jul 19, 2006 11:34 AM (in response to hamptont)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 Jul 19, 2006 1:14 PM (in response to hamptont)"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
hamptont Jul 19, 2006 2:40 PM (in response to hamptont)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
claprun Jul 19, 2006 6:14 PM (in response to hamptont)Which steps did you follow to change the context?
-
8. Re: Please explain the Portal URL - /portal/portal
hamptont Jul 19, 2006 7:38 PM (in response to hamptont)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
julien1 Jul 20, 2006 12:05 PM (in response to hamptont)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
shagy69 Oct 13, 2006 8:58 AM (in response to hamptont)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
nollie May 17, 2007 1:55 PM (in response to hamptont)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 suggestionIf 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