On Sun, Dec 9, 2018 at 3:45 AM Woonsan Ko <woon...@apache.org> wrote:
> On Sat, Dec 8, 2018 at 10:48 PM Rémy Maucherat <r...@apache.org> wrote: > > > > On Sat, Dec 8, 2018 at 2:37 AM Woonsan Ko <woon...@apache.org> wrote: > > > > > On Sat, Dec 8, 2018 at 3:35 AM Mark Thomas <ma...@apache.org> wrote: > > > > > > > > On 04/12/2018 22:22, Woonsan Ko wrote: > > > > > > > > <snip/> > > > > > > > > > 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. > > > > > > > > Note that if this is implemented then it is still going to require > > > > extraction to the file system and then deployment from the > filesystem. > > > > Given that limitation, is this still useful? > > > > > > Yes, it is very useful. Even if I mentioned "on a thin ice", every > > > cloud platform I know supports a file system to use for that anyway. > > > > > > > Aren't you supposed to use FarmWarDeployer ? > > I haven't had any requirement to use that yet. > My use cases have been so far in either category: (a) deploying > microservice-like pack as a whole -- not war separately but > embedded-tomcat pack as a whole, or (b) deploying a docker image to > docker-based platforms. > I have nothing against adding the feature (as long as I'm not doing it), but for the "microservice" cloud design, I would expect "small" (haha) self contained reproduceable images. If you pull the application from somewhere at runtime, then it's whatever micro or not and it can evolve, I added a package tool recently for images: https://github.com/apache/tomcat/tree/trunk/res/tomcat-maven Rémy
