Conversazioni con #geotools su 22/10/2007 20.05.20:
(21.05.21) #geotools: L'argomento di #geotools è: Meet'in time: 0) what is up [...put your topics here...]
(21.05.33) aaime!n=aaime@anonymised.com: aaime ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close()
(21.05.57) jdeolive!n=chatzill@anonymised.com: jdeolive ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close() 2) FeatureCollection cleanup
(21.08.23) jgarnett: I have a question;
(21.08.38) jgarnett: does anyone feel like doing osgeo stuff today?
(21.08.45) jgarnett: if not I wont put it on the agenda
(21.08.53) iant_ [n=ijturton@anonymised.com] è entrato nella stanza.
(21.09.13) jgarnett: bah we have enough of the PMC here ...
(21.09.21) jgarnett!n=Jody@anonymised.com: jgarnett ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close() 2) FeatureCollection cleanup 3) iccubation
(21.09.22) ***acuster still has to get out a writeup of the copyright situation
(21.11.05) desruisseaux: I would like to do OSGEO stuff if you have any new on it
(21.11.22) jgarnett: okay coo; anything else for the meeting ...
(21.12.42) jdeolive: yeah, whats up with codehaus being so darn slow
(21.13.44) desruisseaux: Glad to see I'm not the only one to wait for codehaus for many hours...
(21.14.30) jdeolive: yeah... i have noticed its been like that for about a week or so now
(21.15.11) groldan: over the weekend svn were broken too, codehaus sucks since friday at least for me
(21.15.13) jgarnett: slow for me too; anyone talked to #codehaus ?
(21.15.17) acuster: can one of you explain the 'filters are broken' thing?
(21.15.36) acuster: I hear rumors since victoria that filters are a complete, unfixable mess
(21.15.53) aaime: since Victoria? 
(21.16.05) ***groldan joined #codehaus and found him alone
(21.16.25) aaime: I've been saying that a code sprint (few days of) is needed to fix them since the summer
(21.16.40) jdeolive: groldan: you have use irc.codehaus.org
(21.16.42) jdeolive: not freenode
(21.17.06) ***groldan knew it has to be his fault
(21.17.32) acuster: aaime, what needs to be fixed? what's using geoapi and what's using gt-filter?
(21.17.45) acuster: is it a datastore/core split of some kind?
(21.18.09) aaime: datastores are still mainly using gt2 filters
(21.18.19) aaime: and there are lots of filter visitors too
(21.18.38) jgarnett: style uses mostly gt2 filters too as far as I know
(21.18.39) aaime: It's not as big as the change we made in the code sprint at Victoria
(21.18.45) aaime: but not nearly as mechanic
(21.19.06) jgarnett: acuster some code directly casts to "AbstractFilter" class; when you make your own filter by hand (say in uDig) the geotools code that tries this trick breaks
(21.19.16) aaime: So I'd say the effort is somewhat similar... only you'll see people thinking a lot instead of typing a lot
(21.19.17) groldan: there's the function expression problem (ie using plain geoapi no way to know up front how many arguments a function has, if I remember correctly)
(21.19.27) jgarnett: (so even though the interfaces say "geoapi filter" if you pass in anything that is not AbstractFilter it will break.
(21.21.18) aaime: So, do we start the meeting or what?
(21.21.19) ***groldan thinks it would be cool to have a plain geoapi implementation to switch to
(21.21.33) jgarnett: please aaime
(21.21.39) jgarnett: place filter on the agenda for later
(21.21.41) aaime: 0) What's up
(21.21.45) jgarnett!n=Jody@anonymised.com: jgarnett ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close() 2) FeatureCollection cleanup 3) iccubation 4) filter fun
(21.21.52) aaime!n=aaime@anonymised.com: aaime ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close() 2) FeatureCollection cleanup 3) iccubation 4) filter aren't fun
(21.22.01) aaime!n=aaime@anonymised.com: aaime ha scelto come argomento: Meet'in time: 0) what is up 1) DataStore.close() 2) FeatureCollection cleanup 3) iccubation 4) filters aren't fun
(21.22.10) aaime: :-p
(21.22.17) jgarnett: finished uDig user interface review; and am now going to have to explain myself to acuster and jesse 
(21.22.43) ***aaime coding like a crazy cat trying to put a couple of critical fixes and improvement before the last GeoServer beta goes out of the door
(21.22.48) ***jdeolive is looking at cleaning up feature collection
(21.23.00) ***Eclesia has a headack
(21.23.03) acuster: trying to wrap my head around catalog and understand how to avoid doing resource management
(21.23.09) iant_: Ian tried to move cacheing code to trunk post code sprint but failed
(21.23.33) groldan: done some geoserver bug fixing, getting some more community schemas supported, and reading the wfs 1.1 spec to join justin
(21.24.30) desruisseaux: martin: a little bit of postgrid (for a "GetLegend" on raster in GeoServer - to tied to postgrid for commiting on GeoServer right now...). Also more work on NetCDF reader and Basic Image I/O framework (making it more robust when the "valid range" information is not known).
(21.26.19) aaime: Next topic?
(21.26.23) aaime: 1) DataStore.close()
(21.26.43) aaime: I hope to have addressed the last concerns in my mail of 5 minutes ago
(21.26.45) aaime: (did I?)
(21.27.17) aaime: so tomorrow I'll start making the changes in order to have the thing go out of the door along with GeoServer 1.6.0-beta4
(21.28.38) jgarnett: andrea I am happy if you know about the concerns and have the answers in the javadocs.
(21.28.43) jgarnett: (I voted +1)
(21.28.48) aaime: Saw it
(21.28.55) jgarnett: cool; thanks for putting this together andrea.
(21.28.59) aaime: The concerns are appropriate
(21.29.06) aaime: thougth not all API address them
(21.29.13) aaime: for example, IOStream.close() does not say anything
(21.29.23) aaime: Connection.close() only say you can call it many times
(21.29.50) aaime: As for mt, I'll state that sync responsibility is on the user
(21.30.01) jgarnett: can you explain?
(21.30.05) aaime: because having it on the datastore would complicate tremendously matters
(21.30.13) aaime: Explain which part?
(21.30.24) jgarnett: can we at least make calling close() multiple times not deadly?
(21.30.37) aaime: Ah yes, that's what I wrote in the mail
(21.30.41) jgarnett: and I would like to make sure that close() can be called at any point in a DataStore lifecycle
(21.30.45) aaime: after first time it should become a no-op
(21.30.50) jgarnett: (ie while it is connecting for example).
(21.30.51) jgarnett: cool
(21.30.57) jgarnett: reading email; please resume meeting 
(21.31.48) aaime: DataStore interface has no thread safety concerns attached to it afaik?
(21.31.57) aaime: that is, it's not meant to be thread safe
(21.32.11) groldan: btw, I'm +1 on calling it dispose() rather than close() (there's no open(), and after calling it the datastore should be thrown away)
(21.32.12) ***aaime is going to read the DataStore interface
(21.33.17) aaime: Hem... I don't know
(21.33.25) aaime: we should reopen the vote to everybody for that one...
(21.33.27) jdeolive: that is what i have called it in the abstract datastore implementation i am working on in h2 land
(21.33.31) jdeolive: "dispose"
(21.34.06) aaime: I would be tempted to keep on calling close() just because I hate Eclipse oriented API :-p
(21.34.08) aaime: but it's ok
(21.34.14) jgarnett: I like dispose(); I am more worried about functionality being clear then the name.
(21.34.19) aaime: The only thing that troubles me
(21.34.23) jdeolive: how about www()?
(21.34.29) aaime: gooood
(21.34.36) jdeolive:
(21.34.36) aaime: is that IanT and Simone have already voted
(21.34.37) groldan: w3()
(21.34.41) acuster: fuckit()
(21.34.56) aaime: rigth on the mark acuster
(21.35.17) aaime: Oh well ok, I'll change the proposal over to dispose()
(21.35.30) aaime: and let's see if IanT and Simone are going to ask for my head
(21.36.08) aaime: Anything else?
(21.36.47) jgarnett: move on
(21.36.55) aaime: 3) iccubation
(21.36.57) iant_: I don't care
(21.37.01) jdeolive: did we miss 2?
(21.37.02) jgarnett: um what about 2)
(21.37.06) aaime: ops
(21.37.15) aaime: I thought I had tricked you...
(21.37.19) jdeolive: 2) FeatureCollection Cleanup
(21.37.21) jdeolive: this one is me
(21.37.23) jdeolive: so
(21.37.39) jdeolive: as we all know we have been talking about cleaning up the mockery we will feature collection for some time now
(21.38.05) jdeolive: and i have been working on implementing 2 datastores ( wfs and h2 ), and indeed having feature collection eb this messy is a pain
(21.38.20) jdeolive: also... as we have been doing the other feature model work now is the best time to fix it
(21.38.43) jdeolive: so i would like to put some time toward working on teh proposal
(21.39.00) groldan: still can't access the proposal page
(21.39.23) jdeolive: so how do peopel feel about making it a target for 2.5? that is deprecating the old feature collection changes and make sure all the improvements are in place
(21.39.57) groldan: It makes all sense to me
(21.40.04) aaime: I think I would need an evaluation of the impact
(21.40.14) iant_: sounds good to me - I never got my head round the old one
(21.40.27) aaime: aka: how much effort it requires to do a clean, non deprecated port of the code from a user perspective?
(21.40.32) jdeolive: aaime: i can going to try to take the smoothest update path possible approach
(21.40.34) groldan: I don't think the impact's gonna be high (do you ever used it as a java.util.Collection after all?)
(21.41.03) jdeolive: groldan: that is my impression as well, the only method that is really used is "iterator()"
(21.41.05) aaime: every time you called iterator() or you used in a java5 loop, you did
(21.41.11) groldan: (though I agree that doesn't count as an evaluation)
(21.41.23) jdeolive: well i kind of think it does
(21.41.33) aaime: agreed
(21.41.34) jdeolive: i mean.. the amont client code has to change is an important thing
(21.41.35) groldan: and we need a safer way to get count and bounds
(21.41.47) jdeolive: anyways, all this is part of the proposal
(21.41.54) jdeolive: which i will be working on
(21.42.10) jdeolive: i just want to get some initial acceptance on the idea of fixing feature collection for 2.5
(21.42.26) jgarnett: hrm; as far as I am concered we need to do this soon as the existing API is a hazzard to any and all users
(21.42.32) groldan: aaime: yeah, thats obvious, just make it iterable or whatever it is called in java5 so
(21.42.38) jgarnett: the Java 5 syntatic sugar makes it too easy to produce broken code.
(21.42.46) groldan: but we all know all the rest of the collection methods are non sense
(21.42.53) aaime: If it's not a blood bath from development point of view I'm ok
(21.43.21) aaime: One thing thought... I would not be ok to do a full code sprint to fix this one and keep on leaving filters in the sorry state they are now
(21.43.54) jgarnett: I already coded up many examples against the proposal above and found them okay; note this is basically a return to the FeatureResults concept --- iie a Feature Collection with such a small API that we are willing to implement it property (tm)
(21.43.58) jdeolive: ideed, we should make the filter thing a blocker for 2.5
(21.44.51) jgarnett: any comments from me on that topic are saved for 5)
(21.45.01) jdeolive: you mean 4)?
(21.45.01) jgarnett: sorry agenda item 5-1=4)
(21.45.05) jdeolive:
(21.45.33) jdeolive: ok... well i think that is it for me, i dont want to talk any more until we have a clear proposal with code examples
(21.45.53) jgarnett: 3) iccubation
(21.46.05) jgarnett: This one will start as me ... but really it is all of us PMC
(21.46.16) jgarnett: if many of us are like iant_ and in a "Don't care" state
(21.46.19) jgarnett: (and we can be honest)
(21.46.25) jgarnett: we should just drop this for now;
(21.46.32) jgarnett: and look into FSF or something else.
(21.46.42) jgarnett: But the responsibility is ours; and we need to deal with it.
(21.46.58) jgarnett: Last week I tried putting together a proposal based on some bad information
(21.47.11) jgarnett: from a rather confused OSGeo board member.
(21.47.19) iant_: Who said I was don't care?
(21.47.26) jgarnett: I am going to attend their meeting on Nov 2nd and get the record straight.
(21.47.36) acuster: what's the question?
(21.47.57) jgarnett: (I saw it above; maybe the temporal IRC response paradox interspersed your commend onto a different topic?)
(21.48.22) iant_: (I think that refered to close()/dispose())
(21.48.27) acuster: what is it that you don't understand about incubbation?
(21.48.28) jgarnett: cool
(21.49.17) jgarnett: sorry; set the record straight. If they are still confused about what we needt to the point we are getting conflicting instructions etc....
(21.49.28) jgarnett: (not get the record straight)
(21.49.41) acuster: ah, to see if *they* are confused
(21.49.42) acuster: ok
(21.50.00) jgarnett: The other thing we could do is switch tatics; leave (c) with individuals / organizations
(21.50.05) jgarnett: and license the result to OSGeo.
(21.50.12) acuster: I thought we were in the home stretch.
(21.50.23) jgarnett: It may be our only option since the "PMC" as an idea never managed to hold (c)
(21.50.36) acuster: Cholmes decided kind of unilaterally that the lawyers we were using wern't going to work out
(21.50.44) jgarnett: this would mean updating our headers; along with checking svn
(21.50.46) jgarnett: would take longer.
(21.50.49) acuster: and so has been sitting on the text for this last month
(21.50.57) jgarnett: gah
(21.51.03) jgarnett: see I am out of the loop
(21.51.06) jgarnett: is cholmes around?
(21.51.29) jgarnett: perhaps I should just do a quick PMC poll:
(21.51.35) jgarnett: aaime: do you know what is going on?
(21.51.35) aaime: nope
(21.51.39) aaime: nope
(21.51.41) acuster: we almost succeeded in having a text for victoria
(21.51.53) jgarnett: iant_ do you?
(21.52.04) jgarnett: desruissseaux ?
(21.52.15) desruisseaux: What is the question?
(21.52.27) chorner: ... i thought this was a no-brainer
(21.52.31) iant_: nope - I thought it was nearly done
(21.52.39) chorner: we sign everything away
(21.53.04) acuster: to monsieur gates, bellingham washington
(21.53.07) chorner: is it just the text that is in dispute?
(21.53.17) acuster: a man who loves to own code
(21.53.33) aaime: Afaik the main problem is first finding out what would protect us the best
(21.53.36) jgarnett: chorner the problem is who signs the code away
(21.53.37) acuster: chorner, yes, as best as i can tell
(21.53.53) acuster: jgarnett, ?
(21.53.59) jgarnett: acuster so you think we are close to getting some text that OSGeo will agree too?
(21.54.13) acuster: yes, very
(21.54.21) jgarnett: okay; that was getting lost on me.
(21.54.35) jgarnett: okay; will we have something for them to look at for Nov 2nd?
(21.54.37) acuster: if we were grownups we would go to see a lawyer and have a text the next week
(21.54.41) jdeolive: we have 5 mins left, shyodl we move onto 4?
(21.54.56) jgarnett: not quite yet jdeolive
(21.55.16) jgarnett: this iccubation thing is a do we finish or do we stop trying kind of thing for me.
(21.55.27) acuster: jgarnett, no I do not have a final text draft for the board
(21.55.35) jgarnett: (at the very least I don't want us to have to talk about it anymore)
(21.55.37) jgarnett: okay
(21.55.37) acuster: because their lawyer doesn't understand diddly
(21.55.54) acuster: so what I have is an annotated document, with my proposal text
(21.55.59) jgarnett: And you say cholmes is getting a different lawyer ?
(21.56.00) acuster: surrounded by explanations
(21.56.12) jgarnett: okay; well we can always try forcing the issue; change our headers
(21.56.14) acuster: and by the texts from other documents
(21.56.18) jgarnett: sign that document and send it to OSGeo central.
(21.56.51) jgarnett: basically if it is something that *we* the GeoTools project like
(21.56.57) jgarnett: then we should do it.
(21.57.03) acuster: The question is really: can OSGeo produce a copyright assignment form or not?
(21.57.11) acuster: it's not a geotools question at all, fundamentally
(21.57.12) jdeolive: i gotta run all, will have to catch up via logs
(21.57.19) acuster: ciao justin
(21.57.22) jgarnett: cheers
(21.57.31) jgarnett: Well regardless of if the OSGeo can do it or not
(21.57.35) jgarnett: we need to see it get done.
(21.57.59) jgarnett: Should I kill the existing proposal page then acuster?
(21.58.03) acuster: we could unilaterally give them copyright
(21.58.24) acuster: but we would have no guarantees at all for what that assignment meant
(21.58.30) jgarnett: Well we have some difficulty; dzwiers does not want to give (c)
(21.58.39) acuster: jgarnett, I don't know of what page you speak
(21.58.43) jgarnett: and we have the difficulty of code for which the author cannot be found.
(21.58.58) acuster: fine, some code stays licensed lgpl
(21.59.01) acuster: that's not a problem
(21.59.08) acuster: if osgeo gets the bulk of it
(21.59.10) jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Update+GeoTools+Headers
(21.59.34) acuster: and we have a reasonable list of what code is licensed and what code is assigned
(21.59.47) jgarnett: okay I need to open up the floor to the rest of the PMC here
(21.59.57) jgarnett: (because I, like others, have little time on this one)
(21.59.58) acuster: we could undertake the provenance review before signing the docs
(22.00.08) desruisseaux: Adrian said that he is close to getting the paper accepted by OSGEO. Can we make this try? Do we have someone who can tell us when OSGEO accept it (if they do)?
(22.00.31) jgarnett: Paul is now on the board; I can ask him to tell me when they accept it.
(22.00.35) acuster: cholmes was supposed to be point man on this
(22.00.49) jgarnett: My impression is the board thinks we the GeoTools PMC are insane
(22.00.56) acuster: I sent *him* the text and he was supposed to take it from there
(22.01.17) jgarnett: okay cholmes is sometimes known to be busy
(22.01.22) jgarnett: do we have a back up plan?
(22.01.29) acuster: if they think we are simply ask them for a copyright assignment form, any form
(22.01.57) desruisseaux: Then can we send an email to Chris and ask him if he have any new, or if he wish to pass to someone else?
(22.02.02) acuster: the only one I have seen is *terrible*
(22.02.12) acuster: legally incorrect and such
(22.02.41) acuster: writen by american lawyers trying to encompass european law and getting it flat out wrong
(22.02.50) jgarnett: I see
(22.03.15) jgarnett: GeoServer recently did something; that was more or less sane.
(22.03.17) acuster: so if OSGeo wants to allow projects to recieve copyright, let them tell us how they propose we do it
(22.03.27) jgarnett: Sane to the point I was willing to sign it after careful review.
(22.03.43) jgarnett: OSGeo does not really want to put in the work on this one
(22.03.51) jgarnett: there is no way they are going to tell us what to do
(22.03.58) acuster: great, if anyone has an alternative, great
(22.03.58) jgarnett: (ie they are not a grown up foundation like FSF
(22.04.04) jgarnett: they want to learn from our example)
(22.04.21) jgarnett: okay; how about this
(22.04.23) acuster: right so we did all the work we possibly could do for them
(22.04.28) jgarnett: yep
(22.04.35) acuster: if they don't want to do anything, then we are stuck
(22.04.35) jgarnett: I will talk to the board on Nov 2nd
(22.04.44) jgarnett: we can try your docs
(22.04.54) acuster: we could easily assign all the (c) to the FSF europe
(22.05.04) jgarnett: and then I think we should look into back up plans; ask TOPP for help (as a foundation) or FSF
(22.05.13) iant_: Can we try reminding them that I "donated" $500 from google soc mentoring that could be used for lawyers i fneed be
(22.05.13) jgarnett: that would be good as well.
(22.05.17) acuster: we could do that today
(22.05.25) jgarnett:
(22.05.41) jgarnett: well if we like that idea let me present it as an alternative to them on Nov 2nd
(22.05.41) acuster: the (c) would be FSFeu and the project would be "OSGeo"
(22.06.08) jgarnett: So the decision comes down to:
(22.06.23) jgarnett: a) look at this code contribution agreement from acuster; like it lump it or fix it
(22.06.24) jgarnett: or
(22.06.37) jgarnett: b) (c) FSFeu and organization would be OSGeo
(22.06.41) jgarnett: that works for me...
(22.07.01) desruisseaux: Fine for me too (My first preference would be (c) OSGEO. My second preference would be (C) FSF hosted on OSGEO as proposed by Adrian).
(22.07.21) acuster: more precisely (c) [mix of FSFeu and individuals]
(22.07.31) jgarnett: you are correct
(22.07.41) jgarnett: iant_ any feedback?
(22.07.42) jgarnett: aaime?
(22.07.45) acuster: but if the majority was with FSF they would have standing to sue/protect/...
(22.08.21) jgarnett: understood
(22.08.33) desruisseaux: Adrian, do you think that (c) FSF is preferable to (c) OSGEO?
(22.08.38) iant_: How would choosing an EU licence work for the US?
(22.08.47) acuster: desruisseaux, no
(22.08.51) desruisseaux: Thanks
(22.08.58) acuster: iant_, the license is lgpl
(22.09.11) acuster: the group holding the copyright is in europe
(22.09.29) acuster: I don't get your question beyond that
(22.09.37) iant_: which we already have, right? so how would choosing an EU group to hold the copyright work in the US
(22.10.04) acuster: iant_, sorry I don't undestand you
(22.10.10) acuster: today (c) is held by all of you
(22.10.18) acuster: despite what the headers say
(22.10.35) iant_: will US Orgs recognise and honour an EU copywrite?
(22.10.41) groldan ha abbandonato la stanza (quit: Remote closed the connection).
(22.10.43) acuster: sure
(22.10.56) iant_: and visa versa if we go with OSGEO
(22.11.32) acuster: yes, copyright is become standardized (except for some details like the total length of the exclusion right)
(22.11.52) acuster: copyright lawsuits are filed all over the world against everyone
(22.11.52) aaime: Aren't USA companies much more sue prone than european one? (or is it just a myth)?
(22.12.06) iant_: That's what I thought. - What about those of us whoes employers claim ownership of all our IP?
(22.12.30) acuster: the foundation holding the copyright will probably not affect the occurance of a lawsuit
(22.12.46) acuster: except perhaps FSF is slightly more of a deterrent
(22.12.58) jgarnett: iant_ I think such organizations get to sign something
(22.13.02) acuster: since they are better known as legally competent
(22.13.06) jgarnett: Refractions signed something for us to work on GeoServer.
(22.13.35) acuster: iant_ indeed, those are exactly the kinds of questions we need to tackle in a document
(22.13.39) acuster: which is why it is hard
(22.13.47) iant_: So would it be a problem that James and I never worried about this back when we worked for Leeds Uni
(22.13.55) acuster: and why their proposal a year and a half back was a bad joke
(22.14.25) acuster: iant_, it's too bad but I don't think it's a problem
(22.14.37) acuster: if your code back then belongs to Leeds
(22.14.50) acuster: then they have a joint (c) on the code base
(22.14.53) iant_: well Leeds and the grant funding body
(22.15.02) jgarnett: The (c) Leeds still shows up in the headers IanT
(22.15.30) acuster: iant_, did they give you permission to use the lgpl?
(22.15.40) acuster: iant_, do you know if you needed to ask them for permission?
(22.15.45) iant_: but for sure James and I were never allowed to own the copyright on work product during that period. That's why we gave GT away in the first place
(22.16.06) acuster: the best we can do is document what code from that period remains
(22.16.18) acuster: and add (c) Leeds/grant funders to the files
(22.16.31) iant_: We never really asked, but no one is likly to chase it down
(22.16.32) acuster: at the cost of maybe one day having to rip those files out
(22.16.52) acuster: we should in any case document the files as best as we possibly can
(22.18.15) acuster: to close this topic. I'm going to work on an update of the situation in the next few days.
(22.18.22) acuster: I encourage everyone to read it
(22.18.31) acuster: and the PMC can then take decisions from there.
(22.18.38) aaime: I have to run
(22.18.43) iant_: ok
(22.18.46) jgarnett: thanks aaime
(22.18.49) aaime: Will anyone post the logs?
(22.19.06) jgarnett: I will post the logs now
(22.19.11) acuster: aaime, was your filters topic serious?
(22.19.15) jgarnett: thanks for the meeting and sorry we did not get to filter
(22.19.17) Eclesia ha abbandonato la stanza (quit: Read error: 104 (Connection reset by peer)).
(22.19.27) aaime: it was serious 4 months ago
(22.19.32) aaime: now it's becoming a joke
(22.19.38) jgarnett: aaime can we write up a proposal for filter ? ie so discussion can be structured next time?
(22.19.40) Eclesia [n=Administ@anonymised.com] è entrato nella stanza.
(22.19.45) acuster: as a topic for today (something you wanted to talk about)
(22.19.52) acuster: not as a subject
(22.19.55) aaime: Proposal? We need a sprint, not a proposal imho
(22.20.06) aaime: It's not like we have to make a new API
(22.20.06) jgarnett: fiar enough
(22.20.08) jgarnett: it is about work
(22.20.10) jgarnett: not about API
(22.20.12) aaime: right
(22.20.15) jgarnett: right
(22.20.38) Sei ora conosciuto come aaime_away
(22.20.50) aaime: Bye bye
---
(20.13.39) L'argomento di #geotools è: Weekly meeting 2007.10.29: 0) What is up? 1) Nd CRS-es and transforms
(20.13.44) judd_taylor: Ok, I checked JIRA, and I didn't see this bug mentioned anywhere...
(20.13.46) acuster: are you sure you need to do all that there?
(20.13.54) judd_taylor: I'll report it here when you guys are ready.
(20.14.00) aaime: Hi
(20.14.12) acuster: judd_taylor, file a new bug and then you can paste the url
(20.14.16) jdeolive: hi all
(20.14.40) acuster: judd_taylor, martin would be the one to help you and he's not here yet
(20.14.52) judd_taylor: Well, if I mention it here first, then if it turns out to be something I'm doing stupid, then I won't need to do all of that paperwork...
(20.15.03) jgarnett: so if we are through agenda item 0) shall we move on?
(20.15.19) jgarnett: Anyone else with an agenda item speak up; ... add it to topics etc...
(20.15.24) acuster: Eclesia, in restore_tabs() you are making a new listener
(20.15.30) acuster: Eclesia, within the catch block
(20.15.31) judd_taylor: Well, this one isn't exactly related to the orthographic stuff, although I'm sure martin would be very helpful on this issue.
(20.15.35) vheurteaux: acuster: Martin will be late I think
(20.15.42) acuster: Eclesia, that seems heavy
(20.15.56) acuster: buci, want to run your question for jody?
(20.16.02) acuster: buci, you are the next up
(20.16.03) jgarnett: 1) Nd CRS-es and transforms
(20.16.26) buci: would be better, if Martin was here, I guess, but let's try
(20.16.29) Eclesia: acuster: it's just a demo
(20.16.41) ***vheurteaux calling Martin
(20.16.49) jgarnett: well we can juggle you to the end of the meeting; but so far you are the only topic.
(20.16.51) aaime ha scelto come argomento: Weekly meeting 2007.10.29: 0) What is up? 1) Nd CRS-es and transforms 2) logging
(20.16.53) acuster: Eclesia, I'm giving you feedback man, take it or leave it as you wish
(20.17.10) judd_taylor: I'll wait for martin as well.
(20.17.48) Eclesia: ^^ thx, but the objectiv wasn't a perfect thing, i made it to test the reliability of the widgets
(20.17.56) jgarnett ha scelto come argomento: Weekly meeting 2007.10.29: 0) What is up? 1) swing widets feedback 2) logging 3) Nd CRS-es and transforms
(20.18.06) jgarnett: okay now that reflects reality
(20.18.11) jgarnett: 1) swing widgets feedback
(20.18.15) jgarnett:
(20.18.23) Eclesia: ggrrrr jgarnett
(20.18.37) acuster: aaime, did you take a look at eclesia's widgets? you had a good comment last time around
(20.18.46) aaime: sorry no
(20.19.05) aaime: I had a look at the netbeans rcp demo and it looked promising thought
(20.19.20) acuster: http://altersig.developpez.com/telechargement/Appli.java
(20.19.25) aaime: my concerns do remain
(20.19.30) acuster: http://altersig.developpez.com/images/snapshot_explorer.png
(20.19.40) acuster: for those who want them.
(20.19.44) aaime: lack of internationalization and layout that can be modified with a single IDE
(20.19.53) aaime: but I sure prefer someone working on those conditions
(20.19.57) aaime: that nobody working at all
(20.20.02) aaime: go Eclesia go!
(20.20.06) Eclesia:
(20.20.39) Eclesia: i do with the time i have and with what i know, but i really would like someone else working on this
(20.20.58) aaime: not me, I'm an Eclipse man
(20.21.12) aaime: really, that's not the reason... I'm already swamped with GeoServer stuff
(20.21.25) aaime: that's the real one...
(20.22.07) groldan [n=groldan@anonymised.com] è entrato nella stanza.
(20.22.16) acuster: next?
(20.22.18) Eclesia: one thing, who works on CQL ?
(20.22.21) simboss___ [n=chatzill@anonymised.com] è entrato nella stanza.
(20.22.50) Eclesia: i made a filter to cql class and it should not stay in the widget module
(20.22.59) jgarnett: That was something axios did right? The module maintainer should be in the pom.xml
(20.23.08) groldan: mauricio pazos, see the pom file for contact info
(20.23.32) Eclesia: ok
(20.23.50) acuster: aaime, are you up with logging?
(20.24.00) aaime: 2) logging
(20.24.04) aaime: I wish Martin was here
(20.24.12) aaime: did anybody follow the logging thread
(20.24.19) aaime: what are the reactions?
(20.24.27) jgarnett: I followed a little bit of it; but most of it was on geoserver-devel
(20.24.28) aaime: (or do you want me to do a quick recap?)
(20.24.37) jgarnett: please
(20.24.39) aaime: I linked the thread from gt2-deve thru nabble
(20.24.45) acuster: seemed like you were going to 'give it a shot'
(20.24.58) aaime: Well, the problem is the usual
(20.25.07) aaime: java logging is no good for enterprise java
(20.25.09) jgarnett: Do you have a proposal page yet? Or were you waiting for discussion.
(20.25.21) aaime: codehaus was mostly down last week
(20.25.31) aaime: today I was simply too busy to setup a proposal
(20.25.57) aaime: The current approach is to add a handler that redirects logging to commons logging
(20.26.21) aaime: The problem is, it's too complex and breaks easily in j2ee containres
(20.26.27) aaime: the idea is basically the following
(20.26.34) judd_taylor: geotools uses log4j, right?
(20.26.40) aaime: nope, java logging unfortunately
(20.26.45) aaime: Replace all Logger.getLogger(xxx) calls in the code
(20.26.55) aaime: with a Gt2LoggerFactory.getLogger(xxx)
(20.27.11) aaime: that, properly configured, will return a java logger subclass
(20.27.21) aaime: that will directly reroute all logging calls
(20.27.28) aaime: to the provider we want
(20.27.49) aaime: For example, we can have a Log4jLogger which _is a_ java logger, but that under covers talks directly to log4j
(20.28.06) jgarnett: I think I see; we want to take control of the process - letting us host the library in more environments.
(20.28.08) aaime: so that in fact the java loggin subsystem is not even called
(20.28.08) acuster: can you drop the 2 in Gt2LoggerFactory?
(20.28.11) judd_taylor: Ok, well that's my suggestion then Log4j isn't perfect, but it's pretty cool. I have no experience with java logging, so I'm not exactly qualified to make these statements...
(20.28.14) jgarnett: Is that any different from what log4j goes?
(20.28.17) jgarnett: goes = does.
(20.28.31) aaime: Sorry?
(20.28.34) jdeolive: i am weary of depending on geotools specific code to obtain a logger instance
(20.29.01) aaime: I know, but if we use commons logging containers relying on slf4j will screw us up
(20.29.23) aaime: you know, the smart guys at slf4j have decided to cripple all users of commons logging
(20.29.31) aaime: they put in the classpath a commons logging replacement
(20.29.37) aaime: that's binary compatible with the original
(20.29.40) jdeolive: isn't that there problem
(20.29.49) jdeolive: like... they chose to screw over 90% of the world
(20.29.52) aaime: and that redirect things were they do want
(20.29.57) aaime: Indeed they did
(20.30.04) judd_taylor: I hate java people
(20.30.14) aaime: If you deploy a commons logging based library in Jetty
(20.30.19) aaime: that is using slf4j
(20.30.27) aaime: you'll end up having no control on logging at all
(20.30.37) aaime: (from within the application at least)
(20.30.49) aaime: because slf4j will take over
(20.30.57) jdeolive: well... its hte sl4j guys that decidedd not to play nice
(20.30.59) aaime: and your log4j.property files wont' eve be used
(20.31.13) aaime: I'm not playing teh "who's to blame" game
(20.31.19) aaime: I want a solution that works
(20.31.23) jdeolive: fair enough
(20.31.25) jdeolive: but here is my issue
(20.31.33) jdeolive: the GT2Factory thing is a hack
(20.31.37) jdeolive: and hacks tend not to scale
(20.31.37) aaime: indeed it is
(20.31.42) jdeolive: like there will be another situation that comes up
(20.31.47) jdeolive: now if this hack was cosntrained to one place
(20.31.49) jdeolive: i woudl be fine
(20.31.51) jdeolive: but its not
(20.31.53) jdeolive: it rquires a mass update
(20.31.56) jdeolive: and that worries me
(20.32.05) aaime: the mass update is mostly automatable
(20.32.05) jdeolive: cause if it does not work in the feature for some reason
(20.32.11) jdeolive: we are stuck with it in many places
(20.32.13) jdeolive: still
(20.32.14) aaime: it's mantainace after it that will be troublesome
(20.32.36) jdeolive: also what about third party libraries that we use
(20.32.41) aaime: because people will have to remember to grab the logger from the gt2 factory
(20.32.42) acuster: jdeolive, do you have an alternative or only worries?
(20.32.48) jdeolive: i am guessing they will be grabbing loggers in a sane way
(20.32.58) jdeolive: my alternative is to do what most other applications do, choose one
(20.33.02) jdeolive: either commons, or sl4j
(20.33.06) jdeolive: not to roll our own stuff
(20.33.10) acuster: can referencing be cut out on its own?
(20.33.18) aaime: I guess not
(20.33.25) aaime: that would be a real mess
(20.33.26) acuster: because as you know matin has done phenomenal work using the logger
(20.33.43) jdeolive: too bad its not portable
(20.33.51) aaime: òne
(20.33.53) aaime: bah
(20.34.02) jdeolive: martin could run his i18n stuff through somethign that does what java logging does before it hits a logger
(20.34.03) acuster: well he did exactly what you suggest and picked one
(20.34.10) jdeolive: fair enough
(20.34.38) jdeolive: its too bad that choice basically limits the options of any application using geotools
(20.34.43) aaime: jdeolive, the current proposal seems to be the best compromise we can get
(20.35.07) acuster: is there any reason that if the proposal fails geotools is worse off than it is now?
(20.35.12) jdeolive: well.. if i get out voted i get out voted... but it wont get a +1 from me
(20.35.14) aaime: being a compromise it has its dark sides (on both parts)
(20.35.52) aaime: acuster, because we're playing differently than every other library in the world
(20.36.04) aaime: with the exception of the forecoming hibernate and wicket
(20.36.12) aaime: which get sucked on the slf4j dark side
(20.36.14) acuster: can you call GTLoggingFactory "Logger" ?
(20.36.26) acuster: so jdeolive would be happy
(20.36.28) aaime: Yes yes, that was my intention in fact
(20.36.33) aaime: that would not make him happy
(20.36.37) jdeolive: acuster: that does not make me happy
(20.36.41) aaime: you still have a choice when doing an import
(20.36.49) aaime: and you can make the wrong one
(20.37.06) acuster: LoggerForGT
(20.37.11) aaime: if you choose to import java logging by mistake, you end up with a class that does not
(20.37.21) jdeolive: what would make me happy is to do what everyone else does and just use commons logging... and if you cant configure logging in a sl4j container, tough, go blame the jetty guys
(20.37.24) aaime: redirect logging to log4j or whatever else we may want to use
(20.37.27) judd_taylor: maybe that's why I can't seem to catch any logger events from geotools... I use my own log4j setup...
(20.37.48) jdeolive: and there are alternatives for martin to be able to do his java logging specific stuff
(20.37.59) aaime: Yep, you have to configure java logging instead (and good nightmares doing so)
(20.38.53) acuster: jdeolive, you want martin to go and rewrite all his logging code in the most stable part of geotools just so new developers don't have to learn how geotools does logging?
(20.38.54) judd_taylor: Yeah.. I gave up on that.
(20.39.15) simboss ha abbandonato la stanza (quit: Connection timed out).
(20.39.20) acuster: that seems extereme
(20.39.29) jdeolive: yes, martin is the maintainer of 4 modules, the other 80 dont have those requirements
(20.40.01) jdeolive: i would be more then happy to help him modify the code
(20.40.02) acuster: if you had to do all the work, what would you do?
(20.40.18) jdeolive: if it would mean that geotools would actually behave in an application container, i think that is a win
(20.40.40) jdeolive: sure, if people decide to stick with java logging, thats fine too
(20.40.53) jdeolive: done make me do a massive search and replace to hack around the fact
(20.41.02) jdeolive: and dont make me read the developers guide before doing as something as simple as logging
(20.41.13) acuster: so the alternatives are: (1) a hack (2) rewrite martin's stuff (3) rewrite all the other logging stuff ?
(20.41.34) jdeolive: also, what about the third party library thing? this has no chance of scaling to third party libraries
(20.41.40) vheurteaux: aaah too bad Martin will be there in 30 mn
(20.41.41) jdeolive: so what do we do with spring in geoserveR?
(20.41.43) aaime: 3 is no option... java logging is just unacceptable in j2ee containers, remember?
(20.42.12) acuster: so we are down to two options?
(20.42.22) aaime: we hope commons logging does not get crippled and use the log4j settings
(20.42.35) acuster: one high risk, low work, the other low risk, high work?
(20.43.07) jgarnett: I am afraid I agree with you on this one justin; reading the developers guide to do logging correctly is bad news. Can I try a compromise (so everyone can shoot it down).
(20.43.22) vheurteaux: hey , You said that Java logging insn't unacceptable in JEE, but it seem's Glassfish is using it no ?
(20.43.40) jgarnett: Can we set up this loggin facade that returns a java logging interface; and help martin to use it in his code. We can make the log4j implementation be the default.
(20.43.45) aaime: vherteaux, you can replace the java logging subsystem with other classes if you're the container
(20.43.49) jgarnett: Everywhere else we can use log4j straight up.
(20.43.49) aaime: but I can't do it as geoserver
(20.44.02) vheurteaux: ok
(20.44.26) aaime: jgarnett... I prefer the hack for sure
(20.44.40) jgarnett: the logging facade == the hack
(20.44.47) aaime: it allows creating other redirectors for other logging api
(20.45.05) aaime: I like log4j, but it seems almost dead to me
(20.45.13) aaime: the author of log4j created slf4j
(20.45.17) jgarnett: except for that whole used everywhere?
(20.45.43) jgarnett: And slf4j is screwed up for the reasons cited above; it conflicts with log4j use...
(20.46.01) aaime: I'm not really buying that people has to read the developers guide to know about how we do logging
(20.46.22) aaime: am I the only one diong "monkey see, monkey do" when approaching a library I'm not familiar with?
(20.46.50) jgarnett ha abbandonato la stanza (quit: Read error: 104 (Connection reset by peer)).
(20.46.56) aaime: even today when I have to create a logger in a class I copy past and fix from another class
(20.46.56) jgarnett [n=Jody@anonymised.com] è entrato nella stanza.
(20.46.59) judd_taylor: aaime: no you're not, but the code looks like normal log4j stuff, which is why I had no idea it was any different...
(20.47.21) aaime: Ah, damn mondern IDE with folding... have a look in the imports
(20.47.28) aaime: (also, the logging level names are different)
(20.47.57) judd_taylor: you can create custom log levels in log4j, which is what I had assumed.
(20.48.19) judd_taylor: My stuff imports commons log4j, and I rarely look at the library imports.
(20.48.43) jdeolive: aaime: so what about spring in geoserver?
(20.48.46) judd_taylor: Having to look at the source of a lib you're trying to use is much worse than having to look through a dev guide...
(20.48.52) aaime: what about it?
(20.49.06) aaime: if we deploy in a standard Jetty it's screwed but there is nothing I can do about it
(20.49.15) jdeolive: how can we configure its logging? since it wont be calling GT2LogFactory
(20.49.18) Eclesia: i must go ++
(20.49.24) Eclesia è ora conosciuto come Eclesia_afk
(20.49.34) aaime: We do configure log4j and have everything redirected to it
(20.49.46) aaime: we won't need to manually touch the logging levels anymore
(20.50.04) aaime: since the Log4jLogger will directly wrap a log4j logger
(20.50.16) aaime: use its isLoggable(xxx) and whatnot methods
(20.50.22) aaime: so no configuration will be needed anymore
(20.50.30) simboss___ è ora conosciuto come simboss
(20.50.31) aaime: We'll be in trouble only if
(20.50.42) simboss: ciao guys!
(20.50.45) aaime: we deploy in a container that replaces commons-loggin on our backs
(20.50.49) aaime: but mind
(20.51.08) aaime: not we as in "geotools", geotools will keep on being happily redirectted to log4j
(20.51.20) aaime: only the libraries using commons logging will be cut out
(20.51.41) jdeolive: does not spring use commons?
(20.51.47) aaime: yes so what?
(20.52.00) jdeolive: ok, i am confused
(20.52.13) aaime: Ah, ok ok, let's do a recap
(20.52.15) jdeolive: regardless... it still gets a -1, i would prefer that we just live with the bug in jetty
(20.52.39) aaime: If you use commons logging and slf4j is in the path before it (containers can make sure this happens)
(20.52.45) aaime: then you grab a commons logging logger
(20.52.56) aaime: you get a slf4j replacement instead
(20.53.09) aaime: (because the replacemnt classes are before the good ones in the classpath)
(20.53.31) aaime: and your log statements get redirected to slf4j which in turns redirects them to whatever it pleases
(20.53.46) aaime: (bing slf4j just a facade for a real logging api)
(20.54.00) aaime: In the jetty case, they get redirected to "simple logging"
(20.54.15) aaime: If we do the hack in geotools
(20.54.23) aaime: we call Gt2LogFactory.getLogger
(20.54.32) aaime: that builds up a Log4jLogger
(20.54.40) aaime: which talks directly to log4j
(20.54.54) jgarnett: (aside: OSGeo iccubation meeting is over; seems the board may of watered down foundation benifit to just "good advice"; others still think the the legal protection is in the cards; who knows what OSGeo is good for)
(20.55.00) aaime: in a sense, we are safe from slf4j tricks because we roll out our own "commons logging"
(20.55.25) aaime: does this make sense?
(20.55.43) jdeolive: yes
(20.55.55) jdeolive: the issue makes sense
(20.56.41) aaime: hmmm.... I guess this ends up the topic?
(20.56.46) jgarnett: I have a question; will contains (the ones that replace log4j on you) eventually be able to handle slf4j ?
(20.56.59) aaime: contains?
(20.57.12) aaime: containers you mean
(20.57.17) judd_taylor: if it were me... I'd have to code issue a warning if slf4j was in use, and to hell with it if someone is using slf4j... they made their own problems by using it.
(20.57.45) jdeolive: judd_taylor++
(20.57.46) aaime: What do you mean by handle jgarnett?
(20.57.48) judd_taylor: I think doing the same thing (rolling another commons with gt) doesn't make anything better in the long run
(20.58.11) jgarnett: Will they eventually configure slf4j behind our back (much the same way they did log4j)
(20.58.30) aaime: jgarnett, they can't change the api
(20.58.44) aaime: but they can load on our back replacement api if we use "well known ones"
(20.59.04) aaime: the replacement trick is just to put a binary compatible replacement library in the classpath before yours
(20.59.40) jgarnett: understood; that is hard core.
(21.00.01) aaime: Moreover, I want the option to switch back to java logging
(21.00.10) judd_taylor: but isn't that exactly what slf4j is doing wrong in the 1st place? This is 2 wrongs make a right here...
(21.00.19) aaime: think of those containers that are making it really hard to use log4j (glassfish)
(21.00.20) jgarnett: Looking at slf4j-jcl.jar which passes everything over to JCL
(21.00.40) aaime: people may end up preferring to use java logging there and give up UI based log level configuration
(21.01.09) aaime: jgarnett, yes, but you have to hack the container using slf4j in order to use that
(21.01.22) aaime: slf4j is not a "standard" java api
(21.01.30) aaime: every jar has exactly the same binary interface
(21.01.38) aaime: you "plug in" by chaning the jar
(21.01.46) aaime: you can't have more than one in the classpath
(21.01.52) aaime: not sure if I'm making any sense
(21.02.27) aaime: You keep on working againt the same class (class, not interface)
(21.02.41) aaime: what you get is different because you put a different jar in the classpath
(21.03.06) aaime: When you do Log.getLog(xxx) in slf4j
(21.03.15) aaime: the actual Log class you get depends on what you put in the classpath
(21.03.29) aaime: but there are, say, 10 Log classes coded differently in 10 jars
(21.03.35) aaime: each redirecting to a different logging api
(21.04.00) judd_taylor: That is just soo wrong. What if you need to use both??
(21.04.30) aaime: Unlikely? You would not do that with commons loggin either
(21.04.37) judd_taylor: Does the classpath thing apply to regular log4j usage, or is it just a slf4j thing?
(21.04.57) aaime: at startup commons logging will instantiate the right logger subclass according to the api you chose anyways
(21.05.03) aaime: it's a slf4j thing
(21.05.09) aaime: but they chose to extend that reasoning
(21.05.24) aaime: and they created binary replacement for commons logging and for log4j too
(21.05.31) aaime: you put those in the classpath
(21.05.42) aaime: and you'll end up using slf4j without knowing
(21.05.52) aaime: (and your code is still coded against teh, say, log4j api)
(21.06.13) aaime: so for example
(21.06.28) aaime: say you have an app coded against log4j
(21.06.32) aaime: you put in the classpth
(21.06.32) acuster: aaime, it sounds like you are not reaching a concensus
(21.06.51) acuster: and you're going to need a formal proposal thingy
(21.06.51) aaime: I know sorry... Martin is not here so I kept on going
(21.07.00) judd_taylor: which is why I say to heck with slf4j. I would just ignore it, and at most print a warning if it's use is detected. Coding around slf4j would mean committing the same code sins that slf4j did in the first place.
(21.07.03) aaime: I know, I'll do that anyways
(21.07.14) jgarnett: okay meeting is out of time; I will revist the rest when posted.
(21.07.35) aaime: acuster, the hack is the only practical and short term solution I see
(21.08.04) aaime: (the only one that will allow GeoServer 1.6 to be released with a working logging subsystem anyways)
(21.08.23) jdeolive: to say its not working is a bit of an overstatement
(21.09.06) aaime: to say it's working means you did not try to change logging levels
(21.09.23) acuster: this almost seems like a geoserver religious war
(21.09.33) jdeolive: haha
(21.09.34) aaime: the only alternative is go back to 1.5.3 and use java loggin only
(21.09.42) judd_taylor: I don't even use geoserver ha
(21.10.18) aaime: jdeolive, try the following
(21.10.21) jdeolive: aaime: i think you need to check your definition of working... not beeing able to configure it via property file in one container does not mean it does not work
(21.10.37) aaime: start geoserver, change the logging level to geotools_developer_logging, and do some wms requests
(21.10.52) aaime: and see if you can find any "debug" level statement in the logs
(21.11.12) aaime: It does not work because the only have to have a logger level be configured
(21.11.22) aaime: is to change the logging level after the logger has been created
(21.11.33) aaime: to me this is "completely broken" (TM)
(21.11.58) aaime: if you're not satisfied, when you're done with the example above
(21.12.06) aaime: apply/save, shut down geoserver, restart
(21.12.15) aaime: your loggers will still be operating an INFO level
(21.12.34) jdeolive: so why am i able to debug from my ide?
(21.12.50) aaime: because you change the logging level after your loggers have been created
(21.13.30) aaime: you first do a request, see it does not work, switch to debug and you see the debug statements
(21.13.40) aaime: no wonder, the first request made all the relevant loggers be created
(21.14.47) aaime: Don't trust me, try it
(21.15.43) jdeolive: i trust you, but your not going to convince me that a hack in geotools is the solution, i realize its the shortest path
(21.16.06) jdeolive: anyways, luckily for you its not my decision
(21.16.09) jdeolive: and i only get one vote
(21.16.15) jdeolive: so dont worry too much about it
(21.16.15) buci: sorry, guys, I have to go. I'll send a mail to the list with my questions.
(21.16.19) aaime: Look, we're going to release geoserver 1.6 in possibly two weeks
(21.16.25) buci: bye
(21.16.38) aaime: we can't release it in the current state
(21.16.39) buci ha abbandonato la stanza (quit: "Client exited").
(21.16.53) aaime: ops... vherteaux, was Martin around now?
(21.17.43) jdeolive: aaime: should we not let the psc decide that?
(21.18.26) aaime: I like consesus when it's possible
(21.18.54) jgarnett: aaime;jdeolive can we get a proposal page up. Showing alternatives if nothing else. It sounds like there are technical problems no matter what we do ... we can however do something.
(21.19.40) jgarnett: I have been reading logging apis; but I am unable to catch up to the discssion you guys are having here.
(21.19.41) aaime: I'll try to put up a proosal page asap
(21.19.45) acuster: and that should close the meeting no?
(21.19.52) jgarnett: thanks muchly aaime; sorry I have not had much to contribute.
(21.19.59) acuster: going once,
(21.20.04) jgarnett: gone!
(21.20.10) judd_taylor: if martins' not here...
(21.20.11) acuster: twice,
(21.20.21) acuster: done.
(21.20.23) aaime: vheurteaux
(21.20.32) aaime: Is Martin around?
(21.20.47) jgarnett: aaime you may try setting up a breakout IRC with Martin
(21.21.01) aaime: I don't need to, we both agree on the proposal
(21.21.28) aaime: even if for different reasons
(21.21.33) vheurteaux: aaime: Martin will be there in a couple of minutes
(21.21.38) aaime: Martin wants to keep on using java logging
(21.21.43) vheurteaux: he just call me
(21.21.53) aaime: I want a solution that is compatible with the geoserver release timeframe
(21.22.14) aaime: (I still have the option of going back to java loggin, but that would waste Saul Farber work and I don't want to walk that path)
(21.23.14) vheurteaux: yeeeaaa Martin is here
(21.23.20) vheurteaux: pfeeew !
(21.23.52) vheurteaux è ora conosciuto come desruisseaux
(21.23.56) ***jdeolive is still unaware that the decision is up to aaime
(21.24.06) aaime: up to me?
(21.24.13) desruisseaux: I"m here
(21.24.19) aaime: That was my opinion
(21.24.23) aaime: no my decision
(21.24.31) aaime: the geoserver decision will be made by the psc
(21.25.22) groldan: yeah, aaime is doing a great job both on digging into the situation as in communicating his findings
(21.26.11) judd_taylor: Ok, I've added a new JIRA issue for the CRS equals problem (since I didn't see anything after searching it). http://jira.codehaus.org/browse/GEOT-1553
(21.28.16) acuster: desruisseaux, judd_taylor's bug is probably for you
(21.28.19) acuster: (salut)
(21.28.42) acuster: logs posted
(21.28.43) judd_taylor: Note, this is just the tip of the iceberg of problems I've found trying to get an orthographic projection going. I'm waiting to get the thing worked around before I start griping about the rest.
(21.29.31) desruisseaux: I know it is a controversial aspect, but I think that the claim that java logging is not suitable to server is urban legend. Glasfish uses java logging natively, and it is not a toy. We use javalogging with Geoserver (we disabled all those log4j stuff) and it work perfectly well for us. The claim that javalogging is jvm wide is just plain false, except for "per classloader" thing, but a JEE can easily fix that with their own logic like
(21.30.18) judd_taylor: One thing frustrating me is that if I'm doing some thing wrong, it still "sorta" works... leading me off in the wrong direction... I'm still not sure I even get the gist of what I'm trying to do.
(21.30.57) desruisseaux: Judd, what is the issue you are facing?
(21.31.13) simboss___ [n=chatzill@anonymised.com] è entrato nella stanza.
(21.31.19) acuster: http://docs.codehaus.org/display/GEOTOOLS/2007/10/29
(21.32.02) judd_taylor: I've got to add and display some layers on an orthographic map. Some of them are already in the same projection, and some are in lat/long (DefaultGeographicCRS.WGS84), and I'm just running around in circles getting this to work.
(21.32.13) judd_taylor: I can get one part working, and then other parts start failing...
(21.33.11) judd_taylor: I've so far figure that I need to set the ortho layers to a ProjectedCRS, and not a DerivedCRS, but now when I set a WGS84 layer to the WGS84 CRS, it's reprojecting "on-the-fly" improperly.
(21.33.29) judd_taylor: Stuff is not showing up in the right places.
(21.34.02) acuster: you're doing this in JMapPane from geotools 2.4?
(21.34.05) judd_taylor: I've tried a ReprojectFeatureReader, (which I had to wrap with a fault tolerant version, since this is ortho), and it doesn't make it any better...
(21.34.09) desruisseaux: Yes my fault, I remember that I told you a few weeks ago to use DerivedCRS but it was I mistake of mine (I wrote that too fast). ProjectedCRS is right.
(21.34.10) judd_taylor: 2.3.1
(21.34.20) aaime: desriusseax, java logging works in the container only if the container itself replaces the standard implementation with its own
(21.34.25) judd_taylor: woo hoo, that means I'm doing something right now!
(21.34.39) aaime: geoserver is no container, we don't have that luxury
