[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1234... ] Julien Viet commented on JBPORTAL-1004: --------------------------------------- I agree the use case is interesting. One could look at developing customs CommandFactory and URLFactory to map URL back and forth with the portal objects available. I think it is quite easy to do. -- 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

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1234... ] Antoine Herzog commented on JBPORTAL-1004: ------------------------------------------ In the doc, it is said : rebuild the jboss portal to change the "portal" first item in the url. Could be possible to do it more simply ? when starting, we don't want to touch that. After trying the portal and build our environnement (cms configuration....) and new portlets, it seem heavy to rebuild from the begining. May be only make some documentation about how to change thing without rebuilding the whole thing ? (open another issue for this ?) -- 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

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ] Sverker Abrahamsson updated JBPORTAL-1004: ------------------------------------------ Attachment: new.files.zip -- 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

[ 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

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1234... ] Sverker Abrahamsson commented on JBPORTAL-1004: ----------------------------------------------- Well, the idea I had was that since a different web application is essentially a different context then create new contexts under the root would be the right way to go. If you have only one context then you can optimize it away, it doesn't add any value to the data model. Not that it matters though, I think it should be possible to map ContextPath to Portal instead. The only issue I can think of from the top of my head is how to decide which is the default portal if several portals is deployed in the same *-object.xml without parent references but that can be handled by being a bit picky when deploying. I don't really care which, the only thing I care about is the functionality in the end. -- 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

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1234... ] Sverker Abrahamsson commented on JBPORTAL-1004: ----------------------------------------------- I have uploaded a new patch which binds virtual hosts to the portal instead of context. -- 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

[ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_1239... ] dpocock commented on JBPORTAL-1004: ----------------------------------- What is the current status of this issue - is anyone working on a solution already? I've been looking at the following use case/potential solution: - a single JBoss server (or cluster of servers) - Apache2 with mod_jk as the front end - multiple `VirtualHost' definitions in Apache2 - each VirtualHost has a JkMount for /portal/* and /portal-core/* - Each virtual site has it's own entry page, template, etc. However, there is no isolation between the sites - a user can construct a URL that let's them see content from any of the sites through any of the VirtualHosts. This is a viable solution if all the sites are related. If the sites are not related (e.g. if one site is for a mining company and another site is for an environment group), then such a solution would be inappropriate. -- 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