On 24 February 2014 22:48, Mark Thomas <ma...@apache.org> wrote: > On 24/02/2014 02:10, Greg Wilkins wrote: > > The Jetty project has been considering switching to directly consume the > > apache version of Jasper JSP. > That said, there is a balance to be struck. If the changes are very > invasive or impact performance then I'd be less likely to support them. >
+1. Totally understand that only changes that make sense for the whole project should be pushed back. Even if it is not 100% of what we need, if it is close we might be able to consume by repackaging apache jars rather than rebuilding. > Are we just talking about Tomcat 8 here? > > For our part yes. We are only doing this for new releases and not back porting. > > - Modified JuliLog LogFactory to use a ServiceLoader to find an > > implementation of Log. Within the jetty project we add an impl of > the Juli > > Log that logs to the jetty log and we set that as a service in our > own jars > > META-INF. Note that judging by some of the comments in the classes, > there > > is not much desire to make logging discoverable? > > Discoverable in the Commons Logging sense of the term is not something I > am a fan of. At the risk of opening a huge can of worms would now be a > good time to review the choice to implement JULI? There have been some > significant changes in the Java logging landscape since then. Would now > be a good time to switch to log4j2, slf4j, something else? > > How would such a switch impact potential downstream users like Jetty? > I'm always amazed at how hard logging is for projects like ours that have to work with everybody else's logging expectations. At Jetty, we've chosen not to use any common logging framework, but to have a thin facade over stderr or slf4j - more or less what you've done with Juli. I know this can end up with a facade over a facade over a facade over a logging framework, but isn't there a golden rule that no problem cannot be solved without another layer of delegation? For us working with however you make Juli pluggable (even if it is replacing the LogFactory class), will be easier than if you pick a specific framework. > > The InstanceManagerFactory was intended to provide downstream users with > a way of injecting their own InstanceManager into Jasper. Is that not > sufficient? If not, what would you like to change? > Hmm will review that again and get back to you. > If there is interest here, then we could prepare a git pull request of our > changes (against the apache github clone), or would we need to remember our > svn and submit a diff against that? As long as a diff arrives in a format we can review it, it doesn't > really matter how that diff is generated or how it reaches is. Pull > requests should be fine. We need to get infra to hook them up to our dev > list. I'll try and create that request today. If we don't notice a PR > after a few days feel free to ping us on the dev list. > We'll prepare some PR in the next week. > If anyone from Jetty is going to be at ApacheCon, we are holding a > Tomcat Summit on the Friday. > I don't think so this year. thanks for your consideration. -- Greg Wilkins <gr...@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
