[jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal to support virtual hosts

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1234... ] Sverker Abrahamsson commented on JBPORTAL-1004: ----------------------------------------------- Ok, after a lot of working with the debugger and following the flow I've made the neccesary changes. It works beautifully now, if I may say it myself. The attached patch and files are on the 2.4 branch but shouldn't bee too hard to port to head once we've agreed on a few design questions that needs to be discussed. With this patch, if a war file contains an *-object.xml which creates a portal without any parent ref, then a new context is created and the virtual-host and context path settings of the war file is bound to it. The id of the context is either the application name given by jboss-app.xml or derived from the virtual-host and context path. I haven't updated Transient PortalObjectContainer yet with the new functionality, just added the method declarations to make it compile. Next, after the deployment had been taken care of, the request processing had to change slightly. The servername is fetched from the request in PortalServlet and stored in ServletRequestContext. The CommandFactory classes are updated so that doMapping gets the portalHost parameter. DefaultPortalCommandFactory caused a strange behaviour, if a link was wrong, e.g. spelled wrong or so, then it sent the request to the default portal. That resulted in that suddenly the default portal markup could appear in a middle of a page. I changed that so that if the CommandFactory chain failed to map the request, then a 404 response is sent via the new class ErrorResponseCommand. However, this more or less obsoletes this class. Instead CoreController should create a ErrorResponseCommand if cmd is null after passing through the CommandFactory chain. DelegatingCommandFactoryService was modified to send a request to / to PortalObjectCommandFactory, it's doing that by shortcutting the PathParser but I think it's ok. PortalObjectCommandFactory is modified to look up the context by using portalHost and portalContextPath. If a context can't be found using those data, then it tries to look up on just portalContextPath (for those cases where the webapp didn't specify any virual-host but just bind to the default name) and if still noting found then the default context is used. CMSObjectCommandFactory was modified to send a ErrorResponseCommand with 404 if it couldn't find the file specified which is the correct behaviour. As it was before the default portal could suddenly appear in the middle of the page which looked quite strange. Also, it now respond with code 500 if an internal error occurs. The same for StreamContentCommand. I noticed another thing, the file was first looked up in CMSObjectCommandFactory and then again in StreamContentCommand. I added a shortcut so that it could be passed along and hence eliminating the second lookup. A minor change had to be done on the security, in JACCPortalAuthorizationManager and JACCPortalAuthorizationManagerFactory as the configured roles have to be managed per context id (i.e. war file). The last big change was on how theme is handled. Before it just rendered an url, e.g. /portal-core/themes/phalanx/portal_style.css which didnt work because that path didn't exsist in my virtual-host. Instead I created a new CommandFactory which is bound to /theme so if I have a portal bound to the url http://portaltest.abrahamsson.com which use theme Npalanx then the stylesheet is loaded from http://portaltest.abrahamsson.com/theme/themes/phalanx/portal_style.css Julien and Roy, please read through these proposed changes and let me know what you think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira