You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Tim Moore <tm...@atlassian.com> on 2009/06/22 23:46:50 UTC
Shindig's use of java.util.logging
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
Re: Shindig's use of java.util.logging
Posted by Tim Moore <tm...@atlassian.com>.
On Jun 25, 2009, at 5:32 AM, Vincent Siveton wrote:
> 2009/6/24 Tim Moore <tm...@atlassian.com>:
>> I see that Shindig used to be inconsistent about use of Commons
>> Logging vs.
>> JUL (https://issues.apache.org/jira/browse/SHINDIG-940) and that the
>
> IMHO SHINDIG-259 was the best solution and it could solve easily your
> problems today, but we decided to use only JUL impl.
> I am open to change the logging uses, as Shinidg remains backward
> compatible about JUL.
>
> I suggest you to create a patch and submit us. I am willing to
> revise it.
> If you have technical addons, dev@ is always open for you!
Thanks, Vincent,
I'll plan on writing a patch that *does not* change from JUL, but does
abstract Logger creation into a factory bound by Guice so that
integrators can replace it with another implementation. I'll post the
patch in a JIRA issue and we can continue discussion from there.
Cheers,
-- Tim
Re: Shindig's use of java.util.logging
Posted by Vincent Siveton <vi...@gmail.com>.
2009/6/24 Tim Moore <tm...@atlassian.com>:
> I see that Shindig used to be inconsistent about use of Commons Logging vs.
> JUL (https://issues.apache.org/jira/browse/SHINDIG-940) and that the
IMHO SHINDIG-259 was the best solution and it could solve easily your
problems today, but we decided to use only JUL impl.
I am open to change the logging uses, as Shinidg remains backward
compatible about JUL.
I suggest you to create a patch and submit us. I am willing to revise it.
If you have technical addons, dev@ is always open for you!
Cheers,
Vincent
Re: Shindig's use of java.util.logging
Posted by Tim Moore <tm...@atlassian.com>.
On Jun 24, 2009, at 3:57 PM, Kevin Brown wrote:
> On Wed, Jun 24, 2009 at 3:49 PM, Tim Moore <tm...@atlassian.com>
> wrote:
>
>>
>> On Jun 24, 2009, at 2:27 PM, Kevin Brown wrote:
>>
>> -Djava.util.logging.config.class=xxwhatever allows you to specify a
>>> completely different class to do the logging setup, and that class
>>> can
>>> load
>>> custom handlers. That's what we do internally.
>>>
>>>
>> That's not something we can control from within the webapp.
>
>
> What about System.setProperty?
Ah yeah I thought that the property would only be checked when the
LogManager is first created, but I see now that you can force it to
reload the config class by calling LogManager.readConfiguration(). The
property isn't really even necessary, since you can just call
readConfiguration with an input stream. Still, it would not be very
friendly for one app to hijack the logging config for the whole VM.
And as you mentioned, there's still the problem that loggers are
identified by class name, and not by instances of class objects, so
directing logging from the same class in different webapps to the
right place would still be an issue.
-- Tim
Re: Shindig's use of java.util.logging
Posted by Kevin Brown <et...@google.com>.
On Wed, Jun 24, 2009 at 3:49 PM, Tim Moore <tm...@atlassian.com> wrote:
>
> On Jun 24, 2009, at 2:27 PM, Kevin Brown wrote:
>
> -Djava.util.logging.config.class=xxwhatever allows you to specify a
>> completely different class to do the logging setup, and that class can
>> load
>> custom handlers. That's what we do internally.
>>
>>
> That's not something we can control from within the webapp.
What about System.setProperty?
>
>
> -- Tim
>
Re: Shindig's use of java.util.logging
Posted by Tim Moore <tm...@atlassian.com>.
On Jun 24, 2009, at 2:27 PM, Kevin Brown wrote:
> -Djava.util.logging.config.class=xxwhatever allows you to specify a
> completely different class to do the logging setup, and that class
> can load
> custom handlers. That's what we do internally.
>
That's not something we can control from within the webapp.
-- Tim
Re: Shindig's use of java.util.logging
Posted by Brian Eaton <be...@google.com>.
On Wed, Jun 24, 2009 at 2:27 PM, Kevin Brown<et...@google.com> wrote:
> -Djava.util.logging.config.class=xxwhatever allows you to specify a
> completely different class to do the logging setup, and that class can load
> custom handlers. That's what we do internally.
>
> I'm not sure how you'd disambiguate the shindig running in JIRA from the one
> running in confluence.
You could probably leverage the segregated webapp class loaders to
figure it out. Maybe initialize a singleton with the application
name, then have the logging configuration peek at that singleton.
Re: Shindig's use of java.util.logging
Posted by Kevin Brown <et...@google.com>.
On Wed, Jun 24, 2009 at 12:40 PM, Tim Moore <tm...@atlassian.com> wrote:
> On Jun 22, 2009, at 5:09 PM, Kevin Brown wrote:
>
> Putting aside our deployment scenario for now, do you have any thoughts
>>> specifically about the logging questions?
>>>
>>
>>
>> I don't have any strong opinions on the matter. I have never encountered a
>> situation where java.util.logging was inadequate. The performance kind of
>> sucks due to excessive synchronization, but the API itself doesn't seem
>> bad
>> enough to bother with an external dependency.
>>
>
> Unfortunately, we have encountered situations where JUL is inadequate. The
> problem isn't so much the API, but the configuration. It probably isn't an
> issue for centralized websites or software-as-a-service types of
> deployments, where you have complete control over the deployment
> environment, but it can be for packaged software that people expect to be
> able to just download and throw in an app server with a minimum of initial
> configuration. The java.util.logging framework seems to have been designed
> with only server administrators in mind, without offering any control over
> the initial configuration to application developers.
>
> So there are a few solutions that I can think of.
>
> Ideally, I'd prefer it if Shindig used slf4j. It's pretty lightweight and
> very flexible, and can easily be configured to log straight through to
> java.util.logging. It also has some nice API conveniences, such as message
> format strings that allow you to avoid string concatenation for messages
> that won't get logged at the currently configured level without having to
> wrap an if statement around it. It has a nice MIT-style license.
>
> But I can understand why you might not want to add an additional
> dependency. Another option is Apache Commons Logging. This is of course
> pretty common in Apache projects, and is already pulled into Shindig
> transitively by several other libraries, so it wouldn't mean adding a new
> dependency.
>
> I see that Shindig used to be inconsistent about use of Commons Logging vs.
> JUL (https://issues.apache.org/jira/browse/SHINDIG-940) and that the
> decision was to standardize on JUL. I found some discussion in the list
> archives (http://markmail.org/thread/54bvh2jfjacr52ph) and it sounds like
> a number of people prefer JUL, but it's not clear why. I know that commons
> logging has some known class loader issues, but those aren't hard to work
> around, and wouldn't affect the way Shindig itself is written. Also, slf4j
> provides a drop-in commons-logging replacement JAR that could be used by
> anyone that wants to avoid them entirely. In any case, JUL also has class
> loader issues of its own (e.g.,
> http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java).
>
> If you really want to stick with JUL, another solution is to allow logger
> construction to be overridden. If we could hook into the way that Logger
> objects are created, then we could reconfigure the handlers it uses.
> Unfortunately, AFAICT, loggers created through Logger.getLogger(String)
> don't provide a way to do that.
-Djava.util.logging.config.class=xxwhatever allows you to specify a
completely different class to do the logging setup, and that class can load
custom handlers. That's what we do internally.
I'm not sure how you'd disambiguate the shindig running in JIRA from the one
running in confluence.
> So it would require adding a LoggerFactory interface to Shindig that is
> injected by Guice. This is related to what Henning suggested in
> https://issues.apache.org/jira/browse/SHINDIG-259 but not quite the same;
> I'm not suggesting a wrapper interface around the Logger as a whole, just a
> factory to abstract its construction. The default implementation could just
> call Logger.getLogger but integrators could replace that with their own
> implementation if they need to.
>
> If any of these sound OK, I'm happy to provide the patch for whatever
> approach everyone can agree on. We're going to have to do one of these
> changes on our vendor branch regardless, but I'd really like to avoid
> diverging from the mainline any more than necessary.
>
> Cheers,
> -- Tim
>
Re: Shindig's use of java.util.logging
Posted by Tim Moore <tm...@atlassian.com>.
On Jun 22, 2009, at 5:09 PM, Kevin Brown wrote:
>> Putting aside our deployment scenario for now, do you have any
>> thoughts
>> specifically about the logging questions?
>
>
> I don't have any strong opinions on the matter. I have never
> encountered a
> situation where java.util.logging was inadequate. The performance
> kind of
> sucks due to excessive synchronization, but the API itself doesn't
> seem bad
> enough to bother with an external dependency.
Unfortunately, we have encountered situations where JUL is inadequate.
The problem isn't so much the API, but the configuration. It probably
isn't an issue for centralized websites or software-as-a-service types
of deployments, where you have complete control over the deployment
environment, but it can be for packaged software that people expect to
be able to just download and throw in an app server with a minimum of
initial configuration. The java.util.logging framework seems to have
been designed with only server administrators in mind, without
offering any control over the initial configuration to application
developers.
So there are a few solutions that I can think of.
Ideally, I'd prefer it if Shindig used slf4j. It's pretty lightweight
and very flexible, and can easily be configured to log straight
through to java.util.logging. It also has some nice API conveniences,
such as message format strings that allow you to avoid string
concatenation for messages that won't get logged at the currently
configured level without having to wrap an if statement around it. It
has a nice MIT-style license.
But I can understand why you might not want to add an additional
dependency. Another option is Apache Commons Logging. This is of
course pretty common in Apache projects, and is already pulled into
Shindig transitively by several other libraries, so it wouldn't mean
adding a new dependency.
I see that Shindig used to be inconsistent about use of Commons
Logging vs. JUL (https://issues.apache.org/jira/browse/SHINDIG-940)
and that the decision was to standardize on JUL. I found some
discussion in the list archives (http://markmail.org/thread/54bvh2jfjacr52ph
) and it sounds like a number of people prefer JUL, but it's not clear
why. I know that commons logging has some known class loader issues,
but those aren't hard to work around, and wouldn't affect the way
Shindig itself is written. Also, slf4j provides a drop-in commons-
logging replacement JAR that could be used by anyone that wants to
avoid them entirely. In any case, JUL also has class loader issues of
its own (e.g., http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java)
.
If you really want to stick with JUL, another solution is to allow
logger construction to be overridden. If we could hook into the way
that Logger objects are created, then we could reconfigure the
handlers it uses. Unfortunately, AFAICT, loggers created through
Logger.getLogger(String) don't provide a way to do that. So it would
require adding a LoggerFactory interface to Shindig that is injected
by Guice. This is related to what Henning suggested in https://issues.apache.org/jira/browse/SHINDIG-259
but not quite the same; I'm not suggesting a wrapper interface
around the Logger as a whole, just a factory to abstract its
construction. The default implementation could just call
Logger.getLogger but integrators could replace that with their own
implementation if they need to.
If any of these sound OK, I'm happy to provide the patch for whatever
approach everyone can agree on. We're going to have to do one of these
changes on our vendor branch regardless, but I'd really like to avoid
diverging from the mainline any more than necessary.
Cheers,
-- Tim
Re: Shindig's use of java.util.logging
Posted by Kevin Brown <et...@google.com>.
On Mon, Jun 22, 2009 at 4:41 PM, Tim Moore <tm...@atlassian.com> wrote:
>
> On Jun 22, 2009, at 3:05 PM, Kevin Brown wrote:
>
> 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?
>>
>
> We don't guarantee domain isolation, and that risk is a trade-off we have
> to make. This is why we make administrators white-list allowed gadgets.
> We're trying to be very clear with our customers that gadgets running in our
> containers should not be considered any safer than server-side plugins. We
> have to assume that the administrators of one application trust the
> administrators of any other applications running in the same container. If
> that's not the case, then there are definitely far bigger problems that
> could arise. Other than gadgets, server-side plugins could steal cookies.
>
> In practice, that's not usually a huge concern. The administrators are
> nearly always the same people.
>
> 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.)
>>
>
> It's something we have considered as an option for administrators who want
> to trade the increased complexity for added security. Even if we do decide
> to go that route, we really need to have a simple, single-WAR file
> installation option, for evaluators if nobody else. We want something that
> can start up and run with a minimum of configuration needed. That's how the
> software has worked for years, and we'd really be very reluctant to change
> that to enable gadget support.
What about treating the gadget server the same way that you treat confluence
or JIRA themselves? Instead of the 'embedding', just have a configuration
option that points the products at the gadget server, if there is one. This
would let you keep your existing deployment setup, and the only people who
would have any extra work would be those who want to run gadgets.
>
>
> Putting aside our deployment scenario for now, do you have any thoughts
> specifically about the logging questions?
I don't have any strong opinions on the matter. I have never encountered a
situation where java.util.logging was inadequate. The performance kind of
sucks due to excessive synchronization, but the API itself doesn't seem bad
enough to bother with an external dependency.
>
>
> -- Tim
>
>
>
Re: Shindig's use of java.util.logging
Posted by Tim Moore <tm...@atlassian.com>.
On Jun 22, 2009, at 3:05 PM, Kevin Brown wrote:
>> 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?
We don't guarantee domain isolation, and that risk is a trade-off we
have to make. This is why we make administrators white-list allowed
gadgets. We're trying to be very clear with our customers that gadgets
running in our containers should not be considered any safer than
server-side plugins. We have to assume that the administrators of one
application trust the administrators of any other applications running
in the same container. If that's not the case, then there are
definitely far bigger problems that could arise. Other than gadgets,
server-side plugins could steal cookies.
In practice, that's not usually a huge concern. The administrators are
nearly always the same people.
>> 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.)
It's something we have considered as an option for administrators who
want to trade the increased complexity for added security. Even if we
do decide to go that route, we really need to have a simple, single-
WAR file installation option, for evaluators if nobody else. We want
something that can start up and run with a minimum of configuration
needed. That's how the software has worked for years, and we'd really
be very reluctant to change that to enable gadget support.
Putting aside our deployment scenario for now, do you have any
thoughts specifically about the logging questions?
-- Tim
Re: Shindig's use of java.util.logging
Posted by Kevin Brown <et...@google.com>.
On Mon, Jun 22, 2009 at 2:46 PM, Tim Moore <tm...@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
>
>