On 03/08/2011 19:29, Adrian Stabiszewski wrote: >>> As I understand it, you have to add the version number after two >>> hashes (##). The version will then be compared as a String. >>> This scheme doesn't fit with my versioning system which uses Maven as >>> build system which uses a hyphen as version separator. >>> Is there some Interface in Tomcat I could implement to integrate my >>> version scheme? Some ContextVersionComparator? >> >> Do you want to change the ## separator or just how the comparison is done? >> The first is very unlikely to happen. There aren't that many characters > that >> can be used safely. >> >> The second might be possible but not per web application as the version >> determination happens much earlier in the process. > > Actually I would like to change both, the separator and the comparator. If > it would be possible to extract the logic which decides the version and > which compares the version into an interface, then I think it would be easy > define your own versioning scheme. When I think about it, I would only need > to change the "ContextVersionExtrator". The class would take the filename > and create a context name and a version number of it. > For example, if my war filename is "myproject-1.5" it would return > "myproject" and convert the version to some safe string like "105" to be > able to handle versions like 1.10 which would become "110".
Hmm. You should get the extension point in if the code isn't too ugly (I know I wrote the parallel deployment code but I haven't looked at it in almost a year and I don't recall exactly where that is extracted) but you certainly won't get that behaviour by default since "/myproject-1.5" is a perfectly valid context path. >>> 1. Allow setting the context name in the META-INF/context.xml of the >>> WAR file. >>> Something like >>> >>> <Context path=""></Context> >>> >>> (which is forbidden atm) would deploy the WAR as a ROOT context. >> >> Very unlikely to change due to the complications it causes with automated >> deployment. Come up with a solution that allows this without breaking > auto- >> deployment or making the code horribly complex then things get rather >> more likely. > > To be honest I favored this solution. Now I would even suggest to add the > version as an attribute of the Context tag like: > > <Context path="" version="1.05"></Context> > > This would reduce the need "for safe characters" in the filename. > > When you say if causes complications with automated deployment, what do you > mean by that? Does this happen when Tomcat finds a new WAR File in its > appBase? Yes. Details in the Context and Host docs. > Don't you think that Tomcat relies too much on filenames when it comes to > context names? No. The switch over to using just the file name was to avoid a host of problems around automated deployment associated with the approach that you are currently suggesting. The problem was mainly one of complexity. Dealing with all the various edge cases and conflicts got to the point where a simpler solution was required. The file name approach has been refined slightly (mainly around the extraction or not of context.xml files) but the fundamental basis has remained unchanged since it was first implemented and we haven't yet found a use case it can't meet. Some folks don't like the configuration required for their particular use case but that is a different issue. Alternative suggestions are welcome but they are going to have to stand up to scrutiny. > I think it is good to have some convention over > configuration, but I'm missing the configuration options here. I haven't seen you describe anything you can't do with the current scheme so far, just some things you would prefer to configure differently. If you can find a way to do what you want that doesn't cause a bunch of problems elsewhere (either for other users or in maintenance) then patches to achieve those changes are likely to find their way into the code base. As an aside, the only thing I am aware of you can't do with the current scheme is have a context path of "/ROOT" and you can do that if you define the context in server.xml. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
