On Thu, Nov 9, 2017 at 3:32 PM, Ralph Goers <[email protected]> wrote:
> > > On Nov 9, 2017, at 2:34 PM, Gary Gregory <[email protected]> wrote: > > > > On Thu, Nov 9, 2017 at 1:49 PM, Ralph Goers <[email protected]> > > 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. > OK, I'll tuck in the Jetty code in log4j-appserver. Gary > > Ralph >
