[09:22:33 CDT(-0500)] <EricDalquist> good moring'
[09:23:02 CDT(-0500)] <Arvids> good evening 
[09:23:18 CDT(-0500)] <EricDalquist> that too
[09:23:42 CDT(-0500)] <Arvids> I just realized that import/export manual of uP40 is outdated 
[09:23:53 CDT(-0500)] <Arvids> filing an issue now
[09:23:57 CDT(-0500)] <EricDalquist> yeah
[09:24:01 CDT(-0500)] <EricDalquist> I have that page open
[09:24:06 CDT(-0500)] <EricDalquist> and a todo to finish clearning it up
[09:24:11 CDT(-0500)] <EricDalquist> thanks for the jira issue though
[09:27:04 CDT(-0500)] <Arvids> https://issues.jasig.org/browse/UPD-74
[09:27:38 CDT(-0500)] <EricDalquist> on an unrelated rant ... I really wish hsqldb 2.2 had row level locking :/
[09:28:01 CDT(-0500)] <EricDalquist> without it I have to disable a few unit tests unless they are running against a 'real' db
[09:28:45 CDT(-0500)] <Arvids> concurrency issues?
[09:28:56 CDT(-0500)] <EricDalquist> working on the stats aggregation stuff
[09:29:07 CDT(-0500)] <EricDalquist> and as a pre-req I need a portable way to aquire a lock within a cluster
[09:29:11 CDT(-0500)] <Arvids> yeah, I saw previous commits
[09:29:31 CDT(-0500)] <EricDalquist> what I'm doing is using the JPA2 lock abilities
[09:30:10 CDT(-0500)] <EricDalquist> which on any DB other than hsqldb works great, it does a "select for update"
[09:30:22 CDT(-0500)] <EricDalquist> and holds the tx open until the work is complete
[09:30:48 CDT(-0500)] <EricDalquist> that should result in any other tx trying to do a select for update on that row to block
[09:30:53 CDT(-0500)] <EricDalquist> except on hsql
[09:30:56 CDT(-0500)] <EricDalquist> where it just doesn't 
[09:31:29 CDT(-0500)] <Arvids> I believe you can't wish for everything from bundled database
[09:31:42 CDT(-0500)] <EricDalquist>
[09:31:45 CDT(-0500)] <EricDalquist> I know
[09:31:57 CDT(-0500)] <EricDalquist> really I'm just happy that they finally added true tx isolation in 2.2
[09:32:11 CDT(-0500)] <Arvids> btw, why derby is not used so extensively?
[09:32:32 CDT(-0500)] <Arvids> mostly I hear about hsql, but few years ago derby was very promising, too
[09:32:40 CDT(-0500)] <EricDalquist> don't know, I've never really looked into it
[09:34:03 CDT(-0500)] <EricDalquist> though looking at the DerbyDialect it appears to support row level locking
[09:38:25 CDT(-0500)] <Arvids> http://www.h2database.com/html/features.html#comparison says that hsqldb supports row level locking :S
[09:38:36 CDT(-0500)] <Arvids> *9 When using MVCC (multi version concurrency).
[09:40:00 CDT(-0500)] <EricDalquist> yeah
[09:40:21 CDT(-0500)] <EricDalquist> but from looking in the forums their "row level locking" isn't actual blocking
[09:41:11 CDT(-0500)] <Arvids> sad
[09:41:14 CDT(-0500)] <EricDalquist> hrm
[09:41:25 CDT(-0500)] <EricDalquist> though I'll give enabling MVCC a try
[09:44:17 CDT(-0500)] <EricDalquist> yup just enabled MVCC and still no blocking
[09:50:12 CDT(-0500)] <Arvids> btw, can I deselect some of the commits while creating pull request?
[09:50:28 CDT(-0500)] <Arvids> I select "Pull Request" and it shows all my commits
[09:50:47 CDT(-0500)] <Arvids> ... including "Merge remote-tracking branch 'upstream/master'"
[09:52:33 CDT(-0500)] <Arvids> Found out how to create a pull request with only one commit
[09:53:41 CDT(-0500)] <EricDalquist> once you click "Pull Request" there is the link in the upper right to select specific commits
[09:53:59 CDT(-0500)] <EricDalquist> though in theory your feature branch should only contain commits for that feature
[10:39:13 CDT(-0500)] <b-rock> Greetings uPortal devs: do you know if a servlet running in the portal has visibility to the portlet session? or how to accesss the portlet session from a servlet?
[10:40:11 CDT(-0500)] <EricDalquist> your question is a little inconsistent
[10:40:20 CDT(-0500)] <EricDalquist> are you asking about a servlet in a portlet application
[10:40:25 CDT(-0500)] <EricDalquist> or a servlet in uPortal itself
[10:40:41 CDT(-0500)] <b-rock> well the gateway sso portlet interacts with a servlet thats added to uPortal
[10:41:13 CDT(-0500)] <EricDalquist> I'm not familiar with gatewaysso, does it live in a webapp external to the uPortal webapp?
[10:41:16 CDT(-0500)] <b-rock> and in the portlet some data about the user is set.
[10:41:29 CDT(-0500)] <b-rock> no it is within the uPortal context
[10:41:53 CDT(-0500)] <b-rock> there are links in the portlet interface that call the servlet directly.
[10:42:13 CDT(-0500)] <b-rock> the servlet is trying to pull data about the user from the servlet session.
[10:42:46 CDT(-0500)] <b-rock> somehow this is working in the 3.2 build but doesnt' work so far in the new build
[10:43:39 CDT(-0500)] <b-rock> I do see this arrtName: 'org.jasig.portal.security.IPerson' in the servlet session. maybe thats a handle for the person object
[10:43:41 CDT(-0500)] <EricDalquist> ok, so the gatewaysso portlet is some code portlet + servlet code that is added to the uPortal web application
[10:43:47 CDT(-0500)] <EricDalquist> there is no additional webapp in tomcat for it
[10:43:54 CDT(-0500)] <b-rock> yes.
[10:44:05 CDT(-0500)] <athena> there is an additional webapp
[10:44:10 CDT(-0500)] <EricDalquist> so then it sees the portal session
[10:44:19 CDT(-0500)] <EricDalquist> portlets and servlets in one webapp share a single session object
[10:44:25 CDT(-0500)] <athena> there are a few jars that are added to uportal, plus adding a servlet
[10:44:30 CDT(-0500)] <EricDalquist> portlets have two scopes for accessing the session
[10:44:30 CDT(-0500)] <athena> and then there's a separate webapp
[10:44:34 CDT(-0500)] <athena> the whole thing is pretty complex
[10:44:42 CDT(-0500)] <EricDalquist> application scope accesses the session just like a normal servlet
[10:44:46 CDT(-0500)] <athena> and should be rewritten as a JSR-286 portlet
[10:44:53 CDT(-0500)] <EricDalquist> portlet scope namespaces session attributes to that portlet's window id
[10:45:13 CDT(-0500)] <EricDalquist> there is NO WAY to access one webapp's session from another webapp though
[10:45:54 CDT(-0500)] <athena> it doesn't really - it has a servlet that spits javascript out of the uportal webapp, i believe
[10:46:10 CDT(-0500)] <athena> i can't remember exactly what the workflow is
[10:46:36 CDT(-0500)] <b-rock> yeah. I'm guessing at the workflow myself but I see that the servlet is called everytime the portlet is rendered.
[10:46:54 CDT(-0500)] <athena> yeah, i believe it's called via ajax
[10:47:10 CDT(-0500)] <b-rock> there appear to be some porltet related data in the servlet session arrtName: 'org.jasig.portal.user.UserInstanceManagerImpl.USER_INSTANCE' .
[10:47:26 CDT(-0500)] <EricDalquist> portal related data you mean?
[10:47:39 CDT(-0500)] <b-rock> yes portal not portlet.
[10:47:59 CDT(-0500)] <b-rock> although there is this. 'org.jasig.portal.portlet.session.PortletSessionExpirationManager.PORTLET_SESSIONS'
[10:48:09 CDT(-0500)] <EricDalquist> since the servlet is part of the uPortal webapp it would have access to the entire uPortal session
[10:48:18 CDT(-0500)] <EricDalquist> uPortal stores a lot of data in the session
[10:48:28 CDT(-0500)] <EricDalquist> but ALL of it is stored and accessed through utilities
[10:48:54 CDT(-0500)] <EricDalquist> bad things will happen if you start poking around with existing portal session attributes (reading from or writing to) without going through the appropriate accessor API
[10:49:21 CDT(-0500)] <EricDalquist> like to get the IUserInstance you should inject IUserInstanceManager into your code
[10:49:29 CDT(-0500)] <EricDalquist> and use: "IUserInstance getUserInstance(HttpServletRequest request)"
[10:49:33 CDT(-0500)] <b-rock> yes. I have done that in the servlet .
[10:49:36 CDT(-0500)] <b-rock> and get the user.
[10:50:15 CDT(-0500)] <b-rock> or rather updated the servlet to use the updated api for the IUserInstance
[10:50:42 CDT(-0500)] <EricDalquist> sounds good
[10:52:17 CDT(-0500)] <b-rock> so in the servlet, the code is trying to get a session attribute that is set as a portlet session attribute in the portlet. I'm not sure how this is working yet.
[10:52:59 CDT(-0500)] <EricDalquist> and the portlet is part of the uPortal webapp?
[10:53:29 CDT(-0500)] <b-rock> no the portlet is its own webapp toro-gateway-portlet.war with its own set of portlets.
[10:54:05 CDT(-0500)] <EricDalquist> then there is no way
[10:54:20 CDT(-0500)] <EricDalquist> one webapp can't see session attributes from another webapp
[10:54:31 CDT(-0500)] <EricDalquist> without seriously unmaintainable trickery
[10:55:41 CDT(-0500)] <b-rock> yeah this is really some interesting code I've got here.
[10:56:39 CDT(-0500)] <EricDalquist> I bet :/
[11:02:55 CDT(-0500)] <athena> http://code.google.com/p/toro-portal/source/browse/trunk/libraries/sso-callback-servlet/src/main/java/net/unicon/academus/apps/sso/SsoCallbackServlet.java
[11:03:33 CDT(-0500)] <athena> it's passing in a key, at which point the servlet either pulls somethign from cache or builds a new one
[11:04:08 CDT(-0500)] <athena> so caching some stuff in the portal's session, but just to save redoing it, and not using the portlet session
[11:04:40 CDT(-0500)] <b-rock> yeah so the evaluator object is the GatewayUserContext object being set in the portlet from what I can tell.
[11:07:55 CDT(-0500)] <athena> don't think it's passing through the session though
[11:10:25 CDT(-0500)] <b-rock> I'm not sure. I see with some added debug that my cache object is empty when the servlet gets called.
[11:13:50 CDT(-0500)] <b-rock> I see.
[11:14:22 CDT(-0500)] <athena> this was all written before we even had spring, so the codebase is pretty old
[11:14:26 CDT(-0500)] <b-rock> the version we're using is already heavily customized with encryption for the password
[11:14:44 CDT(-0500)] <athena> well, not heavily customized
[11:14:53 CDT(-0500)] <athena> i wrote that modification, i believe
[11:15:03 CDT(-0500)] <b-rock> yes you did.
[11:15:26 CDT(-0500)] <athena> so stuff like that encryption code is more modern and could be pulled into a new project
[11:15:35 CDT(-0500)] <athena> a new project that did the things you need to do would be a lot smaller
[11:16:32 CDT(-0500)] <b-rock> yeah. I'm not sure if it would be easier to just try to write this from scratch or port the existing code to its own project and refactor it as a jsr 268 porlet.
[11:17:10 CDT(-0500)] <athena> it'd be easiest to rewrite from scratch, though pulling in select bits or using them for a model
[11:17:24 CDT(-0500)] <athena> an initial project also maybe wouldn't have to do absolutely everythign the current version does
[11:17:28 CDT(-0500)] <athena> could build it back up slowly
[11:17:36 CDT(-0500)] <b-rock> yeah. I agree.
[11:17:45 CDT(-0500)] <athena> i imagine you're only using a subset of hte functionality
[11:18:31 CDT(-0500)] <b-rock> we really just need the links that sso into the external applications. although that seems like probably the biggest chunk?
[11:19:32 CDT(-0500)] <athena> well, the portlet actually has support for some complex stuff like logging into applications that require a number of sequential steps to authenticate
[11:20:01 CDT(-0500)] <athena> if your SSO targets are just simple links you could skip some of that
[11:20:51 CDT(-0500)] <b-rock> yeah. i think all of the targets just have the basic form based auth that take a user name and passsword which is the same as you use to log into the portal
[11:25:23 CDT(-0500)] <athena> yeah, my recommendation would be to create a new portlet, taking what's still relevant from toro, and build up first the limited use case that you actually need
[11:25:38 CDT(-0500)] <athena> which means you could leave out some of the authentication options
[11:25:47 CDT(-0500)] <athena> as well as leave out the database-persisted credentials bit
[11:25:55 CDT(-0500)] <athena> i assume you're only doing password replay
[11:26:15 CDT(-0500)] <athena> the whole thing could be just a single small webapp that uses JSR-286
[11:26:23 CDT(-0500)] <athena> and we could probably get it included in uportal itself
[11:26:28 CDT(-0500)] <athena> make life a lot easier
[11:26:30 CDT(-0500)] <b-rock> I think your right. I'll need to take this back to my PM and see if we can make time to do this. yes we just do the password replay and our creds are encrypted as a user attribute.
[11:26:43 CDT(-0500)] <athena> sounds good
[11:28:20 CDT(-0500)] <athena> you going to be at the unconference b-rock?
[11:31:48 CDT(-0500)] <b-rock> athena: i"m not sure. i know its coming up and hasn't been dissussed by or mgmt team.
[11:32:00 CDT(-0500)] <b-rock> would be nice to go again.
[11:32:08 CDT(-0500)] <athena> always good to see you
[11:32:14 CDT(-0500)] <b-rock> you too.