[Building Sakai] runtime config of log4j

John Bush john.bush at rsmart.com
Thu May 10 21:59:48 PDT 2012


yeah those pesky ops guys with all their freakin rules.  I guess it
really depends on how you expose your webservices, if you are careful
about how you open that up and manage access you can achieve the level
of security required.

Even outside of prod, I find this is helpful in dev and especially qa
when debugging isn't always as easy.

On Thu, May 10, 2012 at 5:41 PM, Matthew Jones <matthew at longsight.com> wrote:
> Hi John,
>
> I would occasionally use a jsp to change the log levels, I think it was this
> one:
> https://gist.github.com/943918
>
> The issue with that was I never made it "sakai protected" behind the
> requestfilter so I'd just use it on development servers. Your webservice is
> an interesting idea, but I think at many schools, operations still wouldn't
> want any administrator on the server to be able to change log levels
> whenever they want.
>
> The compromise we found useful at Michigan was to add a JMX that can be used
> to change the log level.
> https://source.sakaiproject.org/contrib/umich/logjmxservice/
>
> This needed to be on 2.7.x or 2.8 because the log4j in earlier versions was
> too old, but probably could just be dropped into core. It was pretty useful
> and let operations keep pesky developers out of these settings while still
> letting us adjust them when we really needed.
>
> Now if developers would just add more debug logging in places where it
> really could be useful!
>
> On Wed, May 9, 2012 at 1:11 AM, John Bush <john.bush at rsmart.com> wrote:
>>
>> this is bad ass, if you didn't know it you can change log levels at
>> runtime.  Add this to your SakaiScript.jws
>>
>>   public String adjustLogLevel(String sessionid, String packageName,
>> String level) throws AxisFault {
>>       Session session = establishSession(sessionid);
>>       if (!securityService.isSuperUser()) {
>>           LOG.warn("NonSuperUser trying to collect configuration: "
>> + session.getUserId());
>>           throw new AxisFault("NonSuperUser trying to collect
>> configuration: " + session.getUserId());
>>       }
>>       Properties props = new Properties();
>>       try {
>>
>>           // ok, yes I know this is fragile and totally tomcat
>> specific, but it works and avoids having to
>>           // configure up a new version of the log4j file somehow.
>> For sure this will break in tomcat 6, as
>>           // I think classloading is much different there.
>>           // This finds the log4j file in kernel common:
>>           // common/lib/sakai-kernel-common-x.x.x.jar!/log4j.properties
>>           InputStream configStream =
>>
>> this.getClass().getClassLoader().getParent().getParent().getParent().getResourceAsStream("log4j.properties");
>>           props.load(configStream);
>>           configStream.close();
>>           props.setProperty("log4j.logger." + packageName, level);
>>           LogManager.resetConfiguration();
>>           PropertyConfigurator.configure(props);
>>       } catch (Exception e) {
>>           e.printStackTrace();
>>       }
>>
>>       return "success";
>>   }
>>
>> The call the webservice via a browser or however you like to do that
>> (using an active sessionid of course):
>>
>>
>> http://localhost:8888/sakai-axis/SakaiScript.jws?method=adjustLogLevel&sessionid=9a17024e-7430-4d69-998e-83a6f7d35cab&packageName=org.springframework&level=DEBUG
>>
>> and viola you can adjust log level at runtime.   Pretty sweet.
>>
>> Try it out.
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>
>



-- 
John Bush
602-490-0470


More information about the sakai-dev mailing list