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

Reply via email to