Moving a mail conversation with Julien back to the forum... anonymous wrote : 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973122#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...