Virtual hosts and multiple portal server instances

[sverker]

We have been discussing in the user forum about that we can't find out how to use JBoss Portal with virtual hosts. The threads can be found on the following url's:
http://jboss.org/index.html?module=bb&op=viewtopic&t=89005
http://jboss.org/index.html?module=bb&op=viewtopic&t=76777

I've come to the conclusion that it is simply not supported by JBoss Portal architecture to have it serving multiple virtual hosts, nor to run multiple instances of the portal server itself.

While running multiple instances of the portal server maybe isn't that high priority (isn't required by my applications at least), the ability to support virtual hosts is.

I'm willing to participate in an effort to solve this issue (or do it myself if nobody else is interested to help out) but I need some pointer of where to start. Which parts of JBoss Portal needs to be changed or enhanced to support this functionality?

[julien1]

Hello Servker,

I am not really aware of how virtual host works. How can you from the HttpServletRequest get the virtual host ID ?

If you can then it is fairly easy to propose a different assembly of CommandFactory that setup the page according to that ID.

Let me explain quickly how that works : The CoreController of JBoss Portal is a service that delegates to a set of CommandFactory objects that need to return a ControllerCommand object.

Those different CommandFactory service are wired in jboss-portal.sar/META-INF/jboss-service.xml to form a chain of responsability (see correspoding GOF pattern).

By default we propose an assembly that form the default way JBoss Portal turns request into page views. It is possible to either form a different chain of responsability or develop custom CommandFactory to implement your own behavior.

In particular one command of the portal is called RenderPageCommand and it just trigger a page view.

I advise you to look at the javadoc or download the source code of the portal. If you need further help don't hesitate.

[claprun]

I believe virtual hosts are implemented via the HTTP header Host, which allows for multi-homing.

[sverker]

I'm working on it. The first step was to take care of the deployment, I think that is taken care of now. JBossPortal has it's own way of request interception which is not how war files usually works. My implementation is that then a war is deployed with a *-object.xml which doesn't refer to a parent id, a new context is created which binds to the virtual-host and context path specified by the war. That way both the old JBossPortal way and the usual way a war works can be supported without any hassles.

Now I'm following the request flow to work out all the issues that is caused by a slightly different model. Supprisingly few so far but it's a bit complex to follow. For example I was struggeling a lot with an issue in the security interceptor which I haven't figured out yet but I have seen it happen also on a unmodified JBossPortal that suddenly it's not possible to do unchecked accesses and the only solution is to restart the app server.

[sverker]

Moving a mail conversation with Julien back to the forum...

Hi Sverker,

I found good ideas in your patch, however there are things that
prevent it to be integrated as is : it requires too many
modifications in the codebase that make jboss portal depend on that
solution.

What raise issues :

1/ retrieving metadata from the war file about the virtual host :
this is simply not portable and jboss portal is going to migrate to
environment agnosticity
2/ modifications of the portal object tables (context path addition) :
2.1/ make the solution depend on the environement (the fact that
there are context paths).
2.2/ will require an extra migration step from users.

I hope you can understand that.

I think we should take our time and discuss now how we can better
integrate your idea while remaining compatible with the main
objectives of the portal (i.e not depend on a particular
customization) as I think that it is a good feature for the project.
All of this for the 2.6 timeframe.

Hi Julien,
the purpose of those patches was not that they were a complete solution but to form examples of how to solve this isse and to get the discussion started.

To answer on your specific remarks below:
1. There are no standard way how the containers handle virtual host configuration. However, there are several other things that are not standardized neither, e.g. how deployments are handled etc, or even if they are standardized not all containers follow that. I believe that most likely you'll need to have some code specific for each container/application server that you want to support, you are currently tied to jboss/tomcat and it wouldn't be possible to deploy on jboss/jetty without additional adapter code. To retrieve virtual-host information could be part of that container-specific code.

Another approach could be to specify virtual-host as part of the *-object.xml file. While it's completely portable I find it a bit cumbersome to have to specify that information when it's already avalible in the container. Maybe the right approach is to use both, if the information can be retreived from container then use it otherwise use context information specified in *-object.xml file.

2. A major problem with JBoss Portal today is that it is an application and not an infrastructure component as it should be. It works fine for a single purpose such as e.g. the JBoss site where you have a number of sub-portals forming one site, but I can't use it for deploying a number of arbitrary portals. There are several reasons for that, one is the issue that we are discussing that virtual-host is not supported, another is that all portals run in the same security domain which is not generic, yet another (minor issue) is that you throw in a default portal which should instead be part of the portal-samples.war etc.

Forturnatly it turned out to be quite easy to extend the model slightly to contain virtual-host/context-path information which is neccesary to be able to map a request to the correct portal. The reason why I see that it should be bound to context instead of a portal is because of isolation, the portal container needs to be able to isolate portals which does not belong together while it still must be possible to build a site made of sub-portals like jboss.org. Just as the EJB container isolates two ear-files rom eachothers context, so must the portal contaier be able to do. Another example is how a servlet container provides separate contexts and isolation for different war files.

A benefit with this approach is that it gives the flexibility to both be able to have isolation between portals and to not have it (which is how it currently works).

2.1 I'm not sure I understand what you mean there. A web application always is bound to a context path, which is / for the root. It is either derived from the war name or specified in a jboss-web.xml (or application.xml of a enclosing ear).

2.2 What migration? The only thing needed is to create the table CONTEXT_PATH. Previous portals will continue to work just as before as they deploy to the default context and no old persisted data needs to be converted. That is btw something I consider a bit aqward in the current implementation, that you persist data from the deployments, which by nature is transient (which I assume is why you created the TransientPortalObjectContainer). The current implementation doesn't clean up neither so if I undeploy a portal component it's still in the ObjectNode tree.

[yxyang]

"sverker" wrote:

I've come to the conclusion that it is simply not supported by JBoss Portal architecture to have it serving multiple virtual hosts, nor to run multiple instances of the portal server itself.

While running multiple instances of the portal server maybe isn't that high priority (isn't required by my applications at least), the ability to support virtual hosts is.

JBoss portal does have a few limitations:

(1)default portal should be there as an example.
(2)Virtual host not supported.
(3)Navigation menu is urgly. Navigation portlet is so important that all deployments are needed.
(4)User portlet is not fully implemented yet... Example, once you update the profile, not any indication appear on the page. Nobody knows whether the update success or not until you try it out by logout/login.


But you can acheive the virtual host features or running multiple portal instance easily.

(1)I have running semi-virtual hosting on jboss. What i used to solve the problem is using "http redirect".
(2)i have my own generic nativation portlet. which itsown is a WAR DIRECTORY. You can enter the directory to modify the configurations anytime.
(3)I will rewrite the user portlet myself in the next few days.

yang

[theute]

"yxyang" wrote:
(3)Navigation menu is urgly. Navigation portlet is so important that all deployments are needed.
(4)User portlet is not fully implemented yet... Example, once you update the profile, not any indication appear on the page. Nobody knows whether the update success or not until you try it out by logout/login.

<...>

(2)i have my own generic nativation portlet. which itsown is a WAR DIRECTORY. You can enter the directory to modify the configurations anytime.
(3)I will rewrite the user portlet myself in the next few days.

1 - this is out of topic, we try here to agree on the concept of multi-host and its implementation within portal

2 - How comes we didn't receive your contribution on the navigation portlet and when will you be done with the user portlet enhancement and providing us with a patch ?

[yxyang]

i have no idea how to submit.

The navigation portlet is a standalone portlet package. how to submit as patch?

yang

[sverker]

Hi guys
I didn't receive much feedback on the virtual-host stuff. While I understand that it's not high priority for you to support virtual-hosts, I need to urgently solve this as I have some projects which has been on hold waiting for JBoss Portal (or similar component) but now I have to move on.

There are three alternatives:
1. Use JBoss Portal with my own modifications for virtual-host support and merge back later when eventually this issue is solved.

2. Dump JBoss Portal and use something else.

3. Work together with you guys to get virtual-host support implemented the correct way.

No 1 solves the problem temporarily but can potentially cause bigger problems later when migrating to mainstream release.

No 2 is possible but the alternatives I've been looking at I didn't like too much as they aren't properly integrated with the rest of the app server.

No 3 is preferable, but how can we move forward? I can write the code but need to communicate with you regarding how to design and integrate the support.

In http://jboss.org/index.html?module=bb&op=viewtopic&t=92151 Julien mentions namespaces. That the war file foo.war would be deployed to webapp:foo.default.default.

This would work, the namespace is like I used context in my proposal implementation. The virtual host details will then be bound to the webapp:foo namespace.

What do you think about that approach?

[julien1]

Could you explain why virtual host linked to a war file deployment ?

"sverker" wrote:
Hi guys
I didn't receive much feedback on the virtual-host stuff. While I understand that it's not high priority for you to support virtual-hosts, I need to urgently solve this as I have some projects which has been on hold waiting for JBoss Portal (or similar component) but now I have to move on.

There are three alternatives:
1. Use JBoss Portal with my own modifications for virtual-host support and merge back later when eventually this issue is solved.

2. Dump JBoss Portal and use something else.

3. Work together with you guys to get virtual-host support implemented the correct way.

No 1 solves the problem temporarily but can potentially cause bigger problems later when migrating to mainstream release.

No 2 is possible but the alternatives I've been looking at I didn't like too much as they aren't properly integrated with the rest of the app server.

No 3 is preferable, but how can we move forward? I can write the code but need to communicate with you regarding how to design and integrate the support.

In http://jboss.org/index.html?module=bb&op=viewtopic&t=92151 Julien mentions namespaces. That the war file foo.war would be deployed to webapp:foo.default.default.

This would work, the namespace is like I used context in my proposal implementation. The virtual host details will then be bound to the webapp:foo namespace.

What do you think about that approach?

[sverker]

Because the normal method in JBoss to specify virtual hosts (and context path) is through jboss-web.xml in a war file.

However, that doesn't mean that it has to be the only way to specify virtual hosts. I don't mind if there are other ways, they might be useful, as long as the normal JBoss method works.

[julien1]

ok, I was not sure of that.

I am looking forward now to add a different portal object tree for the dashboard feature.

It could be stored in parallel of the existing tree with a new set of tables or could be stored in the actual tables using some trick. My concern is that it does not bring schema change that requires migration step.

I tried to look back at the patches your proposed a while ago in the jira where you seemed to propose something like that. Do you think it is possible to hold "parallel" trees in the same tables or would it require a new set of tables ?

The biggest issue I see today is that the "path" column would conflict, for example :

"" (default actual context) + "a.b"

"a" ("a" context) + "b"

would have the same path value.

And today I don't see an alternative solution other than adding a new set of tables for the dashboard.

"sverker" wrote:
Because the normal method in JBoss to specify virtual hosts (and context path) is through jboss-web.xml in a war file.

However, that doesn't mean that it has to be the only way to specify virtual hosts. I don't mind if there are other ways, they might be useful, as long as the normal JBoss method works.

[julien1]

Hi Sverker,

I have added the portalHost idea from your patch to the codebase.

That way it gives to ppl that integrates using command factories the capability to leverage that information to return the appropriate command (like a specific portal for a specific virtual host).

[erich_lol]

Hi,

is it already planned to integrate support for supporting multiple virtual hosts with one portal container? For which release?

[lukin]

Hi, guys! Who can say clearly what is going on with virtual host feature implementation? I'm new to JBoss portal source, but it seems there's no such beast in in svn "trunk". Is something done already from last year when this tread started?