https://issues.apache.org/bugzilla/show_bug.cgi?id=54386
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to comment #7)
> Well, the "classpath:/META-INF/resources/" identifier load the correct
> resources, as it is result of the current webapp-classloader. This is even
> better than use ant scripts (indeed pathological).
Well, perhaps it is more convenient for you. Adding something like this to
Tomcat doesn't make any sense because it's a deployment detail, not anything to
do with actually running the web application.
Think about it this way: you want to modify Tomcat so that it can launch a
webapp and dump a .zip file (or fill a directory) containing all your static
content. Then what are you going to do? scp it up to a CDN, right? Well, that's
going to have to be manual anyway, so what's the problem with
manually-generating the .zip file or content directory?
Or do you propose that Tomcat be fit with connectors to upload static content
to popular CDNs so you can just go to a JSP page and click "upload static
content" and have it work? Do you see how this is really not Tomcat's business,
now?
> To use an CDN for those static resources ANT must be installed then? Finally
> i must life with that fact then.
Ant must be installed on the host where you prepare your builds. How do you to
builds, today? If you use Java and you don't use Ant, then you probably use
Maven. I'm sure Maven can be taught to do this stuff, too -- I just don't know
how. If you use some other build process, then use that: unzipping files and
re-zipping them is not rocket science... you can do it with a 50-line shell
script if you have to. I just used Ant because it's awfully convenient.
Once the static content has been extracted, you can upload it to your CDN which
of course does not need Ant to be installed.
> Tomcat already have a deployment-process. To calculate what resources the
> defaultservlet would serve should not be a manual job of a person imo.
The point is that using Tomcat as a conflict-resolution system is ...
unnecessary. You could easily write a servlet that can dump your static
resources to a ZIP file and return it in the response. There is no need for
Tomcat to implement this functionality.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
