[MAGNOLIA-233] single service deployment Created: 06/Dec/04 Updated: 11/Mar/05 Resolved: 11/Mar/05 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface, core |
| Affects Version/s: | 2.0 Final |
| Fix Version/s: | 2.1 Final |
| Type: | Improvement | Priority: | Major |
| Reporter: | Sameer Charles | Assignee: | Sameer Charles |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
It should be possible to deploy multiple magnolia instances under one container service |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
So, what is to do if you want to deploy magnolia as a war without changing server.xml? The point is the context of the web application. This means that every URL created by First you have to define the context as a prefix in the config section (this should not be a problem) Then there are two possibilities: In either ways the Magnolia team should support one of these. Ralf |
| Comments |
| Comment by Sameer Charles [ 06/Dec/04 ] |
|
that's exactly the point. Then there are two possibilities: we can wrap response but that will badly effects the performance , since some servlet containers like weblogic would load the response in memory before 2. Whenever you create a URL make sure to use this prefix (admintemplates and custom templates/paragraphs). we should have some virtual prefix URI which we can always ignore while aggregating the content, and as you said presentation logic must take care for war deployment I will create a build script but before that we need to figure out the best way to handle this URI mapping. |
| Comment by Ortwin Glueck [ 06/Dec/04 ] |
|
A servlet can determine the context string with ServletContext#getServletContextName(). But ideally a servlet should not produce any absolute URLs at all but only relative ones. |
| Comment by Sameer Charles [ 09/Feb/05 ] |
|
Fabrizio: I saw in your comments on svn that you already did something in this regard? could you please explain me what exactly you did? |
| Comment by Fabrizio Giustina [ 09/Feb/05 ] |
|
Yes, I started working on it and I think it will not be so hard to make magnolia fully work without to be bound to the root context. This is what need to be done and what I did till now:
With this changes magnolia is able to ork in subcontext but it still requires the mapping of the docroot/admindocroot directories in server.xml: |
| Comment by Fabrizio Giustina [ 09/Feb/05 ] |
|
well, another important step:
|
| Comment by Sameer Charles [ 09/Feb/05 ] |
why dont we simply add a spool servlet inside magnolia context which will take over all requests to
For cache handler its not a big deal, it could easily resolve path with or without context. - ll do that |
| Comment by Sameer Charles [ 10/Feb/05 ] |
(to switch off security on static resources add these to config/server/SecureURI deny list)
|
| Comment by Fabrizio Giustina [ 10/Feb/05 ] |
|
the spool servlet works perfectly for me. I fixed more gui elements, jsp, js, and page templates. Now magnolia WORKS when dropped in tomcat without any modification to server.xml, but there will probably be still some glitches or problems... the getContextPath() thing needed to be added in lots of places and in gui controls you actually can't know if the request has been set or not (all the controls extends ControlSuper which has a getRequest, and there are different contructor, with or without request). Another problem is that NPE are generally catched and ignored without any log so it's also difficult to see if an error has occurred (if something is missing in the page, probably it has). Anyway, it mostly works for me: we need to review and test everything accurately (and add log when an exception is swallowed)... the bigger part of the work is done |
| Comment by Andy [ 24/Feb/05 ] |
|
Hope this formats ok? Here is an example of how I have modified ALL of the config classes to make them context based. Once all of the config classes have been modified in this way it is pretty easy to follow through the compile process and make the additional changes. public class Listener { private static Logger log = Logger.getLogger(Listener.class); /** /**
/** return ((HashMap)cachedContextContent.get(context.getServletContextName())); /**
public static void reload(ServletContext context) { log.info("Config : re-loading Listener info for context: " + context.getServletContextName()); init(context); }/**
Content c = (Content) ipList.next(); try { Iterator it = c.getContentNode("Access").getChildren().iterator(); } catch (RepositoryException re) {} ipList = null; /**
} |
| Comment by Fabrizio Giustina [ 24/Feb/05 ] |
|
Andy, in the current svn trunk all the needed classes have already been modified adding the servletContext where appropriate. There is still some work to do on the front end part, but IHMO the java side is already ok. The problem actually is to fix and test all the javascript functions to make them context based (XmlHttpRequests are fixed, some few other js functions which load urls are not yet working). |
| Comment by Fabrizio Giustina [ 11/Mar/05 ] |
|
fixed in svn for 2.1. |