Timestamps are in GMT/BST.
[1:43] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) has joined #duraspace
[1:57] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Quit: jonathangee)
[2:05] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) has joined #duraspace
[2:24] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Quit: jonathangee)
[6:42] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:42] -rajaniemi.freenode.net- *** Checking Ident
[6:42] -rajaniemi.freenode.net- *** Found your hostname
[6:42] -rajaniemi.freenode.net- *** No Ident response
[6:42] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:42] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:42] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:23] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[9:37] * eddies (~eddies@61.202-63-155.unknown.qala.com.sg) has joined #duraspace
[9:37] * eddies (~eddies@61.202-63-155.unknown.qala.com.sg) Quit (Changing host)
[9:37] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[9:51] * eddies1 (~eddies@bb121-6-75-93.singnet.com.sg) has joined #duraspace
[9:51] * eddies1 (~eddies@bb121-6-75-93.singnet.com.sg) Quit (Changing host)
[9:51] * eddies1 (~eddies@unaffiliated/eddies) has joined #duraspace
[9:54] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 240 seconds)
[10:14] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:14] * eddies (~eddies@61.202-63-155.unknown.qala.com.sg) has joined #duraspace
[10:14] * eddies (~eddies@61.202-63-155.unknown.qala.com.sg) Quit (Changing host)
[10:14] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:19] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[13:12] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) has joined #duraspace
[13:22] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:52] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[14:52] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[14:52] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[15:11] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[17:29] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Quit: jonathangee)
[19:01] * bofmouais (8dd9612d@gateway/web/freenode/ip.141.217.97.45) has joined #duraspace
[19:32] * bofmouais (8dd9612d@gateway/web/freenode/ip.141.217.97.45) Quit (Ping timeout: 245 seconds)
[19:54] * jrgriffiniii (~chatzilla@139.147.64.187) has joined #duraspace
[19:59] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:01] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[20:02] <PeterDietz> IS there a DSpace Dev meeting soon?
[20:04] <mhwood> There is if we do one. Tim is still out.
[20:04] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[20:05] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:05] <PeterDietz> If there's no agenda, I would always love to talk about DSpace APIs
[20:09] <mhwood> OK?
[20:10] <hpottinger> I'm here, people keep trying to talk to me in meatspace, so I'm distracted
[20:10] <aschweer> I'm here too but like hpottinger slightly distracted by other things
[20:13] <jrgriffiniii> What would be required to become a DSpace committer?
[20:13] <jrgriffiniii> We're currently experiencing some significant issues with our installation of 1.6.2, and it relates to an issue which has not been resolved
[20:14] <jrgriffiniii> It has been suggested at my institution that I look to resolve the issue by modifying the source code
[20:14] <PeterDietz> jrgriffiniii: Contributions are always welcome.
[20:14] <hpottinger> jrgriffiniii: https://wiki.duraspace.org/display/DSPACE/Committer+Nominations
[20:14] <kompewter> [ Committer Nominations - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Committer+Nominations
[20:14] <jrgriffiniii> I'm hesitant to undertake this without contacting the primary developers first
[20:14] <aschweer> jrgriffinii: you don't actually need to be a committer to modify the source code. You could have local customisations or you could contribute your fix back to us, for example via a pull request
[20:15] <aschweer> is your problem filed in Jira, the DSpace bug tracker? If so, do you happen to know its issue ID?
[20:15] <hpottinger> to give a bit of context, I chatted with jrgriffiniii yesterday, regarding this issue: https://jira.duraspace.org/browse/DS-675
[20:15] <kompewter> [ [#DS-675] XMLUI doesn't start if the error level in the log4j.properties is set to DEBUG - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-675
[20:15] <kompewter> [ https://jira.duraspace.org/browse/DS-675 ] - [#DS-675] XMLUI doesn't start if the error level in the log4j.properties is set to DEBUG - DuraSpace JIRA
[20:15] <jrgriffiniii> We're actually encountering more serious issues
[20:16] <jrgriffiniii> PDF's are served from DSpace irregularly, the problem seems to lie with Apache Cocoon
[20:16] <jrgriffiniii> I can't determine where the problem lies without that log
[20:17] <mhwood> Ah, the old "layered problems" problem.
[20:17] <jrgriffiniii> Unfortunately, when the cache is disabled, all is well except for an issue in which protocol.xml cannot be retrieved from the JNDI for the advanced search
[20:18] <hpottinger> based on our discussion yesterday, I realized that 675 needed to be flagged in our workflow as "needs volunteer" so I did so.
[20:20] <jrgriffiniii> Because our problem (in which protocol.xml cannot be retrieved for the "advanced-search" URI is specific to 1.6.2), I'm uncertain as to whether I should bother modifying the source code, and just update to a more recent version
[20:20] <mhwood> Now we just need to find someone who knows the guts of Cocoon well enough to dive in.
[20:20] <jrgriffiniii> Any thoughts?
[20:21] <hpottinger> from the IRC chat log pasted in to 675, it looks like mdiggory had an idea of a possible course of action
[20:23] * hpottinger wishes cocoon were a livelier project...
[20:24] <PeterDietz> I run away from cocoon. What is meant by PDF's are served from DSpace "irregularly"?
[20:24] <mhwood> At first glance, this seems like three separate problems.
[20:26] <jrgriffiniii> PeterDietz: At times, PDF's fail to download in response to a request over the HTTP
[20:26] <jrgriffiniii> PeterDietz: This is resolved when the Apache Cocoon caching is disabled entirely
[20:27] <aschweer> what exactly does "fail to download" mean?
[20:27] <hpottinger> even with DSpace 1.6.2 you can clear an old Cocoon cache
[20:27] <jrgriffiniii> hpottinger: I've cleared it on multiple occasions
[20:27] <PeterDietz> hmm. You could make responding to bitstreams non-cached. a non-caching pipeline
[20:28] <PeterDietz> I do like cache though. It keeps the site from dying of performance woes, but I'm not sure how often a bitstream is hit while still hot in the cache
[20:28] <mhwood> Did clearing the cache *help*?
[20:29] <jrgriffiniii> mhwood: Clearing the cache did not help
[20:29] <jrgriffiniii> aschweer: When a user downloads a PDF (or, presumably, any bitstream; but we have only ingested PDF's), the servlet seems to time out
[20:30] <aschweer> and I guess there isn't anything in the dspace or tomcat logs at the default log level
[20:30] <hpottinger> how big are these PDFs?
[20:30] <jrgriffiniii> aschweer: Apache indicates that the file is sent ("mod_proxy_http.c(1848): proxy: end body send" in the log at LogLevel debug)
[20:30] <aschweer> yeah good point hpottinger. jrgriffiniii, is there a pattern as to which PDFs are affected? all of them? just those above a certain size?
[20:31] <jrgriffiniii> The PDF's are generally from ~100kb to ~5mb
[20:31] <jrgriffiniii> The size does not seem to affect the performance
[20:32] <aschweer> so it's some of the PDFs all the time? or is it essentially random whether it works for a given PDF or not?
[20:32] <jrgriffiniii> It's odd, I can only reproduce the error with a series of successive download attempts
[20:32] <jrgriffiniii> It's essentially random
[20:32] <jrgriffiniii> 1/13 or 1/15 attempts on average
[20:32] <aschweer> sounds very strange
[20:32] <jrgriffiniii> I've ensured that caching is disabled for httpd with a mod_cache directive
[20:33] <jrgriffiniii> So the HTTP proxy isn't likely introducing anything problematic
[20:33] <aschweer> have you tried bypassing httpd completely (not that I think httpd is the problem), eg download via wget from localhost:8080 on the box?
[20:34] <jrgriffiniii> aschweer: The problem cannot be reproduced with wget alone
[20:34] <jrgriffiniii> aschweer: lynx, wget, curl...all of these retrieve bitstreams properly
[20:34] <mhwood> Too many variables...wget et al. do not show the problem, when proxying, or when going direct to the servlet container?
[20:35] <aschweer> jrgriffiniii: you mean when you use the command-line tools on the box? or even when you use the command-line tools from a different machine
[20:35] <jrgriffiniii> aschweer: both
[20:35] <jrgriffiniii> mhwood: When proxying, bitstream content is received successfully when using command-line tools only
[20:35] <aschweer> so you just get the problem in GUI browsers? or just in specific ones? from everywhere, or just from specific machines?
[20:36] <jrgriffiniii> aschweer: From my CentOS workstation using Firefox and Google Chrome, from Windows 7 workstations using Firefox, and from an iPad 2 using Safari
[20:37] <aschweer> I assume all these boxes are in the same network (your instition's), is that correct? does it work fine from outside that network? do these boxes use a proxy to get to DSpace?
[20:37] <jrgriffiniii> aschweer: I have no ability to directly contact the users, and all issues are directed to me through an administrator (i. e. I never receive any error reports; I'm only told to address certain issues by an administrator)
[20:38] <jrgriffiniii> aschweer: These boxes are on the same network, and I've tested this from workstations within various subnets of the institution
[20:38] <aschweer> jrgriffiniii: I was wondering whether you'd tried to reproduce the problem eg from your home machine, or got a friend at a different institution to try or something
[20:38] <jrgriffiniii> aschweer: I've also verified that the issue is present from outside of the network entirely
[20:39] <aschweer> ah good, that's what I was after I guess :)
[20:39] <mhwood> I can't imagine how it would make a difference, but one common difference between commandline and GUI clients would be that the former won't be interested in CSS.
[20:40] <jrgriffiniii> mhwood: I was running curl and httperf with 100% success rates (2xx responses for all tests)
[20:40] <mhwood> Yup, just brainstorming....
[20:43] <hpottinger> OK, dumb question time: what version of Cocoon are we running under the hood here?
[20:43] <jrgriffiniii> I'm uncertain
[20:43] <jrgriffiniii> One moment please
[20:43] <hpottinger> sorry, meant that for the other developers :-)
[20:45] <mhwood> I think it's been 2.2.0-hacked-by-DSpace for a long time now.
[20:45] <hpottinger> http://mvnrepository.com/artifact/org.dspace.dependencies.cocoon/dspace-cocoon-servlet-service-impl
[20:45] <kompewter> [ Maven Repository: org.dspace.dependencies.cocoon » dspace-cocoon-servlet-service-impl ] - http://mvnrepository.com/artifact/org.dspace.dependencies.cocoon/dspace-cocoon-servlet-service-impl
[20:47] <mhwood> Right, every Cocoon artifact is stock except for org.dspace.dependencies.cocoon:dspace-cocoon-servlet-service-impl:1.0.3. I don't think that's changed in years.
[20:47] <mhwood> (Probably because Cocoon hasn't released in years.)
[20:49] <hpottinger> here it is in github https://github.com/DSpace/dspace-cocoon-servlet-service-impl
[20:49] <kompewter> [ DSpace/dspace-cocoon-servlet-service-impl · GitHub ] - https://github.com/DSpace/dspace-cocoon-servlet-service-impl
[20:50] <mhwood> OK, 1.0.3 went to Central in October 2011.
[20:50] <mhwood> http://search.maven.org/#search|gav|1|g%3A%22org.dspace.dependencies.cocoon%22%20AND%20a%3A%22dspace-cocoon-servlet-service-impl%22
[20:50] <kompewter> [ The Central Repository Search Engine ] - http://search.maven.org/#search|gav|1|g%3A%22org.dspace.dependencies.cocoon%22%20AND%20a%3A%22dspace-cocoon-servlet-service-impl%22
[20:53] <hpottinger> some comment headers in that source do seem to point towards dspace-cocoon-servlet-service-impl being based on Cocoon 2.2
[20:53] <mhwood> Would it be much work to try moving to a more recent version of DSpace? 1.6.x has been out for so long that this may have been fixed and forgotten.
[20:54] <mhwood> Yeah, hpottinger, dspace-xmlui/pom.xml pulls in cocoon-core:2.2.0 and some of its relatives (which have their own versions).
[20:54] <jrgriffiniii> mhwood: I feel that this is best course of action. I want to ensure that there aren't any quick work-arounds which will buy me time for a proper upgrade.
[20:55] <jrgriffiniii> mhwood: We only have one server for DSpace, and requesting another server for the migration will consume time in itself
[20:55] <hpottinger> mhwood: I do seem to remember that DS-768 may have made some changes that might apply to the issues being reported by jrgriffiniii
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:56] <mhwood> Fixed in 1.8.0, according to JIRA.
[20:56] <mhwood> That is: the response code was fixed then. Dunno about this other issue.
[20:58] <hpottinger> in theory, you might be able to just tweak your pom.xml to refer to the latest version of dspace-cocoon-servlet-service-impl, if I recall correctly, that's how we tested it before it was committed (on a 1.7.x code base)
[20:58] <mhwood> jrgriffiniii, can you scrounge up any old PC with maybe 512MB memory, just to test on? Would that be a good use of time?
[21:02] <jrgriffiniii> mhwood: Sorry, one moment. I've just discovered that a theme which was allegedly working may not in fact be functioning properly
[21:02] <hpottinger> I just pasted this link to the ticket for 675: http://cocoon.apache.org/2.2/core-modules/core/2.2/1399_1_1.html
[21:02] <kompewter> [ Cocoon Core - Logging configuration ] - http://cocoon.apache.org/2.2/core-modules/core/2.2/1399_1_1.html
[21:06] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :))
[21:07] <mhwood> Well, *that's* different. I wonder if Cocoon is doing its own log4j configuration, and then somehow we come along and confuse it.
[21:11] <hpottinger> I suppose block-level debugging would be helpful...
[21:14] <hpottinger> sorry, didn't mean to hijack the whole Developers meeting :-\ but 675 has been on the "to fix" list for a while.
[21:15] <mhwood> It was pretty quiet anyway, and I agree, this has been something that we need to fix, for too long.
[21:16] <hpottinger> I'm far from a Cocoon expert, but, I might as well claim this ticket
[21:19] <mhwood> It definitely looks like Cocoon is trying to manage log4j itself.
[21:23] <hpottinger> so, potential problem is collision of what we were asking of log4j and what Cocoon is asking? Or possibly a version miss-match of log4j libraries?
[21:24] <mhwood> Perhaps. Cocoon may be doing something to log4j that we don't expect. Pure speculation....
[21:25] <hpottinger> well, this looks like it will be good for me :-) a nice "learning experience"
[21:25] <mhwood> That page you cited: the configuration there doesn't look like anything that the log4j property configurator would read, or understand.
[21:26] <hpottinger> so, we may need to do more to actually direct cocoon to log to its own file
[21:26] <mhwood> That's what I'm thinking. We may have to figure out how to do it "the Cocoon way".
[21:27] <mhwood> Whatever that is.
[21:27] <mhwood> We may have been lucky that our way ever worked.
[21:27] <hpottinger> :-) anything in *your* cocoon log?
[21:28] <mhwood> Lots, but nothing I ever needed to see.
[21:28] <hpottinger> same here, just checked
[21:31] <mhwood> http://stackoverflow.com/questions/3752921/is-it-possible-to-make-log4j-display-which-file-it-used-to-configure-itself
[21:31] <kompewter> [ java - Is it possible to make log4j display which file it used to configure itself? - Stack Overflow ] - http://stackoverflow.com/questions/3752921/is-it-possible-to-make-log4j-display-which-file-it-used-to-configure-itself
[21:32] <hpottinger> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties
[21:32] <kompewter> [ DSpace/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties
[21:33] <hpottinger> last two lines of that file
[21:33] <hpottinger> I think we might be able to "fix" this with a documentation change
[21:34] <mhwood> At least it may provide a workaround.
[21:34] <mhwood> Ugh, Avalon...another dead project.
[21:35] <hpottinger> yehaw!
[21:35] <mhwood> ?
[21:35] <hpottinger> sorry, it's the Missourian in me
[21:36] <hpottinger> I was being ironically excited about the tech under the hood of Cocoon
[21:36] <mhwood> One good reason to move to Cocoon 3 (if it ever leaves alpha): shake off all that old dead Avalon/Excalibur stuff that you can't even find anymore.
[21:37] <hpottinger> mhwood, what do you think about maybe just trying Cocoon3 in a branch?
[21:38] <mhwood> I was just thinking that perhaps the way to get Cocoon 3 to release would be to declare that DSpace 4 will use it, start finding broken stuff, and flood them with issues until it firms up.
[21:39] <hpottinger> I mean, the cocoon devs clearly are thinking in terms of 3 being *the* release
[21:39] <hpottinger> even if they haven't pulled the lever on the official release
[21:39] <mhwood> It won't be a drop-in replacement for 2.2, though. There's pretty much a new team on C3, they dropped a lot of existing stuff, and it's pretty thoroughly reorganized.
[21:39] * hpottinger grumbles
[21:40] <mhwood> Yeah, the C3 dev.s are standing around waiting for the community to adopt C3, while the community is waiting for C3 to release (or even graduate to beta).
[21:40] <hpottinger> I remember mdiggory proposing another path, something about replacing cocoon with webmvc
[21:41] <mhwood> C2.2 -> C3 probably means the same thing that happened with Maven: forget how we used to do it and embrace the C3 Way.
[21:41] <mhwood> grahamtriggs wanted to do a webmvc UI, IIRC.
[21:41] <PeterDietz> I like webmvc better than the idea of webmvc.
[21:42] <PeterDietz> Would it help if you saw a demo of webmvc?
[21:42] <PeterDietz> i.e. I love wiring up third-ish party modules
[21:42] <PeterDietz> I think I should also add the wijiti REST API up too.
[21:42] <mhwood> TBH I think DSpace already has too many UIs.
[21:42] <PeterDietz> disclaimer: I worked on the webmvc project for a bit
[21:43] <PeterDietz> I was just diagramming. I would like to make DSpace + REST API be THE way
[21:43] <PeterDietz> then build your "heads" on top of that
[21:43] <hpottinger> to be fair to mdiggory, my understanding is he was talking about the actual spring webmvc, and not the UI based on it
[21:43] <PeterDietz> Sorry, but it looks like I've stolen someone elses concept
[21:44] <hpottinger> but, sure, it would be interesting to replace Cocoon with REST
[21:45] * hpottinger does not know what that would look like
[21:46] <hpottinger> seems like a lot of effort just to keep XML in the workflow, though
[21:46] <mhwood> ?
[21:47] <hpottinger> XMLUI is kind of couched in the world of the early 2000s, where XML was *the thing* that everyone was going to use to do everything. I think the idea was that you could farm out customization work to interested power users.
[21:48] <mhwood> Oh. The idea seems to have been that you could hand a lot of the work to XML types instead of programmers. As usual, forgetting that you've only created a new class: XML programmers.
[21:48] <hpottinger> exactly
[21:49] <mhwood> Where XML shines is in places where you can hand it to *machines* instead of people.
[21:49] <hpottinger> XSLT: world's stupidest programming language
[21:50] <mhwood> I can't help thinking that XSL would make a good deal of sense, once I wrap my head around the processing model. Which is taking forever.
[21:50] <mhwood> Worse than learning LISP after FORTRAN.
[21:51] <hpottinger> I think the idea was to make it self-documenting… but I don't think that goal was met
[21:52] <mhwood> Can't work. The machine doesn't read the documentation to do its job, so you can put anything there...or nothing. The only stuff that gets done is what makes the compiler shut up and the processing happen.
[21:52] <mhwood> And you can easily create an XML schema that looks like utter nonsense when used, but still works just fine.
[21:53] <hpottinger> anyhow, it's all good fun to bash XSLT, but, honestly, if it hasn't delivered on the promise, and we have to invest a lot of effort to keep an interface based on it going… maybe it's time for change
[21:53] <mhwood> I would be willing to try changing to C3, which looks like almost as much of a revolution as switching to something entirely separate.
[21:54] <mhwood> The problem is that the promise of which you speak can't be fulfilled. "Programming without programmers" just creates new types of programmers, and self-documentation has never worked because documentation only has meaning to people.
[21:55] <hpottinger> I think we have other groups working on revolutionary changes, I think Lyncode is working on a different template system, and we have REST-API
[21:57] <hpottinger> I agree mhwood on your assessment of the situation
[21:58] <hpottinger> in practical terms, I think just documenting how to turn on debugging for Cocoon is probably the best approach, and we probably need to have a chat about what comes after Cocoon
[21:58] <mhwood> As if I didn't have enough going on…I find myself thinking that I, too, should get my feet seriously wet with C3.
[21:59] <mhwood> Yes to both, with the modification: what comes after C2.2.
[22:01] <hpottinger> jrgriffiniii: do you think you can have a go at modifying the core.properites file and turning on debugging in that way? Here it is in github: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties
[22:01] <kompewter> [ DSpace/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/WEB-INF/cocoon/properties/core.properties
[22:02] <mhwood> If you're using an unpacked WAR (most are) then you should be able to tweak the file in place, rather than rebuilding everything. Probably XMLUI would need to be restarted, of course.
[22:05] <mhwood> "in place": [CATALINA_HOME]/webapps/xmlui/WEB-INF/cocoon/properties/core.properties
[22:09] <mhwood> Must go, good luck!
[22:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:12] <hpottinger> I've got to to go, too
[22:12] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:36] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.