Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

[06:16:05 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-103-163.nwrknj.east.verizon.net) has joined ##uportal
[08:03:36 EDT(-0400)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[08:49:23 EDT(-0400)] * colinclark (n=atrcwrk2@128.100.62.140) has joined ##uportal
[09:16:38 EDT(-0400)] * agherna (n=argherna@cites-agherna01.ci.uiuc.edu) has joined ##uportal
[10:35:57 EDT(-0400)] * EricDalquist (n=EricDalq@user147-39.wireless.utoronto.ca) has joined ##uportal
[10:37:15 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[10:40:23 EDT(-0400)] <EricDalquist> wow big old party in here today
[10:42:13 EDT(-0400)] <lescour> i finally made it back after a long trek into cas->horde/imp-imap->imap proxy->pam_cas->sasl
[10:43:29 EDT(-0400)] <esm> never try to settle on a house in two weeks unless you really need to.
[10:44:26 EDT(-0400)] <EricDalquist> (smile)
[10:45:00 EDT(-0400)] <esm> i'm finally getting around to patching our portal for the threading bug.
[10:45:36 EDT(-0400)] <EricDalquist> fun fun
[10:51:51 EDT(-0400)] <esm> is there a 'patch' equivalent for windows
[10:52:23 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[10:52:27 EDT(-0400)] <pberry> whoa
[10:52:35 EDT(-0400)] <EricDalquist> um
[10:52:36 EDT(-0400)] <EricDalquist> eclipse
[10:52:37 EDT(-0400)] <pberry> I guess I'm late and the party already started
[10:53:11 EDT(-0400)] <EricDalquist> I like this
[10:54:19 EDT(-0400)] <esm> windows sucks.
[11:04:08 EDT(-0400)] <pberry> mostly
[11:04:15 EDT(-0400)] <EricDalquist> yup
[11:04:31 EDT(-0400)] <pberry> I mean, there just isn't that much to add...
[11:06:04 EDT(-0400)] <esm> in the midst of home-buying, work insanity, and open source project insanity, I am heading to the local gamestop tonight to pick up my copy of Halo 3.
[11:07:47 EDT(-0400)] <pberry> yeah, because...that will calm things down
[11:08:07 EDT(-0400)] <EricDalquist> and free up much needed time
[11:08:32 EDT(-0400)] <esm> my stress level should go down considerably.
[11:43:11 EDT(-0400)] <esm> lol
[11:43:17 EDT(-0400)] <esm> tapestry and dr. suess
[11:43:17 EDT(-0400)] <esm> http://tapestryjava.blogspot.com/2007/09/dr-seuss-visits-tapestry-mailing-list.html
[12:18:14 EDT(-0400)] <pberry> fine, go play Halo...see if I care
[12:25:22 EDT(-0400)] <apetro_work_desk> lescour in-absentia that's excellent news about proxy cas to get email!
[12:33:17 EDT(-0400)] * colinclark (n=atrcwrk2@128.100.62.140) has joined ##uportal
[13:35:50 EDT(-0400)] * EricDalquist (n=EricDalq@jozuz.oise.utoronto.ca) has joined ##uportal
[13:39:37 EDT(-0400)] * colinclark (n=atrcwrk2@jozuz.oise.utoronto.ca) has joined ##uportal
[13:40:39 EDT(-0400)] * colinclark (n=atrcwrk2@jozuz.oise.utoronto.ca) has left ##uportal
[14:05:02 EDT(-0400)] * colinclar1 (n=atrcwrk2@jozuz.oise.utoronto.ca) has joined ##uportal
[14:05:55 EDT(-0400)] <EricDalquist> so what do people thing of using a static lookup to access the uP3 WebAppContext versus static injectors in provide references to needed beans?
[14:08:33 EDT(-0400)] <EricDalquist> The first one is a bit of a hack because it uses a ServletContextListener to keep a reference to the ServletContext and then wraps Springs WebApplictionContextUtils to provide access to the WebApplicationContext where client code doesn't have access to the ServletContext
[14:09:27 EDT(-0400)] <EricDalquist> The second one exposes static setter methods for each dependency and then uses Springs static method calling capabilities to inject dependencies
[14:09:59 EDT(-0400)] <EricDalquist> I just committed the first option to the trunk and am now exploring the second
[14:10:09 EDT(-0400)] <EricDalquist> and would love people to shoot holes in both ideads
[14:10:12 EDT(-0400)] <EricDalquist> ideas*
[14:14:25 EDT(-0400)] <agherna> hacks bad...
[14:14:33 EDT(-0400)] <EricDalquist> well
[14:14:38 EDT(-0400)] <EricDalquist> both options are hacks
[14:14:57 EDT(-0400)] <EricDalquist> the only other option is to re-write very large chunks to play nice with an ioc container
[14:15:03 EDT(-0400)] <EricDalquist> which really isn't an option
[14:15:55 EDT(-0400)] <EricDalquist> the second method is semi-ioc like
[14:16:01 EDT(-0400)] <agherna> hacks bad... how much rope does that give somebody who wanted to modify the framework?
[14:16:05 EDT(-0400)] <EricDalquist> but doesn't play as nice with servlet/spring context reloading
[14:16:23 EDT(-0400)] <EricDalquist> both options give less rope than exists now
[14:16:57 EDT(-0400)] <EricDalquist> the first option that I have working actually deals nicely now with the uportal web-app reloading in-place
[14:17:02 EDT(-0400)] <EricDalquist> well mostly nice
[14:17:05 EDT(-0400)] <agherna> but is it more rope than re-writing very large chunks of code?
[14:17:11 EDT(-0400)] <EricDalquist> but it actually still runs after the reload
[14:17:34 EDT(-0400)] <EricDalquist> oh yes
[14:17:40 EDT(-0400)] <agherna> and what are those chunks of code that would need to be re-written (50,000 ft view please)?
[14:17:51 EDT(-0400)] <EricDalquist> re-writing it all to be 'correct' would entale making the entire internals of the portal ioc managed
[14:18:18 EDT(-0400)] <agherna> is that what up3 is converging to?
[14:18:26 EDT(-0400)] <EricDalquist> this is up3 work
[14:18:31 EDT(-0400)] <EricDalquist> that would be the end goal
[14:18:40 EDT(-0400)] <EricDalquist> but it really isn't a practical task in the timeline we have
[14:19:13 EDT(-0400)] <agherna> is there a way to hide that code that needs to be re-written with a wrapper of some kind so I don't go changing it if I have to?
[14:19:45 EDT(-0400)] <EricDalquist> I'm not sure ... I'm not thinking so
[14:20:14 EDT(-0400)] <EricDalquist> the changeset from the first option: http://developer.ja-sig.org/source/changelog/jasigsvn/?cs=42483
[14:20:24 EDT(-0400)] <agherna> is it something that will need to be dragged along for years (like the old UserInstance hacks we used to have to do)?
[14:20:53 EDT(-0400)] <EricDalquist> either option? it will need to be dragged along until someone has the time to do a full re-write to use ioc at the core
[14:21:29 EDT(-0400)] <agherna> I see.
[14:21:32 EDT(-0400)] <EricDalquist> this little bit of work is an incremental step toward that (using a spring ContextLoaderListener, having only one context object, having it play nice with context reloads)
[14:22:08 EDT(-0400)] <EricDalquist> I think practically the approach to getting ioc at the core is going to be an incremental one
[14:22:20 EDT(-0400)] <EricDalquist> like how do we fix the CError channel to have a bean injected into it
[14:22:32 EDT(-0400)] <EricDalquist> beans in uPortal are created using Class.newInstance
[14:22:39 EDT(-0400)] <EricDalquist> not very spring context compatible
[14:22:45 EDT(-0400)] <EricDalquist> er channels not beans
[14:22:53 EDT(-0400)] <agherna> as long as its documented well, either solution is fine.
[14:23:05 EDT(-0400)] <agherna> at least fine with me
[14:23:23 EDT(-0400)] <EricDalquist> well with the first option this static locator for the context is marked as deprecated with a big description of why this is bad and what the right way is
[14:24:01 EDT(-0400)] <EricDalquist> which I think I like a bit more since the 'bad' part is centralized and if it is removed it is glaringly obvious all the places in the code that were using it and that need to be fixed
[14:24:20 EDT(-0400)] <EricDalquist> the static injection approach seems a bit more creepish
[14:24:26 EDT(-0400)] <EricDalquist> since each one is a bad pattern
[14:24:33 EDT(-0400)] <EricDalquist> and would need to be documented as such
[14:24:51 EDT(-0400)] <EricDalquist> and there is no central change that can be made to highlight where they are so they can be fixed
[15:03:43 EDT(-0400)] * colinclar1 (n=atrcwrk2@jozuz.oise.utoronto.ca) has left ##uportal
[15:04:03 EDT(-0400)] <esm> static injection would be documented in the spring xml file right?
[15:04:09 EDT(-0400)] <EricDalquist> yes
[15:04:18 EDT(-0400)] <EricDalquist> and I could put it all in its own .xml file
[15:04:32 EDT(-0400)] <EricDalquist> with some big comment about how this is horribly evil bad & worng
[15:04:34 EDT(-0400)] <EricDalquist> wrong too
[15:05:05 EDT(-0400)] <esm> if i wanted to write integration tests using static lookups, I have to mock up a PortletApplicationContextListener right?
[15:05:13 EDT(-0400)] <EricDalquist> yeah
[15:05:18 EDT(-0400)] <EricDalquist> which is a big issu
[15:05:19 EDT(-0400)] <EricDalquist> issue
[15:05:23 EDT(-0400)] <EricDalquist> man I can't type
[15:05:31 EDT(-0400)] <esm> oh it is? I thought that would be not too bad
[15:05:37 EDT(-0400)] <EricDalquist> oh no
[15:05:42 EDT(-0400)] <EricDalquist> wait
[15:05:47 EDT(-0400)] <EricDalquist> mocking the listener?
[15:05:53 EDT(-0400)] <esm> yeah
[15:05:59 EDT(-0400)] <EricDalquist> well you would just need to call its init method with a ServletContext
[15:06:13 EDT(-0400)] <EricDalquist> since the WebApplicationContext methods are static you can't mock them
[15:06:29 EDT(-0400)] <EricDalquist> you can just init it with a mock ServletContext
[15:06:43 EDT(-0400)] <esm> right.
[15:06:57 EDT(-0400)] <esm> ok so it is slightly easier to test using static injection, is that fair to say?
[15:07:23 EDT(-0400)] <EricDalquist> correct
[15:07:43 EDT(-0400)] <EricDalquist> since then you in theory only need to staticly inject the dependency
[15:07:47 EDT(-0400)] <EricDalquist> so its less to mock up
[15:07:57 EDT(-0400)] <esm> right
[15:08:15 EDT(-0400)] <esm> so testability is probably - by itself - a reason to choose one over the other
[15:08:20 EDT(-0400)] <esm> sory
[15:08:25 EDT(-0400)] <esm> is not a reason
[15:08:41 EDT(-0400)] <EricDalquist> ah
[15:08:56 EDT(-0400)] <EricDalquist> yeah
[15:09:20 EDT(-0400)] <EricDalquist> I'm thinking the central locator is going to deal with context reloads better too
[15:09:32 EDT(-0400)] <esm> probably.
[15:09:52 EDT(-0400)] <esm> With a lookup it is a little harder to know what a classes dependencies are.
[15:10:11 EDT(-0400)] <EricDalquist> in what way
[15:10:55 EDT(-0400)] <esm> in that you can look at the method signature of the setter methods of a class to see what it needs
[15:11:02 EDT(-0400)] <EricDalquist> ah yes
[15:11:32 EDT(-0400)] <esm> the lookup strategy exposes the entire context to the caller
[15:11:41 EDT(-0400)] <esm> i don't think that is a bad thing per se
[15:12:47 EDT(-0400)] <EricDalquist> yeah ... what the lookup hack is a work-around for is that most of the portal code that needed access to the app context didn't have a reference to the ServletContext
[15:12:54 EDT(-0400)] <esm> right.
[15:13:12 EDT(-0400)] <EricDalquist> since if code could just use WebApplicatonContextUtils directly I wouldn't care
[15:13:35 EDT(-0400)] <EricDalquist> so I think the locator is closer to what we would be doing if we could do it 'kind of right'
[15:13:55 EDT(-0400)] <EricDalquist> where 'completely right' is actually doing everything in the ioc container
[15:15:00 EDT(-0400)] <esm> the static setter methods would be called by the ioc container right?
[15:15:09 EDT(-0400)] <EricDalquist> yes
[15:15:29 EDT(-0400)] <EricDalquist> so that isn't so bad because it is 'kind of ioc but not really'
[15:16:12 EDT(-0400)] <esm> I'm suggesting that static injectetion by an IoC container is more IoC-like than a locator patter.
[15:16:39 EDT(-0400)] <EricDalquist> I think that is a good point
[15:16:39 EDT(-0400)] <esm> but i'm not arguing for it- i'm just being a sounding board
[15:16:48 EDT(-0400)] <EricDalquist> (smile)
[15:16:56 EDT(-0400)] <esm> i think that either way does what you need it to do
[15:17:20 EDT(-0400)] <EricDalquist> And I think my fear of the static injector pattern creeping from its original usage is too big
[15:17:58 EDT(-0400)] <esm> I've used the listener + locater pattern before and it was fine, i didn't have any trouble
[15:18:15 EDT(-0400)] <EricDalquist> well the hard part is from a plain technical point of view it's a wash
[15:18:23 EDT(-0400)] <esm> yeah
[15:18:49 EDT(-0400)] <esm> and since you already committed the first way of doing it ... (smile)
[15:18:53 EDT(-0400)] <esm> done!~
[15:18:56 EDT(-0400)] <EricDalquist> yup
[15:19:38 EDT(-0400)] <EricDalquist> so I'm going to do some more list emails but I'm thinking I'm going to want to start design talks about pluto 1.1/2.0 integration very soon
[15:19:46 EDT(-0400)] <esm> sweet very cool
[15:19:52 EDT(-0400)] <EricDalquist> As much as I'd love to spend time springifying existing code
[15:20:04 EDT(-0400)] <EricDalquist> just getting the little bit of clean up I just did is all that really needs to be done
[15:20:14 EDT(-0400)] <EricDalquist> and then the rest can be done piecemeal
[15:20:21 EDT(-0400)] <esm> sounds good to me
[15:20:22 EDT(-0400)] <EricDalquist> so how is 2.0 progress going?
[15:20:35 EDT(-0400)] <esm> i've been out of touch the past couple of weeks
[15:20:38 EDT(-0400)] <esm> it was going strong
[15:20:41 EDT(-0400)] <EricDalquist> cool
[15:20:49 EDT(-0400)] <EricDalquist> are there any planned dates yet?
[15:22:28 EDT(-0400)] <esm> not that I know of.
[15:22:34 EDT(-0400)] <EricDalquist> I
[15:22:35 EDT(-0400)] <esm> the RI has to be implemented before the spec is released
[15:22:40 EDT(-0400)] <EricDalquist> yeah
[15:22:46 EDT(-0400)] <EricDalquist> I'm just curious about timing
[15:22:55 EDT(-0400)] <EricDalquist> it would be really neat if uP3 in december used pluto 2
[15:23:10 EDT(-0400)] <EricDalquist> but I'm not holding my breath for it
[15:23:38 EDT(-0400)] <esm> my gut feeling is that up3 in dec is best served using 1.1. If pluto 2 is out, it will likely be not fully baked, and there will be problems/bugs.
[15:24:35 EDT(-0400)] <esm> but I don't have any information, official or otherwise, about when 286 is goign to be final.
[15:24:50 EDT(-0400)] <EricDalquist> yeah that is my feeling too
[15:26:33 EDT(-0400)] <EricDalquist> brb
[15:29:36 EDT(-0400)] <EricDalquist> oi
[15:29:44 EDT(-0400)] <EricDalquist> so time to go look at the roadmap and see whats next
[16:00:08 EDT(-0400)] <esm> http://opensource.atlassian.com/projects/spring/browse/SPR-3905 (smile)
[16:00:38 EDT(-0400)] <EricDalquist> nice
[16:01:05 EDT(-0400)] <esm> except that the problem seems to be with Jetty and Pluto Portal
[16:01:23 EDT(-0400)] <esm> so
[16:01:29 EDT(-0400)] <esm> I'll try to find some time and check it out
[16:36:07 EDT(-0400)] <EricDalquist> yay ... deleting deprecated code is fun!
[16:37:05 EDT(-0400)] <esm> lol yeah it is a satisfying feeling to delete code.
[16:37:12 EDT(-0400)] <EricDalquist> yup
[16:37:15 EDT(-0400)] <esm> as long as you mean to delete it.
[16:37:26 EDT(-0400)] <EricDalquist> well that is what 'svn revert' is for
[16:40:43 EDT(-0400)] <esm> wow.
[16:40:51 EDT(-0400)] <esm> please do not "put everything in shared"
[16:40:52 EDT(-0400)] <EricDalquist> ?
[16:41:08 EDT(-0400)] <esm> reading the portlet developer framework thread
[16:41:17 EDT(-0400)] <EricDalquist> ah
[16:41:18 EDT(-0400)] <EricDalquist> yeah
[16:41:27 EDT(-0400)] <EricDalquist> interesting discussion
[16:41:30 EDT(-0400)] <EricDalquist> great for the -user list
[16:41:31 EDT(-0400)] <esm> i haven't read the list in a while.
[16:41:32 EDT(-0400)] <esm> yeah
[16:47:21 EDT(-0400)] <esm> later all have a good afternoon/evening
[16:52:48 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-103-163.nwrknj.east.verizon.net) has joined ##uportal
[17:24:48 EDT(-0400)] * EricDalquist (n=EricDalq@wm280hi-109.102.Maroon.NetSurf.Net) has joined ##uportal

  • No labels