tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Jasper Improvements
Date Mon, 24 Feb 2014 22:58:39 GMT
On 24 February 2014 22:48, Mark Thomas <> 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

> >    - 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

> 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
> 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 <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message