mirror of
https://github.com/Alfresco/acs-community-packaging.git
synced 2026-09-16 18:13:21 +00:00
Jon Cox
b65c1e6371
With this checking, Struts and other model-2 style apps can now be virtualized. However, I needed to upgrade the virt server Tomcat from 5.5.23 to 5.5.25, and create a custom build, which is pretty big; this a necesary evil, unfortunately (see "Gory details", below). That said, the build is no slower; it's just a slower 1st time download. WARNING: Developers should install this new virt server to see the fix. A normal "developer build" won't do that. Gory details: Patched build of Tomcat 5.5.25 for use as new virtualization server. This works around a problem with a "stock Tomcat" that occurs when a jsp is executed/included on behalf of a servlet. When Tomcat needs to do this, a code path is taken that unwraps the request object, thereby exposing mangled URIs/URLs/contexts to jsps. Interestingly, the authors of Tomcat seem to have been attempting to fix a different bug (c.f.: Tomcat's Bugzilla #30949), but ended up creating other problems by violating the wrapper abstraction. Because of where/how the core Tomcat classes do this, there was no good way to configure around it (nor wiggle out via classloader tricks). Thus we've got our own TomCat build now for the virt server (JonCat?). Prior to this custom build, if a JSP or Servlet asked what the context path was, they'd get a correct answer, but if the JSP was run on behalf of a servlet (which is often the case in Struts), it would see mangled context paths like "/$-1$mysite--alice$ROOT/" and URIs like "/$-1$mysite--alice$ROOT/index.jsp", which produce 404s. Unfortunately, the pristine Tomcat 5.5.25 code base and the custom binary are big: root/projects/3rd-party/src/apache-tomcat-5.5.25-src.zip ==> 7.7M apache-tomcat-5.5.25-virtserver-alfresco-1.1.zip ==> 13.8M Further, Tomcat's native build is slow & wants network access, neither of which I thought were acceptable. Therefore, I've created a pre-build apache-tomcat-5.5.25-virtserver-alfresco-1.1.zip in 3rd-party/distro, which the continuous.xml build now uses. The actual construction of a new Tomcat is fully automated via the root/project.xml target 'tomcat-virtserver' (comments in-line within project.xml), but that target is run by hand. The target then deposits the custom Tomcat (JonCat?) binary in 3rd-party/distro. Essentially, I'm just supplying a facade for certain API calls to work around the problem created by "stock Tomcat" unwrapping reverse proxied requests. Got that? Good! Note: Developers will also want to be sure they upgrade their virt servers by doing a real install. QA should also take note that this checkin will move us from Tomcat 5.5.23 ==> 5.5.25. git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@7025 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
22 lines
494 B
XML
22 lines
494 B
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<projectDescription>
|
|
<name>Web-Client</name>
|
|
<comment></comment>
|
|
<projects>
|
|
<project>3rd Party</project>
|
|
<project>MBean</project>
|
|
<project>Repository</project>
|
|
<project>Web-Framework</project>
|
|
</projects>
|
|
<buildSpec>
|
|
<buildCommand>
|
|
<name>org.eclipse.jdt.core.javabuilder</name>
|
|
<arguments>
|
|
</arguments>
|
|
</buildCommand>
|
|
</buildSpec>
|
|
<natures>
|
|
<nature>org.eclipse.jdt.core.javanature</nature>
|
|
</natures>
|
|
</projectDescription>
|