On Wed, Dec 5, 2018 at 5:36 AM Michael Osipov <micha...@apache.org> wrote:
>
> Am 2018-12-03 um 20:30 schrieb Mark Thomas:
> > Hi,
> >
> > I have been looking at [1]. This is a request to be able to specify a
> > URL for a WAR, including a URL that points to a WAR file packaged inside
> > a JAR. This request is in the context of embedded Tomcat.
> >
> > The embedded aspects are just part of this. Fixes would also be required
> > to the core Tomcat code.
> >
> > The Javadoc for Context indicates that a URL is acceptable for the
> > docBase. However, the code does not support this. The code expects a
> > file path (absolute or relative to appBase) that points to either a
> > directory or a WAR.
>
> How can a URL with a scheme be relative?!

E.g, 
jar:file:/path/to/application/bits/myapp.jar!/META-INF/hipshoot/embedded-catalina/webapps/site.war,
based on JAR URL [1].

[1] https://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html

>
> > I've been looking at the code and there are multiple places where the
> > assumption is made that the docBase is a file path. They are fixable but...
> >
> > I am wondering whether it would be better to fix this or to change the
> > Javadoc.
> >
> > In favour of fixing this:
> > - the code would match the intention as described in the Javadoc
> > - the requirements of [1] would be addressed
> > - loading a WAR from a URL offers a lot more flexibility
> >
> > In favour of changing the Javadoc
> > - there are multiple places that would need to be fixed
> > - loading a WAR from a URL broadens the attack surface if a malicious
> >    user can get to the configuration files
> > - there doesn't seem to be much demand for loading from a URL (one bug
> >    report with no activity and no votes in ~5 years)
> >
> > I'm somewhat on the fence on this one.
> >
> > Thoughts?
>
> I strive for simplicity, so I'd go with option 2. Moreover, we should
> clearly document which URL schemes are supported, e.g., file:// only.

It would help my use cases too if the fixing option is preferred
because I also struggled with the same issue before. I had to extract
war files from the application jar file and add webapps based on
webapp directories.
More specifically, I can remove my custom logic in
AppsDeployingTomcatEmbeddedServletContainerFactory.java [2,3] by
giving JAR URLs instead. Also, my solution was on a thin ice by
depending the file system to extract the wars as Chris mentioned in
the bugzilla ticket.

As a side note, most tomcat embedding frameworks assume single web
application (e.g, spring-boot), so they don't need to consider this
kind of use cases at all. My use case was to support multiple wars
with an embedded tomcat because my applications need to be separately
deployed on the same tomcat. If the tomcat-maven-plugin (or just
tomcat-plugin for other build systems?) can support more features of
Tomcat, it would be great.

Regards,

Woonsan

[2] 
https://bloomreach-forge.github.io/hipshoot/hipshoot-spring-boot-support/index.html
[3] 
https://github.com/bloomreach-forge/hipshoot/blob/develop/spring-boot-support/src/main/java/org/onehippo/forge/hipshoot/spring/boot/support/AppsDeployingTomcatEmbeddedServletContainerFactory.java

>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to