Awesome - thanks again, Daan!

On Fri, Jan 9, 2015 at 2:36 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> to get back with my findings so far,
>
> The method I mentioned will work be it not that we have an explicit
> mention of log4j configuration in our web.xml. It states that
> 'log4j-cloud.xml' should be searched on the classpath. I deleted the
> extraneous file(s) from the hyperv plugin. This seems to solve the
> problem. There are several other ways of loading the configuration
> file in cloudstack. I haven't begun to consider consolidating them as
> this is a multi process system and it does make sense. Point of
> attention, though.
>
>
> Daan
>
> On Thu, Jan 8, 2015 at 3:41 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
> > It seems I had thrown away another log4j conf to get this working:( I
> > did a clean checkout and my trick isn't working anymore. keep you
> > posted
> >
> > On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski
> > <mike.tutkow...@solidfire.com> wrote:
> >> Great - thanks, Daan!
> >>
> >> On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> >> wrote:
> >>
> >>> I got around looking at this (under peer pressure @SBP;) There is a
> >>> property to maven jetty plugin:
> >>>           <systemProperties>
> >>>             <systemProperty>
> >>>               <name>log4j.configuration</name>
> >>>               <value>${project.build.directory}/log4j.xml</value> <!--
> >>> or something like this -->
> >>>             </systemProperty>
> >>>           </systemProperties>
> >>>
> >>> doing some final test before checking in. Not sure what changed but in
> >>> jetty and when. It seems to pick the first or last on the class path
> >>> or the lowest or highest hashed one without this set. dunno
> >>>
> >>> Daan
> >>>
> >>> On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> >>> wrote:
> >>> > Anshul,
> >>> >
> >>> > The hyperv log4j configuration should not be used at all.
> >>> >
> >>> > On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar
> >>> > <anshul.gang...@citrix.com> wrote:
> >>> >> Daan,
> >>> >>
> >>> >> I am not seeing extraneous logs on my dev setup other than thread
> which
> >>> is cleaning up expired async-jobs.
> >>> >>
> >>> >> You can safely change CONSOLE appender's threshold to INFO in hyperv
> >>> plugin  if you think that is causing the problem.
> >>> >> We will not lose much info which we want to show to user by this
> >>> change. And in any case it will be available in vmops.log.
> >>> >> CONSOLE appender's threshold is set to TRACE since the start of
> plugin.
> >>> >>
> >>> >> -----Original Message-----
> >>> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >>> >> Sent: Tuesday, December 30, 2014 11:10 PM
> >>> >> To: dev@cloudstack.apache.org
> >>> >> Subject: Re: CS MS Logging Level
> >>> >>
> >>> >> No, vmops.log does not seem to be getting spammed...just the
> console.
> >>> >>
> >>> >> On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> >>> >
> >>> >> wrote:
> >>> >>
> >>> >>> Mike,
> >>> >>>
> >>> >>> It doesn't spew to vmops.log anymore, right? It seems that the new
> >>> >>> jetty version interprets all the log4j/classpath differently and
> the
> >>> >>> one from the hyperv plugin takes precedence. I have been looking
> for a
> >>> >>> solution but haven't found one yet.
> >>> >>>
> >>> >>> On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski
> >>> >>> <mike.tutkow...@solidfire.com> wrote:
> >>> >>> > Hi,
> >>> >>> >
> >>> >>> > Does anyone know if the logging level or something like that
> changed
> >>> >>> > on
> >>> >>> the
> >>> >>> > management server in 4.6?
> >>> >>> >
> >>> >>> > It seems like it's spewing out tons of information to the console
> >>> >>> > these days.
> >>> >>> >
> >>> >>> > Thanks!
> >>> >>> >
> >>> >>> > --
> >>> >>> > *Mike Tutkowski*
> >>> >>> > *Senior CloudStack Developer, SolidFire Inc.*
> >>> >>> > e: mike.tutkow...@solidfire.com
> >>> >>> > o: 303.746.7302
> >>> >>> > Advancing the way the world uses the cloud
> >>> >>> > <http://solidfire.com/solution/overview/?video=play>*™*
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Daan
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> *Mike Tutkowski*
> >>> >> *Senior CloudStack Developer, SolidFire Inc.*
> >>> >> e: mike.tutkow...@solidfire.com
> >>> >> o: 303.746.7302
> >>> >> Advancing the way the world uses the cloud
> >>> >> <http://solidfire.com/solution/overview/?video=play>*™*
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Daan
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >>>
> >>
> >>
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud
> >> <http://solidfire.com/solution/overview/?video=play>*™*
> >
> >
> >
> > --
> > Daan
>
>
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Reply via email to