On Mon, Jun 22, 2009 at 2:46 PM, Tim Moore <tmo...@atlassian.com> wrote:
> 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. I think you're going to have bigger problems than logging with this setup. How do you guarantee domain isolation? How can I be sure that the gadgets running in JIRA can't be attacked by gadgets running the confluence version? > > > So I'm writing the list to ask: > > 1. Does anyone have any other suggestions for a better way to handle this? Have you tried packaging shindig as a dedicated app rather than 'embedding' it? This might complicate your configuration a bit, but it would ensure that you had just one copy of shindig running, even if it serviced multiple containers (JIRA, confluence, etc.) > > > 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 > >
