uPortal IRC Logs-2012-02-14

Owned by Apereo Infrastructure
Last updated: Feb 14, 2012Version comment

[11:26:25 CST(-0600)] <athena> morning EricDalquist

[11:26:31 CST(-0600)] <EricDalquist> morning athena

[11:26:50 CST(-0600)] <athena> so i found my problem w/ the evaluator, which was of course something stupid

[11:26:56 CST(-0600)] <athena> now on to the next issue (tongue)

[11:27:37 CST(-0600)] <athena> having trouble getting ahold of a spring bean reference to the user instance manager - apparently it's in creation at that time

[11:27:53 CST(-0600)] <EricDalquist> heh

[11:28:02 CST(-0600)] <athena> yeah.

[11:28:21 CST(-0600)] <EricDalquist> yeah ... so have I ever mentioned how stupid it is to have logic and data mixed into the same objects?

[11:28:32 CST(-0600)] <EricDalquist> because then you get stuff like this

[11:28:32 CST(-0600)] <athena> (sad)

[11:28:33 CST(-0600)] <athena> yeah

[11:29:03 CST(-0600)] <EricDalquist> and this is during login?

[11:29:18 CST(-0600)] <EricDalquist> I'm wondering if user instance manager creation triggers the DLM evaluation

[11:29:29 CST(-0600)] <athena> yeah, wondering if that's the case

[11:29:31 CST(-0600)] <EricDalquist> which would mean your DLM evaluation can't use any of the user instance data

[11:29:38 CST(-0600)] <athena> yeah, worried about that

[11:29:41 CST(-0600)] <athena> going to do a bit more digging

[11:29:45 CST(-0600)] <EricDalquist> could you set a break point in your eval

[11:29:50 CST(-0600)] <athena> yeah, i'll do that

[11:29:51 CST(-0600)] <EricDalquist> and gist the stack trace?

[11:29:57 CST(-0600)] <EricDalquist> I have to reboot shortly ...

[11:30:05 CST(-0600)] <athena> one more thing i'm going to try first, too

[11:37:14 CST(-0600)] <athena> yes, looks like it's called during login from the RDBMDistributedLasyoutStore.getCompositeLayout method

[11:39:23 CST(-0600)] <athena> looks like it's actually the call to get the user instance that causes problems - not the spring wiring of the evaluator itself

[11:39:55 CST(-0600)] <EricDalquist> spring wiring the evluator?

[11:40:04 CST(-0600)] <EricDalquist> aren't the evaluators persisted via JPA?

[11:40:09 CST(-0600)] <EricDalquist> how is it getting spring wired?

[11:40:25 CST(-0600)] <athena> eh, temporarily created a spring locator until i thought of something better :/

[11:40:42 CST(-0600)] <EricDalquist> ah

[11:40:50 CST(-0600)] <athena> it is indeed persisted via JPA, but to read the user's current profile it needs access to the user instance manager

[11:40:54 CST(-0600)] <EricDalquist> better would be to move all evaluator logic into singleton beans

[11:40:55 CST(-0600)] <athena> the person object isn't enough

[11:41:05 CST(-0600)] <EricDalquist> and just persist the evaluator skeleton (tongue)

[11:41:08 CST(-0600)] <athena> yeah

[11:41:13 CST(-0600)] <EricDalquist> but that is also a lot of work

[11:41:52 CST(-0600)] <athena> well, also if it doesn't work in the first place it's not worth refactoring (smile)

[11:42:10 CST(-0600)] <EricDalquist> right

[11:42:17 CST(-0600)] <EricDalquist> the huge fix is refactoring DLM

[11:42:20 CST(-0600)] <EricDalquist> and profiles

[11:42:23 CST(-0600)] <EricDalquist> and user instances

[11:42:30 CST(-0600)] <EricDalquist> into a reasonable structure

[11:42:32 CST(-0600)] <athena> yeah

[11:42:36 CST(-0600)] <EricDalquist> that isn't all terribly interdependent

[11:43:05 CST(-0600)] <athena> that's what i'm getting right now: https://gist.github.com/1828508

[11:43:22 CST(-0600)] <athena> looks like the layout manager is calling my code for the evaluator, which is then trying to call the user instance manager

[11:43:41 CST(-0600)] <athena> but the user instance manager calls the layout manager, which isn't done yet, since it called out to my coded

[11:43:47 CST(-0600)] <EricDalquist> yup

[11:43:55 CST(-0600)] <athena> ugh

[11:44:00 CST(-0600)] <EricDalquist> yeah that isn't trivally fixible

[11:44:03 CST(-0600)] <athena> yeah

[11:44:17 CST(-0600)] <athena> does it seem possible to expose the profile name as a person directory attribute?

[12:21:45 CST(-0600)] <drewwills> Morning EricDalquist... I have a question about this code: https://gist.github.com/1828806

[12:22:10 CST(-0600)] <EricDalquist> good morning drewwills, on the UP steering committee call right now, I'll let you know when I'm done (smile)

[12:22:34 CST(-0600)] <drewwills> np. so line #7 – the rootElement of fragment layout files is <layout>... true for uP3, true for uP4

[12:36:46 CST(-0600)] <EricDalquist> drewwills: not sure I follow what you mean by that

[12:37:57 CST(-0600)] <drewwills> that Java file is responsible for organizing files to be imported into queues, which will then be processed in the traditional, dependency-driven order... users before groups etc

[12:38:17 CST(-0600)] <EricDalquist> um ... looks like it

[12:38:19 CST(-0600)] <EricDalquist> what file is it from?

[12:38:41 CST(-0600)] <drewwills> atm noting falls in the fragment-layout bucket, and frag-layouts fall in the layout bucket

[12:38:49 CST(-0600)] <drewwills> it's in the title one sec

[12:38:55 CST(-0600)] <EricDalquist> ah ok

[12:38:57 CST(-0600)] <drewwills> PortalDataKeyFileProcessor 

[12:39:07 CST(-0600)] <EricDalquist> so there is another piece ... let me find it

[12:40:20 CST(-0600)] <EricDalquist> ok drewwills you looking at PortalDataKeyFileProcessor?

[12:40:25 CST(-0600)] <drewwills> i am

[12:41:01 CST(-0600)] <drewwills> so there's this file FragmentLayoutPortalDataType.java... and atm I believe nothing matches it's criteria

[12:41:16 CST(-0600)] <EricDalquist> line 125 does: portlet-overlays/uportal-war/src

[12:41:17 CST(-0600)] <EricDalquist> oops

[12:41:20 CST(-0600)] <EricDalquist> final IPortalDataType portalDataType = this.dataKeyTypes.get(portalDataKey);

[12:41:44 CST(-0600)] <EricDalquist> which for your case should result in a LayoutPortalDataType instance being returned

[12:41:57 CST(-0600)] <EricDalquist> then line 133 does: final Set<PortalDataKey> processedPortalDataKeys = portalDataType.postProcessPortalDataKey(resourceUri, portalDataKey, xmlEventReader);

[12:41:58 CST(-0600)] <drewwills> um, yep

[12:42:31 CST(-0600)] <drewwills> ah ok... i see the hook, but not sure it's working atm

[12:42:45 CST(-0600)] <EricDalquist> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/io/xml/layout/LayoutPortalDataType.java#L131

[12:42:51 CST(-0600)] <EricDalquist> then that should be getting called

[12:43:03 CST(-0600)] <EricDalquist> ah ... you know I bet I see the bug

[12:43:44 CST(-0600)] <EricDalquist> yup, the new files end with .fragment-definition.xml

[12:43:48 CST(-0600)] <EricDalquist> and not just .fragment-definition

[12:44:05 CST(-0600)] <drewwills> yep... that was my next point (smile)

[12:44:15 CST(-0600)] <drewwills> i can sort this out

[12:44:17 CST(-0600)] <EricDalquist> so LayoutPortalDataType:133 needs to change to if (systemId.endsWith(".fragment-layout") || systemId.endsWith(".fragment-layout.xml")) {

[12:44:48 CST(-0600)] <EricDalquist> the eventual goal would be to export fragment layouts such that the XML data itself can differentiate

[12:44:54 CST(-0600)] <EricDalquist> but that is the eventual goal (smile)

[12:45:33 CST(-0600)] <drewwills> yeah that's cool... I'm on board... but in the next couple quarters I will probably help 3-4 schools move uP3 -> uP4

[12:45:41 CST(-0600)] <EricDalquist> great

[13:07:19 CST(-0600)] <drewwills> still there EricDalquist?

[13:07:59 CST(-0600)] <drewwills> i see this a bit lower in the method: if (this.userIdentityStore.isDefaultUser(username)) return convertToDefaultUserKey(portalDataKey);

[13:08:51 CST(-0600)] <drewwills> what if there were something like ... if (this.layoutStore.isFragmentOwner(username)) return convertToFragmentKey(portalDataKey);

[13:09:08 CST(-0600)] <drewwills> does that sound preferable?

[13:09:24 CST(-0600)] <EricDalquist> hi

[13:10:16 CST(-0600)] <EricDalquist> well what did the CRN scripts do in 3.2?

[13:10:39 CST(-0600)] <EricDalquist> I think they just assumed anything that was in a .fragment-layout file was a fragment layout'

[13:10:40 CST(-0600)] <drewwills> they differentiated by the systemId.endsWith(".fragment-layout") route

[13:10:46 CST(-0600)] <drewwills> yes

[13:11:13 CST(-0600)] <EricDalquist> can you import a fragment layout correctly even if the associated user isn't currently configured as a fragment owner?

[13:11:14 CST(-0600)] <drewwills> but we know who the fragment owners are... something like that method is already available

[13:11:35 CST(-0600)] <EricDalquist> I guess what happens if someone does the import before having their dlm config completely right

[13:11:54 CST(-0600)] <drewwills> certainly... importing frag-layouts frst only has to do with matching DLM pathref/noderef business

[13:12:15 CST(-0600)] <EricDalquist> I'd just leave it matching off the filename for now

[13:12:28 CST(-0600)] <drewwills> sure, but fwiw it will still fail, i believe

[13:12:39 CST(-0600)] <EricDalquist> by changing the systemid matching?

[13:12:41 CST(-0600)] <drewwills> hmmm... maybe not

[13:12:54 CST(-0600)] <EricDalquist> if (systemId.endsWith(".fragment-layout") || systemId.endsWith(".fragment-layout.xml"))

[13:13:07 CST(-0600)] <EricDalquist> that should match both 3.2 and 4.0 fragment layout files

[13:13:19 CST(-0600)] <drewwills> oh i mean it will fail to match up pathref/noderef when a fragment layout owner is not properly listed as one

[13:13:33 CST(-0600)] <EricDalquist> oh

[13:13:41 CST(-0600)] <drewwills> yes, toally... the file extension matching will work

[13:14:00 CST(-0600)] <drewwills> that's what i meant, but honestly i'm not sure

[13:14:28 CST(-0600)] <drewwills> one more time... "oh i mean it will fail to match up pathref/noderef when a fragment layout owner is not properly listed as one" is what i meant to say, but honestly i'm not positive of that

[13:14:50 CST(-0600)] <EricDalquist> hrm

[13:15:00 CST(-0600)] <EricDalquist> perhaps a two-fold check then

[13:15:07 CST(-0600)] <EricDalquist> first do "if (systemId.endsWith(".fragment-layout") || systemId.endsWith(".fragment-layout.xml"))"

[13:15:21 CST(-0600)] <EricDalquist> then inside that do "if (this.layoutStore.isFragmentOwner(username))"

[13:15:41 CST(-0600)] <EricDalquist> and if that 2nd check is false log a WARNing describing what is wrong and how to fix it

[13:20:45 CST(-0600)] <athena> so i seem to have uncovered yet more strange behavior

[13:21:05 CST(-0600)] <athena> looks like when you make changes to your desktop profile they're not actually reflected in the mobile version

[13:21:59 CST(-0600)] <EricDalquist> your profile?

[13:22:03 CST(-0600)] <EricDalquist> or your layout

[13:22:10 CST(-0600)] <EricDalquist> and what kind of change?

[13:22:36 CST(-0600)] <athena> er, layout

[13:22:40 CST(-0600)] <athena> specifically adding tabs

[13:22:51 CST(-0600)] <EricDalquist> huh ...

[13:23:02 CST(-0600)] <EricDalquist> try restarting the jvm?

[13:23:06 CST(-0600)] <athena> yep.

[13:23:06 CST(-0600)] <EricDalquist> see if something is getting cached?

[13:23:08 CST(-0600)] <EricDalquist> :/

[13:23:48 CST(-0600)] <athena> i took a look in the database, and the user only has user-specific profile entry

[13:23:54 CST(-0600)] <athena> guessing that's getting created when the layout is updated

[13:24:14 CST(-0600)] <athena> but nothing ever gets created for the mobile profile, so the user is still getting the default mobile profile rather than the one with their specific layout?

[13:24:23 CST(-0600)] * EricDalquist goes and sticks his head in the sand

[13:24:33 CST(-0600)] <athena> lol

[13:24:42 CST(-0600)] <athena> i guess i'm just going to file it as a bug for now

[13:24:45 CST(-0600)] <EricDalquist> yeah

[13:24:50 CST(-0600)] <athena> i don't think it's going to ruin anyone's life at the moment

[13:25:02 CST(-0600)] <athena> and . . . ugh i know neither of us want to touch that code right now

[13:25:05 CST(-0600)] <athena> cries

[13:25:23 CST(-0600)] <EricDalquist> (smile)

[13:25:38 CST(-0600)] <athena> do actually have to deal w/ the layout.json issues when you have time

[13:25:45 CST(-0600)] <athena> but this one . . . yeah, lets just document it for now

[13:25:50 CST(-0600)] <EricDalquist> yeah, that will likely be tomorrow morning

[13:25:55 CST(-0600)] <athena> sounds good

[13:41:55 CST(-0600)] <EricDalquist> just did my first vendor branch update in git

[13:43:33 CST(-0600)] <EricDalquist> and it was wonderfully easy

[13:44:07 CST(-0600)] <EricDalquist> "git merge uportal-4.0.3" to update to the 4.0.3 release and then "git mergetool -y" to go through and manually resolve any conflicts

[13:44:18 CST(-0600)] <EricDalquist> and I have a nice pretty graph in gitk

[13:44:20 CST(-0600)] <athena> nice (smile)

[13:44:24 CST(-0600)] <athena> that's excellent

[13:44:45 CST(-0600)] <EricDalquist> SO much better than vendor branch merging in CVS or SVN

[13:44:55 CST(-0600)] <athena> yeah

[13:45:05 CST(-0600)] <athena> i've actually just been updating our demo branch to match the trunk

[13:45:15 CST(-0600)] <athena> and that's really a lot easier than svn vendor branch merging

[13:45:34 CST(-0600)] <EricDalquist> yeah

[13:45:45 CST(-0600)] <EricDalquist> just "git merge placeToMergeTo"

[13:45:48 CST(-0600)] <EricDalquist> and tada

[13:47:47 CST(-0600)] <athena> (smile)

[13:47:59 CST(-0600)] <athena> basically just calling git merge upstream/master

[13:48:07 CST(-0600)] <athena> many times a day as required

[13:48:15 CST(-0600)] <EricDalquist> lol

[13:48:33 CST(-0600)] <athena> makes it easier to test our in-dev code in a more real-world environment too

[13:48:40 CST(-0600)] <athena> since there's SSL, LDAP, etc.

[13:48:44 CST(-0600)] <EricDalquist> yup

[14:47:37 CST(-0600)] <b-sure> Hello uPortal Devs: I'm working with the 4.0.3 release and am running into an issue when I want to modify a category or group in the portlet manager: http://pastebin.com/ZjsNDtQ1 do you know if this is an issue with this release? It was working in 4.0.2 because I did add some new portlets with that build.

[15:02:49 CST(-0600)] <EricDalquist> hrm, looks like it could be from the spring or spring-security library update

[15:02:56 CST(-0600)] <EricDalquist> any ideas athena?

[15:03:05 CST(-0600)] <EricDalquist> better view: http://pastebin.com/raw.php?i=ZjsNDtQ1

[15:10:32 CST(-0600)] <athena> hmm, that does look related to spring-sec

[15:10:36 CST(-0600)] <athena> i don't know offhand

[15:12:25 CST(-0600)] <athena> i guess might be the library update though, if it cropped up at 4.0.3

[15:12:31 CST(-0600)] <EricDalquist> yeah

[15:12:43 CST(-0600)] <EricDalquist> b-sure: can you file a jira issue for now

[15:12:47 CST(-0600)] <athena> that'd be great

[15:12:50 CST(-0600)] <EricDalquist> and we'll see if we can track it down tomorrow

[15:35:49 CST(-0600)] <b-sure> hello EricDalquist and athena. I'll file a jira for this. thanks for looking.

[15:45:37 CST(-0600)] <b-sure> Hello again. also in the 4.0.3 build, I found this error and solution http://stackoverflow.com/questions/5891032/in-a-spring-bean-is-it-possible-to-have-a-shutdown-method-which-can-use-transact for the org.jasig.portal.portlet.dao.jpa.ThreadContextClassLoaderAspect. I'm not sure if that is happening for others but it fixed the issue for me.

[15:46:24 CST(-0600)] <b-sure> I'm sure there is probably a better way maybe to address it but I also had to add a property to the spring configuration for that bean.

[15:46:46 CST(-0600)] <EricDalquist> is this to address an existing bug?

[15:46:51 CST(-0600)] <EricDalquist> or a bit of custom code?

[15:47:29 CST(-0600)] <b-sure> it was what I had to do to get the 4.0.3 build turned on . it was the only customization I needed to make

[15:47:51 CST(-0600)] <EricDalquist> I'm not sure I follow

[15:47:51 CST(-0600)] <b-sure> I was getting the error from that post

[15:48:02 CST(-0600)] <b-sure> and the portal would not start

[15:48:32 CST(-0600)] <EricDalquist> you were getting an error about beans being in destruction while starting the portal?

[15:49:01 CST(-0600)] <b-sure> yes. for the ThreadContextClassLoaderAspect class

[15:49:04 CST(-0600)] <b-sure> that was the only one

[15:49:13 CST(-0600)] <EricDalquist> that is very strange

[15:49:23 CST(-0600)] <EricDalquist> there shouldn't be anytghing shutting down during startup

[15:49:30 CST(-0600)] <b-sure> so I add to that file an implementation of SmartLifeCycle and the error went away and the portal started

[15:50:35 CST(-0600)] <b-sure> not sure if that is something I should try to submit a pull for if others aren't getting it.

[15:50:51 CST(-0600)] <EricDalquist> I'm just really confused as to how you could get that error at all during portal startup (tongue)

[15:51:12 CST(-0600)] <EricDalquist> could you remove your fix and start with a clean portal log file

[15:51:13 CST(-0600)] <b-sure> yeah I don't know but it was happening and I still have it in my logs

[15:51:14 CST(-0600)] <EricDalquist> then post your log file

[15:51:49 CST(-0600)] <b-sure> sure. I don't have time to get that to you today but if you are online tomorrow I'll post it. or to the mailing list.

[15:51:55 CST(-0600)] <EricDalquist> that's fine

[15:51:59 CST(-0600)] <EricDalquist> I'll be on all week

[15:52:12 CST(-0600)] <b-sure> oh ok thanks. I'll try to do it first thing

[15:53:12 CST(-0600)] <b-sure> I only have the log mode set to INFO because DEBUG is always way to much info

[15:53:19 CST(-0600)] <EricDalquist> yeah

[15:53:21 CST(-0600)] <EricDalquist> info is fine

[15:53:25 CST(-0600)] <b-sure> does it need to be debug. oh ok

[16:18:47 CST(-0600)] <Sam4242> Hi. I'm trying to wire up a RestEasy service into a portlet

[16:18:56 CST(-0600)] <Sam4242> I think.