On Thu, Nov 9, 2017 at 3:33 PM, Gary Gregory <[email protected]> wrote:
> 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. > Finally got around to it. Done. Gary > > Gary > > >> >> Ralph >> > >
