> On Nov 9, 2017, at 2:34 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Thu, Nov 9, 2017 at 1:49 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> Every module equates to another jar. I just don’t see why we need a jar >> for one class where a jar with 2 (as well as classes for other app servers) >> will serve equally as well. >> > > First, thank you for being patient here and continuing to entertain this > idea :-) So much can get lost in emails. > > The case of app servers is a great one because these are usually huge > complex beasts with sometimes lots of dependencies. > > I do not think we want to end up with a kitchen sink app server module. > From a developer's experience POV, I would never want my tooling (like > Maven) to end up downloading and configuring in a project jars from a bunch > of app servers and their dependencies. Especially since any single > application will likely only use a single app server (like the one I am > working on now, we are using Jetty and that's it.) > > Gary
I don’t think this is ever going to happen. As a user, you will download log4j-appserver as a dependency and everything else should be marked as provided. If you are using Jetty then the tomcat stuff will just be ignored. Frankly I am expecting that there won’t be many classes per app server. Typically, it is just what is needed to bind the app server’s logging to log4j. It is possible we might have lookup’s specific to the platform, but I would expect we would have an easy way to determine which ones are appropriate and which aren’t. Ralph
