Please explain the Portal URL - /portal/portal

[hamptont]

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.

[julien1]

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 ?

[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 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.

[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.

[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.

[roy.russo]

"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.

[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.

[claprun]

Which steps did you follow to change the context?

[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.

[julien1]

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

[shagy69]

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!

[nollie]

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