Shindig Java currently uses java.util.logging for all of its logging
(see https://issues.apache.org/jira/browse/SHINDIG-940). While I can
appreciate the desire to avoid unnecessary extra dependencies, JUL has
a number of well-known issues, that apply especially to our
(admittedly unusual) situation.
The root of the problem is that it doesn't support per-webapp
configuration very well. Other frameworks, notably log4j, let you
specify a logging configuration within your webapp that doesn't affect
anything else running in the same app server (or the app server
itself). JUL, as far as I know, only allows you to configure things
across the whole VM, which makes it difficult to ship a good default
configuration with a webapp on one hand, and difficult for
administrators to configure correctly on the other hand, since it can
be hard to get libraries that happen to be shared by multiple webapps
to log into the appropriate files for each app.
I know that the most common and recommended deployment configuration
would be to have Shindig running on its own dedicated server. Since
we're shipping packaged software, that wasn't a viable option for us.
Instead, we embed Shindig into our webapps. I'm aware of the security
issues this raises, with gadgets served from the same domain as the
app. Our compromise is to only allow users to add gadgets from an
administrator-controlled whitelist. Not ideal, but it's a trade-off we
need to make in order to ensure that our software can still be easily
installed and configured by a wide variety of administrators.
Since we've embedded Shindig in our webapps, we want its logging to go
into our applications' logs. Most of our customers run our
applications in a dedicated Tomcat instance, but not all of them. We
have some people who load several applications into one big fat
Weblogic or WebSphere container. Maybe it's crazy, but it's something
that we currently support. Unfortunately, this makes VM-global
configuration a problem, since if someone is running, say both JIRA &
Confluence in one webapp, and they each embed a copy of Shindig,
configuring the Shindig loggers at the VM level is going to send some
messages to the wrong file.
So I'm writing the list to ask:
1. Does anyone have any other suggestions for a better way to handle
this?
2. Would the Shindig committers be amenable to converting the logging
code over to log4j or slf4j? (http://www.slf4j.org/) An advantage of
slf4j is that it can be configured to use either java.util.logging or
log4j (or other logging frameworks) as the runtime logging
implementation.
If project members are open to converting to another logging
framework, I'd be happy to do the work of creating the patch and
attach it to a JIRA issue.
Cheers,
--
Tim Moore
