You can solve it directly by committing. No need for patches in jira. The
jira issue we use just to keep track of work to be/done.
On Fri, Jan 29, 2010 at 1:52 AM, David Savage <david.sav...@paremus.com>wrote:
> Hi Niclas,
>
> Ok thx no problem I'll do as you suggest and raise a Jira. I tend to
> avoid j.u.l logging too but it's running in code we don't have the
> source to...
>
> I'll have a dig around in our old logging code, I think we j.u.l
> config working though we ideally want to move to pax logging as in the
> end how many logging frameworks does the world need ;) Maybe there's
> some patches I can put in the jira if I find anything useful.
>
> Regards,
>
> Dave
>
> On Thu, Jan 28, 2010 at 5:57 PM, Niclas Hedhman <hedh...@gmail.com> wrote:
> > Sounds like a bug.
> >
> > I have never used jdk logging in real systems, and the support for it
> > in Pax Logging was added long time ago "since we can".
> >
> > I suspect that the jdk logging also has some logging configuration
> > present that defaults to "to console" which perhaps need to be
> > disabled "somehow".
> >
> > Unfortunately, I am just about to move to another country, and won't
> > have cycles to look at this until the week starting with 13Feb or so.
> > Post a Jira ticket and I'll try to remember and have a look then.
> >
> > Cheers
> > Niclas
> >
> > On Thu, Jan 28, 2010 at 9:29 PM, David Savage <david.sav...@paremus.com>
> wrote:
> >> Hi there,
> >>
> >> I'm currently evaluating switching our internal log management code
> >> over to use pax logging but I'm seeing some odd behaviour wrt j.u.l
> >> handling and I wonder if it's a known problem or something I'm not
> >> doing?
> >>
> >> I've installed both the api and service bundles (version 1.4) and
> >> started both early in our boot process and there are definitely no
> >> other log providers around (except the j.u.l classes as they come from
> >> the system classpath). I'm then using the OSGi ConfigManager to set
> >> the following config options:
> >>
> >> log4j.rootLogger=info,R
> >> log4j.appender.R=org.apache.log4j.RollingFileAppender
> >> log4j.appender.R.File=paremus.log
> >> log4j.appender.R.MaxFileSize=100MB
> >> log4j.appender.R.MaxBackupIndex=1
> >> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> >> log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
> >>
> >> Now when new bundles are installed it successfully redirects all
> >> logging to paremus.log - except the j.u.l log. The j.u.l messages get
> >> sent to the log file but also get dumped to the console - and it's the
> >> console logging I'd like to clear up. During a quick browse of the
> >> source I notice in the code that the j.u.l logging is intercepted by
> >> adding a listener to the root ("") context - should this be sufficient
> >> to intercept all logging?
> >>
> >> Any help much appreciated.
> >>
> >> Regards,
> >>
> >> Dave
> >>
> >> _______________________________________________
> >> general mailing list
> >> general@lists.ops4j.org
> >> http://lists.ops4j.org/mailman/listinfo/general
> >>
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
> >
> > I live here; http://tinyurl.com/2qq9er
> > I work here; http://tinyurl.com/2ymelc
> > I relax here; http://tinyurl.com/2cgsug
> >
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
--
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.wordpress.com
http://sonatype.com - Sonatype - The Maven Company
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
