[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