Page Comparison

[05:32:30 EDT(-0400)] * JASIGLogBot (i=jasigch@jasigch.Princeton.EDU) has joined ##uportal
[05:32:30 EDT(-0400)] * Topic is 'http://rafb.net/paste/ to paste. Don't forget about our #fluid-work neighbors' set by EricDalquist on 2007-10-02 14:18:09 EDT(-0400)
[06:56:00 EDT(-0400)] * JASIGLogBot (i=jasigch@jasigch.Princeton.EDU) has joined ##uportal
[06:56:00 EDT(-0400)] * Topic is 'http://rafb.net/paste/ to paste. Don't forget about our #fluid-work neighbors' set by EricDalquist on 2007-10-02 14:18:09 EDT(-0400)
[09:28:45 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:00:33 EDT(-0400)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[10:11:51 EDT(-0400)] * clown (n=chatzill@guiseppi.atrc.utoronto.ca) has joined ##uportal
[10:57:01 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[11:14:54 EDT(-0400)] * ac_chan (n=alex@tempoutsidepix.pratt.edu) has joined ##uportal
[11:14:59 EDT(-0400)] <ac_chan> hello
[11:16:04 EDT(-0400)] <ac_chan> 2nd day of portal use everything a okay
[11:39:56 EDT(-0400)] * michelled (n=team@142.150.154.114) has joined ##uportal
[11:49:59 EDT(-0400)] <pberry> excellent
[12:44:12 EDT(-0400)] <EricDalquist> hey, I'm looking for recommendations on a good Spring book for someone that has never used it before
[12:52:13 EDT(-0400)] <ac_chan> is spring the framework that uportal uses?
[13:02:02 EDT(-0400)] <colinclark> EricDalquist: I haven't read it but Pro Spring by Rob Harrop seems pretty comprehensive.
[13:03:02 EDT(-0400)] <colinclark> For someone with a classic J2EE background, J2EE without EJB is very good as well, but more architectural and less hands-on.
[13:55:33 EDT(-0400)] <EricDalquist> thanks for the ideas colinclark, I'll look into those
[13:55:58 EDT(-0400)] <EricDalquist> ac_chan: spring is used by uPortal in a limited fashion right now, that is expanding with each release though.
[14:03:52 EDT(-0400)] <ac_chan> ok
[14:08:16 EDT(-0400)] <EricDalquist> most developers involved with uPortal are big proponents of the spring framework and use it extensively as well
[15:26:52 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[15:49:41 EDT(-0400)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[15:50:02 EDT(-0400)] <jayshao> hey hey hey
[15:50:08 EDT(-0400)] <EricDalquist> hey there
[15:50:10 EDT(-0400)] <EricDalquist> so
[15:50:12 EDT(-0400)] <EricDalquist> uPortal URLs
[15:50:16 EDT(-0400)] <jayshao> heh
[15:50:20 EDT(-0400)] <jayshao> ugly little buggers
[15:50:24 EDT(-0400)] <EricDalquist> you can only target a single channel with parameters correct?
[15:50:31 EDT(-0400)] <jayshao> hmmm...
[15:50:37 EDT(-0400)] <jayshao> with the channel parameters yet
[15:50:38 EDT(-0400)] <jayshao> yes
[15:50:42 EDT(-0400)] <jayshao> not sure about the theme parameters
[15:50:45 EDT(-0400)] <EricDalquist> I'm looking at ChannelManager.processRequestChannelParameters
[15:50:47 EDT(-0400)] <EricDalquist> ah
[15:50:52 EDT(-0400)] <EricDalquist> I'll have to look at those too
[15:51:10 EDT(-0400)] <EricDalquist> just for background ... I'm at the point of working on portlet URL generation/processing for pluto 1.1 integration
[15:51:16 EDT(-0400)] <jayshao> right – not sure how smart ChannelManager is about pulling them out or something
[15:51:17 EDT(-0400)] <jayshao> nice
[15:51:30 EDT(-0400)] <EricDalquist> and I decided to 'do it right' and port over the url parameter processor/constructor framework we had in the sandbox
[15:51:44 EDT(-0400)] <EricDalquist> so I just want to make sure I understand how the URLs are parsed right now
[15:52:15 EDT(-0400)] <jayshao> I suspect you have to be a little careful
[15:52:15 EDT(-0400)] <EricDalquist> yeah ChannelManager looks like it finds a single channelTarget parameter and all URL parameters go to it
[15:52:33 EDT(-0400)] <jayshao> IChannels have traditionally been lax about prefixing and whatnot
[15:52:43 EDT(-0400)] <EricDalquist> yeah ... I know
[15:52:53 EDT(-0400)] <jayshao> it would be nice to expose URL generation as a service and encourage it as a channel best practice
[15:53:02 EDT(-0400)] <jayshao> maybe deprecate directly generating URLs for 3.0
[15:53:05 EDT(-0400)] <EricDalquist> that will be part of this eventually I hope
[15:53:38 EDT(-0400)] <EricDalquist> ok so that answers that, or at least confirms what I was thinking, that only a single channel can be targeted by parameters at a time
[15:53:44 EDT(-0400)] <jayshao> I don't think any channels rely on say grabbing a parameter set by another channel
[15:53:50 EDT(-0400)] <jayshao> though you could probably make it work
[15:53:55 EDT(-0400)] <EricDalquist> I hope not
[15:53:58 EDT(-0400)] <EricDalquist> that is just not nice
[15:54:10 EDT(-0400)] <EricDalquist> the sandbox code was all based on prefixing and such
[15:54:22 EDT(-0400)] <jayshao> theoretically if you were IPrivileged you could probably have multiple channels accessing the same servlet session
[15:54:27 EDT(-0400)] <jayshao> which would probably be... bad
[15:54:28 EDT(-0400)] <EricDalquist> yeah
[15:54:40 EDT(-0400)] <EricDalquist> next item is more 'general web app design' related
[15:55:15 EDT(-0400)] <EricDalquist> One of my gripes working in the uPortal code is how the request/response are 'hidden' in many places and the code is actually instanced per user
[15:55:23 EDT(-0400)] <EricDalquist> so very stateful and not thread safe at all
[15:55:44 EDT(-0400)] <EricDalquist> parts of this were carried into the sandbox code
[15:55:53 EDT(-0400)] <EricDalquist> I'd like to try and move away from this as much as possible
[15:56:06 EDT(-0400)] <jayshao> hmmm... in many respect IChannels were intentionally architected that way
[15:56:12 EDT(-0400)] <EricDalquist> yeah
[15:56:20 EDT(-0400)] <EricDalquist> for IChannels themselves I think it makes sense
[15:56:30 EDT(-0400)] <EricDalquist> for the internals of the framework it is a bit of a pain
[15:56:51 EDT(-0400)] <EricDalquist> the way I've done webapps in the past is any interface/service that may need to keep state related to the request or session has the current request (and possibly response) passed in to the method
[15:57:09 EDT(-0400)] <EricDalquist> so I could have something like IPortletWindowManager.setParameters(HttpServletRequst, Map)
[15:57:16 EDT(-0400)] <EricDalquist> that was the manager is stateless
[15:57:28 EDT(-0400)] <jayshao> right – I think most Java developers who have done Servlets tend towards that kind of pattern
[15:57:30 EDT(-0400)] <EricDalquist> but can associate data with the current request/session/etc in whatever way it pleases
[15:58:00 EDT(-0400)] <EricDalquist> and if I need the data later I have a similar method like Map:IPortletWindowManager.getParameters(HttpServletRequest)
[15:58:26 EDT(-0400)] <EricDalquist> I mainly just need some confirmation on if this is a sane and generally accepted as 'good' practice
[15:58:38 EDT(-0400)] <jayshao> seems reasonable to me...
[15:58:48 EDT(-0400)] <EricDalquist> I feel like I'm doing a fair ammount of this work in a little box and I don't want to make decisions that turn out to be horrible and cause problems post 3.0
[15:58:55 EDT(-0400)] <jayshao> I asked Susan to pop in – she probably knows more about ChannelManager
[15:58:59 EDT(-0400)] <EricDalquist> cool
[15:59:36 EDT(-0400)] <EricDalquist> I really want a uportal-dev irc channel that I can convince everyone to idle in so we can have these framework related dev discussions
[15:59:49 EDT(-0400)] <jayshao> heh. baby steps
[16:00:01 EDT(-0400)] <EricDalquist> I hate making this determinations myself and I'm too impatient to wait for email replies if they ever come
[16:00:13 EDT(-0400)] <jayshao> I hear you – with logging it's basically as good as email
[16:00:19 EDT(-0400)] <EricDalquist> so thank you for jumping in
[16:00:36 EDT(-0400)] <jayshao> I'm inclined to follow the state object model
[16:00:58 EDT(-0400)] <jayshao> I think aligning ourselves with the servlet/portlet architecture is a win in the long run
[16:01:04 EDT(-0400)] <EricDalquist> yeah
[16:01:08 EDT(-0400)] <EricDalquist> I agree
[16:01:21 EDT(-0400)] <EricDalquist> and it makes moving things into the Spring managed realm much easier
[16:01:32 EDT(-0400)] <jayshao> I think Brad Johnson is in favor of stateful as he feels it's more object-oriented
[16:01:41 EDT(-0400)] <jayshao> so it may be worth pinging him to get his perspective
[16:01:45 EDT(-0400)] <EricDalquist> trying to manage a lot of per-session objects as if they are singletons is a pain
[16:02:53 EDT(-0400)] <EricDalquist> so my approach with all of this so far is to do new code in the spring/singleton/ioc model and in places where old code needs to access new code it grabs access to the context directly and pulls out the bean
[16:02:56 EDT(-0400)] <pberry> jayshao: Aaron said I could make you do all my conference work
[16:03:02 EDT(-0400)] <EricDalquist> lol
[16:03:09 EDT(-0400)] * SusanBramhall (i=Susan@vpn122.its.yale.edu) has joined ##uportal
[16:03:14 EDT(-0400)] <jayshao> pberry: Aason can say whatever he likes...
[16:03:19 EDT(-0400)] <pberry> ha!
[16:03:20 EDT(-0400)] <EricDalquist> hey there SusanBramhall, thanks for stopping in
[16:03:36 EDT(-0400)] <pberry> uPortal irc is the new facebook
[16:03:48 EDT(-0400)] <EricDalquist> lol
[16:03:52 EDT(-0400)] <SusanBramhall> forgot how to do this - i am so untrendy
[16:04:15 EDT(-0400)] <SusanBramhall> also am in meeting but interested in channel manager question...
[16:04:27 EDT(-0400)] <EricDalquist> well I'm working on URL generation and processing for portlets
[16:04:37 EDT(-0400)] <EricDalquist> this is for the pluto 1.1 integration work
[16:04:39 EDT(-0400)] <pberry> in a meeting with a laptop? for shame...
[16:04:47 EDT(-0400)] <SusanBramhall> right
[16:04:56 EDT(-0400)] <EricDalquist> I'm porting over the url constructor & processor code from the sandbox as the basis
[16:05:07 EDT(-0400)] <jayshao> so treat the BeanFactory as a generic static cover?
[16:05:16 EDT(-0400)] <EricDalquist> and am looking into how channel parameters are currently parsed
[16:05:20 EDT(-0400)] <jayshao> I'm less than thrilled with duplicating bean names between code and XML
[16:05:26 EDT(-0400)] <jayshao> are there that many?
[16:05:37 EDT(-0400)] <jayshao> I dislike Sakai's static cover approach, but it can be valuable
[16:05:45 EDT(-0400)] <EricDalquist> it looks like right now a portal URL can only target parameters at a single channel
[16:05:54 EDT(-0400)] <EricDalquist> well get back to that in a minute jayshao
[16:05:58 EDT(-0400)] <pberry> SusanBramhall: what's the question?
[16:06:01 EDT(-0400)] <EricDalquist> am I correct in that deduction?
[16:06:19 EDT(-0400)] <EricDalquist> pberry: it is my question about how channel parameters are processed right now
[16:06:25 EDT(-0400)] <pberry> ah
[16:06:47 EDT(-0400)] <SusanBramhall> yes - that's the question i was thinking about - or jason pinged me on
[16:07:13 EDT(-0400)] <pberry> http://www.randsinrepose.com/archives/2007/08/31/the_laptop_herring.html
[16:08:16 EDT(-0400)] <EricDalquist> it looks like ChannelManager.processRequestChannelParameters first takes a few tries at figuring out which channel is targeted and if it can figure that out all of the rest of the url parameters are set via runtime data
[16:08:52 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has joined ##uportal
[16:09:25 EDT(-0400)] <EricDalquist> hey ther andrew_petro_ubu, should I summarize or do you want to peak at the logs?
[16:10:03 EDT(-0400)] <SusanBramhall> Jen would be better to add useful insight here i think.
[16:10:09 EDT(-0400)] <EricDalquist>
[16:10:52 EDT(-0400)] <jayshao> it's a regular party in here – who brought the virtual beer?
[16:11:03 EDT(-0400)] * athena7 (n=athena@c-24-2-130-130.hsd1.ct.comcast.net) has joined ##uportal
[16:11:11 EDT(-0400)] <athena7> hello hello
[16:11:16 EDT(-0400)] <EricDalquist> hey there
[16:11:28 EDT(-0400)] <EricDalquist> I'm thinking I need to summarize my questions huh
[16:11:34 EDT(-0400)] <athena7> i always forget about this room
[16:11:37 EDT(-0400)] <athena7> yes, probably
[16:11:39 EDT(-0400)] <andrew_petro_ubu> I've peeked at the logs. They piqued my interest.
[16:11:39 EDT(-0400)] <EricDalquist> ok
[16:11:41 EDT(-0400)] <EricDalquist> so
[16:11:46 EDT(-0400)] <EricDalquist> first question
[16:12:00 EDT(-0400)] <EricDalquist> can uPortal URLs only target parameters at a single channel
[16:12:15 EDT(-0400)] <EricDalquist> from looking at ChannelManager.processRequestChannelParameters this appears to be the case
[16:12:42 EDT(-0400)] <athena7> no idea
[16:12:43 EDT(-0400)] <EricDalquist> and I'm talking parameters for the channel itself ... not layout parameters changing the chrome/rendering of the channel
[16:13:26 EDT(-0400)] <SusanBramhall> i think yes - one channel at a time
[16:14:11 EDT(-0400)] <EricDalquist> cool, as long as no one is thinking this is wrong I'm comfortable going with it
[16:14:23 EDT(-0400)] <EricDalquist> second question was more of a general web app design question
[16:14:53 EDT(-0400)] <EricDalquist> so currently uportal uses a lot of user specific objects to both store state and do work (UserInstance, ChannelManager)
[16:15:52 EDT(-0400)] <EricDalquist> with this model passing state information related to just this request around is kind of ugly since there isn't really a way for it to ever 'go away' after the request is complete
[16:16:21 EDT(-0400)] <EricDalquist> what I've started doing for new code that I'm ending up writing is passing the request object (and if needed the response) into service APIs that may need to save state info
[16:17:14 EDT(-0400)] <EricDalquist> and example of this approach would be something like void:IPortletWindowManager.setParameters(request, windowId, parameterMap) / Map:IPortletWindowManager.getParameters(request, windowId)
[16:18:08 EDT(-0400)] <EricDalquist> this allows the impl of that service to store those parameters in any way it needs to and gives it access to the request and session
[16:18:35 EDT(-0400)] <SusanBramhall> we tried to keep channels from having access to the whole request but i'm not sure that separation really added value - just feels right
[16:19:43 EDT(-0400)] <athena7> why can't the channels access the request now? was it a security consideration?
[16:19:55 EDT(-0400)] <SusanBramhall> that was the idea
[16:20:23 EDT(-0400)] <EricDalquist> yeah
[16:20:28 EDT(-0400)] <EricDalquist> and channels not having access is ok
[16:20:33 EDT(-0400)] <SusanBramhall> keep the channels from medling outside thier proper boundaries by affecting the session or response
[16:20:39 EDT(-0400)] <EricDalquist> the problem is this approach extended into some of the framework code
[16:20:51 EDT(-0400)] <EricDalquist> which just makes it difficult to do things in the framework in places
[16:20:57 EDT(-0400)] <SusanBramhall> ?
[16:21:11 EDT(-0400)] <EricDalquist> I don't have the example handy
[16:21:16 EDT(-0400)] <EricDalquist> oh I know what it is
[16:21:21 EDT(-0400)] <EricDalquist> PortalControlStructures
[16:21:29 EDT(-0400)] <athena7> i'm trying to think of one - i know i've been aggravated before by not being able to get to the request
[16:21:31 EDT(-0400)] <jayshao> pcs is kind of a weird animal anyway
[16:21:36 EDT(-0400)] <EricDalquist> instead of that structure just being used for IPrivChan
[16:21:51 EDT(-0400)] <EricDalquist> it is used as the way to pass the request/response around once you get into the channel manager
[16:21:53 EDT(-0400)] <SusanBramhall> pcs is the way to let a special channel get the request
[16:22:00 EDT(-0400)] <EricDalquist> yup
[16:22:02 EDT(-0400)] <EricDalquist> and that is great
[16:22:20 EDT(-0400)] <EricDalquist> but using it as the way for the ChannelManager to track the current request is problematic for portlet support
[16:22:28 EDT(-0400)] <SusanBramhall> agree
[16:22:29 EDT(-0400)] <EricDalquist> since we need to allow multiple requests for a single user
[16:22:42 EDT(-0400)] <EricDalquist> and PCS is current scoped to 1 instance per user session
[16:23:18 EDT(-0400)] <EricDalquist> so ... I guess what I'm getting at is the possibility of a slow switch to the model of passing the req/res around as direct method arguments on the framework side of things
[16:23:36 EDT(-0400)] <SusanBramhall> ooo multiple requests - meaning more than one at a time?
[16:23:39 EDT(-0400)] <EricDalquist> yup
[16:23:46 EDT(-0400)] <EricDalquist> that actually exists in 2.6
[16:23:57 EDT(-0400)] <SusanBramhall> how does that happen?
[16:23:58 EDT(-0400)] <EricDalquist> through some rather ugly ThreadLocal based hacks with PCS
[16:24:04 EDT(-0400)] <EricDalquist> portlet actions
[16:24:30 EDT(-0400)] <EricDalquist> since they can do redirects it is completely OK to rendering things like images via portlet action URLs
[16:24:58 EDT(-0400)] <SusanBramhall> so what are dangers of passing request and session to portlets - seems pretty grave to allow one to change values for another
[16:25:07 EDT(-0400)] <EricDalquist> they can't
[16:25:16 EDT(-0400)] <EricDalquist> those objects are wrapped with instances specific to each portlet
[16:26:14 EDT(-0400)] <SusanBramhall> so they aren't really "the request" but a version they can use for parameters only
[16:26:22 EDT(-0400)] <EricDalquist> yeah
[16:26:50 EDT(-0400)] <EricDalquist> the real request is wrapped with a version that reads through to the real one but provides local storage for things like attributes
[16:26:53 EDT(-0400)] <SusanBramhall> and you don't want to pass a newly invented "parameters object"
[16:28:35 EDT(-0400)] <EricDalquist> the portlet adapter will always have to be a privledged channel since we need to pass the original request/response to pluto
[16:29:30 EDT(-0400)] <EricDalquist> I'm thinking along the lines of changing some APIs in UserInstance and ChannelManager to pass the req/res directly instead of storing it in an instance level PCS object for use
[16:29:44 EDT(-0400)] <jayshao> can you have multiple instances of the portlet adaptor instantiated simultaneously?
[16:29:59 EDT(-0400)] <EricDalquist> well since IMultithreaded is going away yes
[16:30:13 EDT(-0400)] <SusanBramhall> oh right - since portlet adapter is priveleded that seems the right way to go then
[16:31:15 EDT(-0400)] <EricDalquist> I guess my original question wasn't as much about the uPortal details (though this is really good discussion) but does this pattern of passing the request/response objects around in the methods calls of stateless services seem like a decent way to deal with this?
[16:31:39 EDT(-0400)] <jayshao> how do you want to handle thread safety on the request/reponse?
[16:32:02 EDT(-0400)] <EricDalquist> thread saftey after channel manager delegates rendering to the worker threads?
[16:32:24 EDT(-0400)] <jayshao> was more thinking about multiple portlet adaptors interacting with the same request/response objects
[16:32:37 EDT(-0400)] <EricDalquist> ah
[16:32:58 EDT(-0400)] <EricDalquist> well this was actually done in 2.6
[16:33:12 EDT(-0400)] <EricDalquist> channel manager adds a wrapper to the request for each worker
[16:33:28 EDT(-0400)] <EricDalquist> and in this case to deal with JSP rendering issues this render is unwrappable by tomcat
[16:33:33 EDT(-0400)] <EricDalquist> but that is the approach
[16:33:38 EDT(-0400)] <jayshao> hm
[16:33:52 EDT(-0400)] <jayshao> the wrapper enforces concurrency?
[16:34:06 EDT(-0400)] <EricDalquist> well requests are pretty much read-only right?
[16:34:29 EDT(-0400)] <EricDalquist> the only 'writeable' methods are the session (already had concurrency concerns) and attributes
[16:34:40 EDT(-0400)] <EricDalquist> what the wrapper does is just scope the attributes to each worker
[16:34:51 EDT(-0400)] <jayshao> gotcha
[16:34:55 EDT(-0400)] <EricDalquist> so each wrapper has a Map that it stores attributes in for the duration of the worker's life
[16:35:18 EDT(-0400)] <jayshao> How does pluto handle it?
[16:35:32 EDT(-0400)] <EricDalquist> the only way that could cause a problem that I could see is a combination of rendering groups and channels that pass data via attributes
[16:35:44 EDT(-0400)] <EricDalquist> privledged channels that is
[16:35:59 EDT(-0400)] <EricDalquist> pluto just renders the portlet you tell it to for the req/res
[16:36:15 EDT(-0400)] <EricDalquist> it is up to the portal to ensure that the request is in a functional state
[16:37:23 EDT(-0400)] <jayshao> ah right, the driver is essentially single portlet only, right?
[16:37:40 EDT(-0400)] <EricDalquist> So the process we had in the sandbox was:
[16:37:41 EDT(-0400)] <EricDalquist> -request comes in to uPortal
[16:37:41 EDT(-0400)] <EricDalquist> -processing of parameters (updating layout, parsing portlet parameters, etc)
[16:37:41 EDT(-0400)] <EricDalquist> -rest of framework works with this 'parsed' request
[16:37:41 EDT(-0400)] <EricDalquist> -rendering code wraps the parsed request for each portlet to be rendered
[16:37:47 EDT(-0400)] <EricDalquist> yeah
[16:38:11 EDT(-0400)] <jayshao> gotcha
[16:38:27 EDT(-0400)] <EricDalquist> so in effect the rendering code (ChannelManager) 'clones' the request by wrapping it in a way that scopes the writable portions of it to each channel
[16:38:28 EDT(-0400)] <jayshao> so you would engineer a similar approach into ChannelManager?
[16:38:41 EDT(-0400)] <EricDalquist> well there is a similar approach for 2.6
[16:39:00 EDT(-0400)] <EricDalquist> it just has some ugly code via ThreadLocals in PortalControlStructures
[16:39:24 EDT(-0400)] <EricDalquist> the big change would be changing UserInstance and ChannelManager to not ever depend on PortalControlStructures
[16:39:45 EDT(-0400)] <EricDalquist> and those would be created in the Worker only for IPrivledged channels
[16:40:10 EDT(-0400)] <EricDalquist> oh and making sure everyone is ok with slowly moving to the model where we pass the req/res directly into methods that need access to them
[16:40:22 EDT(-0400)] <EricDalquist> instead of using any sort of tracking/instance variables to access them
[16:40:28 EDT(-0400)] <SusanBramhall> that seems ok - just keep PortalControlStructures for legacy chanels?
[16:41:03 EDT(-0400)] <EricDalquist> yeah, though the portlet adapter will still use them, so I wouldn't call them legacy channels unless we're calling all channels legacy now
[16:41:33 EDT(-0400)] <SusanBramhall> not yet!
[16:41:41 EDT(-0400)] <EricDalquist> just making it clear that PortalControlStructures is a structure specificly for passing request/response data to IPriv channels, not for use within the internals of the framework
[16:41:55 EDT(-0400)] <SusanBramhall> yes
[16:42:13 EDT(-0400)] <EricDalquist> I really enjoy having all of these developers in here!
[16:42:23 EDT(-0400)] <SusanBramhall> strange that it was used in the framework
[16:42:56 EDT(-0400)] <EricDalquist> well I think this work is going to enable us to slowly convert more and more of the framework into static service classes versus user instanced stateful service classes
[16:43:49 EDT(-0400)] <jayshao> probably a convenience thing
[16:43:58 EDT(-0400)] <jayshao> once it's there it's easy to slip into using it in other places
[16:44:01 EDT(-0400)] <EricDalquist> yup
[16:44:29 EDT(-0400)] <EricDalquist> especially since there is such aggressive syncronization on a users session and you can just store data in instance variables
[16:44:52 EDT(-0400)] <jayshao> heh. instance variables
[16:45:00 EDT(-0400)] <EricDalquist> I would love to get to the point where you could have multiple simultaneous requests to render a user's layout
[16:45:02 EDT(-0400)] <jayshao> do we have a development conventions/standards guide
[16:45:11 EDT(-0400)] <jayshao> we should really document this choice somewhere
[16:45:14 EDT(-0400)] <EricDalquist>
[16:45:22 EDT(-0400)] <SusanBramhall> hey this is almost as good as an unconference
[16:45:32 EDT(-0400)] <EricDalquist> yup
[16:45:38 EDT(-0400)] <jayshao> what makes you think we won't be IRC-ing each other at the unconference?
[16:45:41 EDT(-0400)] <jayshao> freaking developers
[16:45:41 EDT(-0400)] <jayshao>
[16:45:55 EDT(-0400)] <SusanBramhall> and your are what?
[16:46:21 EDT(-0400)] <athena7> i'm looking forward to being able to chat with everyone in person though
[16:46:24 EDT(-0400)] <EricDalquist> now if I could only get all of you on here regularly
[16:46:27 EDT(-0400)] <EricDalquist> oh yeah
[16:46:33 EDT(-0400)] <EricDalquist> I think that it will be quite productive
[16:46:39 EDT(-0400)] <athena7> i'll try and come online more - it was so quiet for a while
[16:46:49 EDT(-0400)] <EricDalquist> yeah, that is the hard part
[16:46:57 EDT(-0400)] <EricDalquist> is there will be long periods of nothing
[16:47:03 EDT(-0400)] <jayshao> I try to hangout when I remember on startup
[16:47:04 EDT(-0400)] <SusanBramhall> CSG has an official IRC concurrent with speakers at their meetings - pretty strange to have the public and sub-rosa versions
[16:47:09 EDT(-0400)] <athena7> and i feel weird about being in an IRC room that's logged to the internets
[16:47:32 EDT(-0400)] <jayshao> just remember not to post your cell-phone
[16:47:39 EDT(-0400)] <EricDalquist> yup
[16:47:41 EDT(-0400)] <SusanBramhall> heh
[16:47:50 EDT(-0400)] <EricDalquist> especially since you can't really ever delete things from confluence
[16:47:55 EDT(-0400)] <athena7> oh by the way, i've done most of the work for creating those initial javascript arrays for the fluid work
[16:48:00 EDT(-0400)] <EricDalquist> awesome
[16:48:06 EDT(-0400)] <jayshao> while I peeps are here – are you guys interested in a Wed dinner in NYC with some Sakai people at the Unconference?
[16:48:14 EDT(-0400)] <EricDalquist> I'm going to touch base with the fluid folks this week to see where they are
[16:48:21 EDT(-0400)] <athena7> what i could really use though would be a couple good, complex test scenarios to make sure it's all working correctly
[16:48:22 EDT(-0400)] <EricDalquist> I know they ran into a nasty bug in dojo 0.9
[16:48:27 EDT(-0400)] <athena7> does anyone happen to have any of those?
[16:48:35 EDT(-0400)] <EricDalquist> hrm
[16:48:37 EDT(-0400)] <EricDalquist> I think we do
[16:48:43 EDT(-0400)] <athena7> i might be jason
[16:48:54 EDT(-0400)] <athena7> provided i'm feeling ok, that sounds fun
[16:49:01 EDT(-0400)] <EricDalquist> we make heavy use of DLM restrictions
[16:49:22 EDT(-0400)] <athena7> ah ok
[16:49:47 EDT(-0400)] <athena7> we pretty much just don't use them, so i'm not always 100% confident that i'm interpreting things correctly
[16:50:12 EDT(-0400)] <EricDalquist> I'm hoping that both the uPortal and Fluid sides will be mostly there at the unconference and we can use the face time to do some integration work
[16:52:36 EDT(-0400)] <athena7> that would be fantastic
[16:52:45 EDT(-0400)] <athena7> i'm hoping we can all sit down and talk about some of the interface issues too
[16:52:50 EDT(-0400)] <EricDalquist> yeah
[16:53:04 EDT(-0400)] <athena7> i haven't had the energy to try and convey some of them through email, and open-ended discussions seem to work better in person anyway
[16:53:18 EDT(-0400)] <EricDalquist> yup
[16:53:27 EDT(-0400)] <SusanBramhall> be sure to put your ideas on the wiki
[16:53:31 EDT(-0400)] <EricDalquist> well that is why I like IRC ... less energy than email
[16:53:37 EDT(-0400)] <EricDalquist> and more interactive
[16:53:44 EDT(-0400)] <athena7> yeah
[16:54:38 EDT(-0400)] <athena7> is there going to be much going on friday? i wasn't necessarily planning to stay that day
[16:54:39 EDT(-0400)] <EricDalquist> I probably won't get a summary of this stuff up today but I'll go over the logs tomorrow morning and add more info to the up3/pluto dev pages about the approach
[16:54:58 EDT(-0400)] <EricDalquist> I'll be there for a few hours in the morning but I have a mid-day flight back I believe
[16:55:18 EDT(-0400)] <athena7> ok, i figured a lot of people were probably leaving then
[16:55:23 EDT(-0400)] <EricDalquist> though I will be getting in early afternoon on Sunday if people are going to be around
[16:55:42 EDT(-0400)] <athena7> i should be in before dinner sunday
[16:56:12 EDT(-0400)] <SusanBramhall> i'll be there in board meeting so can't hang with developers.
[16:57:06 EDT(-0400)] <EricDalquist> oh so jayshao we never talked about the static service stuff you were asking about
[16:57:06 EDT(-0400)] <jayshao> I think Faizan is putting together a list of stuff to do – restaurants and whatnot
[16:57:09 EDT(-0400)] <athena7> we'll miss you!
[16:57:23 EDT(-0400)] <jayshao> oh yeah, how to get Spring managed stuff into non-Spring stuff?
[16:57:33 EDT(-0400)] <EricDalquist> in a not very pretty way
[16:57:37 EDT(-0400)] <jayshao> heh
[16:57:47 EDT(-0400)] <jayshao> you hitting this a lot?
[16:58:01 EDT(-0400)] <EricDalquist> I added "PortalApplicationContextListener implements ServletContextListener"
[16:58:23 EDT(-0400)] <EricDalquist> which provides getRequiredWebApplicationContext() and getWebApplicationContext() clones of the methods on Spring's WebApplicationContextUtils
[16:58:33 EDT(-0400)] <EricDalquist> except they don't require the caller to provide a ServletContext
[16:59:12 EDT(-0400)] <EricDalquist> the PortalApplicationContextListener tracks the current ServletContext and uses that to call WebApplicationContextUtils to get you access to the WebApplicationContext object
[16:59:21 EDT(-0400)] <jayshao> gotcha
[16:59:25 EDT(-0400)] <EricDalquist> it plays nice with context restarts and such
[16:59:33 EDT(-0400)] <EricDalquist> which was a problem in 2.5/2.6
[16:59:36 EDT(-0400)] <jayshao> how are you actually getting beans though?
[16:59:41 EDT(-0400)] <jayshao> context.getBean?
[16:59:43 EDT(-0400)] <EricDalquist> .getBean("foo")
[16:59:45 EDT(-0400)] <EricDalquist> yup
[16:59:50 EDT(-0400)] <EricDalquist> no other real choice
[16:59:56 EDT(-0400)] <jayshao> the "foo" scattered all around feels ugly
[17:00:07 EDT(-0400)] <EricDalquist> well I try to localize it
[17:00:09 EDT(-0400)] <jayshao> I almost prefer a static wrapper that at least consolidates that into one place
[17:00:18 EDT(-0400)] <EricDalquist> that is what is being done
[17:00:32 EDT(-0400)] <jayshao> gotcha
[17:00:38 EDT(-0400)] <EricDalquist> if the bean is needed in more than one location using this method a deprecated static wrapper is created
[17:00:47 EDT(-0400)] <jayshao> heh
[17:00:56 EDT(-0400)] <jayshao> shrug notreally much way around it
[17:01:06 EDT(-0400)] <EricDalquist> with explicit comments about why this is horrible evil bad and you should never use it .... unless you have no other choice
[17:01:23 EDT(-0400)] <EricDalquist> as we move more things into the single app context these can be removed
[17:01:44 EDT(-0400)] <EricDalquist> I don't think moving the PortalSessionManager servlet into spring will happen for 3.0 unless someone else does it
[17:01:52 EDT(-0400)] <EricDalquist> but that could be a 3.1 bit of work
[17:02:08 EDT(-0400)] <EricDalquist> and we can just incrementally replace static bits with singleton beans
[17:02:13 EDT(-0400)] <jayshao> Didn't Andrew have a PortalSessionController he had done a while back?
[17:02:19 EDT(-0400)] <EricDalquist> working from the front facing servlets in
[17:02:22 EDT(-0400)] <EricDalquist> don't know
[17:02:28 EDT(-0400)] <EricDalquist> that would be quite handy
[17:02:35 EDT(-0400)] <jayshao> andrew_petro_ubu was that real or a musing?
[17:02:37 EDT(-0400)] <jayshao> still have it?
[17:02:44 EDT(-0400)] <EricDalquist> brb
[17:04:39 EDT(-0400)] <EricDalquist> ok
[17:07:16 EDT(-0400)] <athena7> could we maybe have a section on the wiki for "things i want to talk about but, not hear someone present on"?
[17:07:21 EDT(-0400)] <athena7> i wasn't really sure where to add things
[17:07:34 EDT(-0400)] <EricDalquist> sounds like a great section
[17:07:58 EDT(-0400)] <EricDalquist> 'needed conversations' with a topic and 'requested attendees'?
[17:08:39 EDT(-0400)] <athena7> yes, sounds good
[17:09:11 EDT(-0400)] <athena7> especially since this conference seems intended to follow a looser format, it'd be great to be able to schedule time to just hash things out
[17:09:18 EDT(-0400)] <athena7> particularly since fluid people will be around
[17:09:28 EDT(-0400)] <jayshao> the hope is the afternoon will shape up into that kind of thing
[17:09:29 EDT(-0400)] <EricDalquist> I'll send an email to the conferences email list about this
[17:09:45 EDT(-0400)] <jayshao> certainly if you want to seed some topics we can have some conversation starters for later
[17:10:46 EDT(-0400)] <athena7> ok, sounds great, thanks
[17:10:49 EDT(-0400)] <andrew_petro_ubu> Yes, I had a Spring WebMVC Controller version of the PortalSessionManager servlet
[17:11:20 EDT(-0400)] <andrew_petro_ubu> that code in general was exactly what you'd expect if one just slammed in WebMVC and then tried to translate the couple of servlets we've got to basic controllers
[17:11:35 EDT(-0400)] <EricDalquist> ooh .... do you still have that around somewhere?
[17:12:07 EDT(-0400)] <andrew_petro_ubu> it's probably sitting on the hd I don't have mounted
[17:12:49 EDT(-0400)] <andrew_petro_ubu> someone actually want this code? I can dig it up and share it if it's valuable, but it's nothing more than exactly what you'd expect going down that road
[17:13:08 EDT(-0400)] <EricDalquist> I would love it
[17:13:27 EDT(-0400)] <EricDalquist> in fact it would likely serve as the basis for doing it for uP3
[17:13:46 EDT(-0400)] <EricDalquist> one of the many things on my list and all the time I can save by not figuring it out completely on my own is valuable
[17:14:16 EDT(-0400)] <andrew_petro_ubu> heh. alright. I've got a new Dell chasis to replace the one that died, so I can get on swapping those hds around again...
[17:16:03 EDT(-0400)] <EricDalquist> that would be great if you could get to it ... if not ... it may just wait until some point in the future when I or someone else gets around to doing it
[17:19:35 EDT(-0400)] <athena7> by the way, eric, does the wisconsin proxy portlet support proxy cas?
[17:20:04 EDT(-0400)] <EricDalquist> no
[17:20:12 EDT(-0400)] <EricDalquist> though I don't imagine it would be too hard to add
[17:20:37 EDT(-0400)] <EricDalquist> I would oh so love to revisit that code and clean it up a bit and make additions like that
[17:21:45 EDT(-0400)] <jayshao> Andrew had some musings on how portlets would acquire proxy tickets
[17:22:02 EDT(-0400)] <athena7> i saw that
[17:22:03 EDT(-0400)] <EricDalquist> I think request attributes is likely the way to go
[17:22:11 EDT(-0400)] <EricDalquist> though I really need to learn more about CAS
[17:22:16 EDT(-0400)] <jayshao> it would probably end up being outside the portlet spec really
[17:22:19 EDT(-0400)] <athena7> i was sort of wondering whether any of those ideas had actually been implemented
[17:22:22 EDT(-0400)] <jayshao> does pubcookie allow proxy auth?
[17:22:27 EDT(-0400)] <EricDalquist> nope
[17:22:28 EDT(-0400)] <jayshao> or something like passing kerb credentials?
[17:22:35 EDT(-0400)] <EricDalquist> nope
[17:22:37 EDT(-0400)] <jayshao> ouch
[17:22:39 EDT(-0400)] <EricDalquist> yup
[17:22:42 EDT(-0400)] <jayshao> so how do you do backend integration?
[17:22:44 EDT(-0400)] <EricDalquist> go iframes!
[17:22:51 EDT(-0400)] <EricDalquist> or trust
[17:23:27 EDT(-0400)] <EricDalquist> aka if a portal IP asks for data for 'dalquist' it gets it
[17:23:31 EDT(-0400)] <EricDalquist> which works well enough
[17:23:40 EDT(-0400)] <EricDalquist> since many of the portal services are only available through the portal
[17:24:06 EDT(-0400)] <EricDalquist> the ones that aren't we do little dashboard portlets or iframes that just link you into the other app
[17:24:15 EDT(-0400)] <EricDalquist> so the pubcookie stuff works
[17:25:22 EDT(-0400)] <EricDalquist> ok well I have to run and catch a bus
[17:25:26 EDT(-0400)] <EricDalquist> I'll see everyone tomorrow!
[17:25:32 EDT(-0400)] <jayshao> have a good one
[17:25:38 EDT(-0400)] <athena7> adios!
[17:26:48 EDT(-0400)] <jayshao> I'm going to take off too – have a good day everyone
[17:27:02 EDT(-0400)] <pberry> lazy east coasters...
[17:27:14 EDT(-0400)] <athena7> hmph.
[17:27:16 EDT(-0400)] <pberry> think about us out here on the left coast...
[17:27:24 EDT(-0400)] <athena7> left coast, left behind?
[17:31:14 EDT(-0400)] <pberry> seems like it
[17:31:39 EDT(-0400)] <pberry> oh well, at least we see the end of Monday Night Football before midnight...
[17:31:52 EDT(-0400)] <athena7> true
[17:32:10 EDT(-0400)] <athena7> even the sox games have been going well past midnight here
[17:32:31 EDT(-0400)] <pberry> man, longest games....ever
[17:35:12 EDT(-0400)] <athena7> well, not as long as alcs 2004 anyway!
[17:35:15 EDT(-0400)] <athena7> but yeah, pretty long
[17:55:12 EDT(-0400)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal