[Deploying Sakai] Replacing Log4j with Logback

[John Bush]

We are about to roll out logstash, plus elasticsearch and kibana.  In
the case of logstash, its pretty good at reading any type of log
output, and in any cases adjusting formats and stuff like that is
pretty easy.  So I'm not so concerned about that.  But Splunk is
expensive so if someone is using that, maybe they should be concerned,
don't know much about it.

On Thu, May 30, 2013 at 9:11 AM, Noah Botimer <botimer at umich.edu> wrote:
> One more:
>
> Who's doing log analysis (e.g., Splunk) and would the patterns change enough to disrupt it?
>
> Thanks,
> -Noah
>
> On May 30, 2013, at 3:36 AM, John Bush wrote:
>
>> This sounds reasonable to me.  Three thoughts:
>>
>> 1. why not just fix the 3 imsglobal files and not deal with the JUL
>> thing.  Looks like a 10 minute affair to fix up that stuff
>>
>> 2.  If the migrator and all the code migration turns out to be
>> problemmatic could we fall back to just including jcl-over-slf4j.jar
>> instead of commons-logging.jar as a step forward ? We'd have to still
>> deal with LogConfigurationManager, but don't imagine that is terribly
>> hard, which gets me to next point.
>>
>> 3.  Would removing the ability to set log levels from sakai.properties
>> and moving it somewhere else entirely be such a bad idea.  It's not
>> runtime modifiable from there now.  Plus you can't control very much,
>> only set log level for packages, nothing fancy.
>>
>> On Wed, May 29, 2013 at 10:11 PM, Seth Theriault <slt at columbia.edu> wrote:
>>> On Thu, May 30, 2013 at 12:49 AM, John Bush <john.bush at rsmart.com> wrote:
>>>> Have you tried to use this migrator tool on all or part of the
>>>> codecase yet?  It looks like there's a bunch of things it trips up on
>>>> that have to be done manually, it would be helpful to know how
>>>> widespread or not the manual work is.
>>>
>>> I have tested it on parts of the codebase, and it works pretty much as
>>> advertised.
>>>
>>> There will need to be manual inspection for sure since if you have
>>> both JCL and JUL imports in the same file (yes, we have that!), you
>>> get 2 sets of SLF4J import statements. In addition, the string
>>> matching isn't always perfect:
>>>
>>> Index: citations/citations-osid/web2bridge/src/java/edu/indiana/lib/osid/base/repository/http/Logger.java
>>> ===================================================================
>>> --- citations/citations-osid/web2bridge/src/java/edu/indiana/lib/osid/base/repository/http/Logger.java
>>> (revision 125249)
>>> +++ citations/citations-osid/web2bridge/src/java/edu/indiana/lib/osid/base/repository/http/Logger.java
>>> (working copy)
>>> @@ -36,7 +36,7 @@
>>>        }
>>>
>>>        /**
>>> -        * Log a message
>>> +        * Logger a message
>>>         */
>>>        public void log(String entry)
>>>        throws org.osid.repository.RepositoryException
>>>
>>> Overall, I think it gives you a fast start on the tedium of the
>>> migration, but in the end, you still have to double-check it.
>>>
>>> Seth
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/production
>>
>> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>



-- 
John Bush
602-490-0470