[09:02:44 CDT(-0500)] <Arvids> EricDalquist: I updated published schemas at https://source.jasig.org/schemas/uportal/ (UP-3192)

[09:03:21 CDT(-0500)] <Arvids> That cleared like 150 error messages in Eclipse

[09:04:08 CDT(-0500)] <EricDalquist> ah thanks, we usually only push changes there on a release but that shouldn't be a problem for now

[09:04:56 CDT(-0500)] <EricDalquist> I need to finish updating the "cutting a uP release docs" but one step will be doing a merge from https://source.jasig.org/uPortal/trunk/uportal-war/src/main/resources/xsd/ to https://source.jasig.org/schemas/uportal/

[09:04:58 CDT(-0500)] <Arvids> yeah, I thought whether should i do it or not, but figured out - since it's a bug fix, it won't hurt to publish the changes ASAP

[09:05:05 CDT(-0500)] <EricDalquist> yeah

[09:05:11 CDT(-0500)] <EricDalquist> did you do it as a merge or a copy?

[09:06:01 CDT(-0500)] <Arvids> applied diff in my workspace and commited changes

[09:06:07 CDT(-0500)] <EricDalquist> ok, sounds good

[09:06:36 CDT(-0500)] <EricDalquist> also saw the commit for the new portlet

[09:06:37 CDT(-0500)] <Arvids> and there are some more nasty XML error messages in Eclipse

[09:06:47 CDT(-0500)] <EricDalquist> I'll take a look later today or tomorrow

[09:06:51 CDT(-0500)] <EricDalquist> on which files?

[09:07:23 CDT(-0500)] <Arvids> one is flowsContext.xml

[09:08:11 CDT(-0500)] <Arvids> not sure why, but using spring-webflow-config-2.0.xsd reports errors, while spring-webflow-config-2.3.xsd does not

[09:08:42 CDT(-0500)] <Arvids> one more problematic file is cacheContext.xml

[09:08:42 CDT(-0500)] <EricDalquist> weird

[09:08:53 CDT(-0500)] <EricDalquist> well we're using webflow 2.3 so using the more recent XSD would be good

[09:09:05 CDT(-0500)] <Arvids> http://ehcache-spring-annotations.googlecode.com/svn/schema/ehcache-spring/ehcache-spring-1.2.xsd

[09:09:10 CDT(-0500)] <Arvids> this one is not available anymore

[09:09:23 CDT(-0500)] <Arvids> hence Eclipse complains at validation

[09:09:35 CDT(-0500)] <EricDalquist> oh that's my fault

[09:09:39 CDT(-0500)] <Arvids> found the same file at http://ehcache-spring-annotations.googlecode.com/svn/trunk/core/src/main/resources/com/googlecode/ehcache/annotations/ehcache-spring-1.2.xsd

[09:09:40 CDT(-0500)] <EricDalquist> I'll go publish the XSD later today

[09:09:45 CDT(-0500)] <Arvids> ahh.. ok

[09:09:47 CDT(-0500)] <EricDalquist> now that the 1.2 release is out

[09:09:58 CDT(-0500)] <EricDalquist> I work on that project with a co-worker

[09:11:24 CDT(-0500)] <EricDalquist> ok, I have to run for about 90 minutes

[09:11:58 CDT(-0500)] <Arvids> ok, one last fix: http://pastebin.com/z6dLwsHi

[09:12:39 CDT(-0500)] <EricDalquist> oh good catch

[09:13:13 CDT(-0500)] <Arvids> ok, heading home now

[09:13:42 CDT(-0500)] <EricDalquist> have a good evening

[09:13:46 CDT(-0500)] <EricDalquist> thanks for the help

[12:22:40 CDT(-0500)] <drewwills> my IMAP email is behaving poorly... did anyone see that Email Preview message I sent a short time ago?

[12:24:32 CDT(-0500)] <EricDalquist> yes

[12:24:42 CDT(-0500)] <b-rock_> Hi EricDalquist. I just submitted a patch https://issues.jasig.org/browse/UP-3214 that addresses circular dependencies that can sometimes be found in grouper. After reading your post the the dev list a few min ago, I put this as affecting 4.0.1 but it probably can apply to the 3.2.5 patches.

[12:25:08 CDT(-0500)] <EricDalquist> thanks good to know

[12:25:14 CDT(-0500)] <b-rock_> np

[12:42:21 CDT(-0500)] <b-rock_> Hi EricDalquist. I've got another question regarding exporting our 3.2.5-patches prod data. The fragment owners layouts were exported to the "layouts" folder and not the "fragment_layout" folder. I imported them into the 4.0.1 build, but I see that the fragment manager portlet does not list any of the fragments and the tabs don't show after logging in. Are these related?

[12:42:32 CDT(-0500)] <b-rock_> apologies for the long windedness

[12:42:55 CDT(-0500)] <EricDalquist> are all of these fragment owners correctly defined in dlm.xml in both the 3.2 code you used for exporting and the 4.0.1 instance?

[12:43:13 CDT(-0500)] <EricDalquist> the portal determines if a user is a fragment owner based on that file

[12:43:19 CDT(-0500)] <b-rock_> I think I only have them listed a the owner of the fragment but nowhere else

[12:43:30 CDT(-0500)] <EricDalquist> what do you mean?

[12:44:30 CDT(-0500)] <b-rock_> in dlm.xml I have them listed as ownerID="uocWelcome-lo" for example.

[12:44:47 CDT(-0500)] <b-rock_> am I missing another spot where they need to be listed?

[12:44:56 CDT(-0500)] <EricDalquist> that should be enough I believe

[12:45:34 CDT(-0500)] <b-rock_> yeah the fragment owners that made it into the fragment_layout folder don't have any fragments listed in the dlm.xml

[12:45:58 CDT(-0500)] <EricDalquist> are you using the dlm.xml file or are you using the DB backed fragment configuration code?

[12:46:08 CDT(-0500)] <EricDalquist> I'm not as familiar with that

[12:46:09 CDT(-0500)] <b-rock_> not sure. where can I check.

[12:46:18 CDT(-0500)] <EricDalquist> honestly I can't remember

[12:46:21 CDT(-0500)] <EricDalquist> drewwills: can you help here?

[12:46:44 CDT(-0500)] <drewwills> yeah the setting for using db-back fragments was oved... possibly to portal.properties

[12:46:48 CDT(-0500)] <b-rock_> I know we do have the dlm.xml file deployed with uPortal

[12:47:13 CDT(-0500)] <drewwills> it seems all properties were moved out of dlm.xml

[12:48:00 CDT(-0500)] <b-rock_> I didn't override this in 4.0.1 and it is set to org.jasig.portal.layout.dlm.defaultLayoutOwner=fragmentTemplate in the portal.properties

[12:48:10 CDT(-0500)] <EricDalquist> I think it is actually in the spring config in 4.0

[12:48:14 CDT(-0500)] <EricDalquist> let me look

[12:48:36 CDT(-0500)] <EricDalquist> yes in 4.0 layoutContext.xml defines the dlmConfigurationLoader bean

[12:49:08 CDT(-0500)] <EricDalquist> same thing in 3.2: https://source.jasig.org/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/resources/properties/contexts/layoutContext.xml

[12:49:22 CDT(-0500)] <EricDalquist> so check your layoutContext.xml file in your 3.2 deployment

[12:49:48 CDT(-0500)] <drewwills> did you get .fragment-definition files on export?

[12:50:13 CDT(-0500)] <b-rock_> checking...

[12:51:13 CDT(-0500)] <b-rock_> I do see the structure/DLM_Tabs_and_columns.structure file but I didn't import that into the 4.0.1 build

[12:52:09 CDT(-0500)] <b-rock_> there is also the theme/DLM_XHTML.theme

[12:52:16 CDT(-0500)] <EricDalquist> that isn't what he's looking for, the first question is did your 3.2 export work correctly an export .fragment-definition files

[12:52:55 CDT(-0500)] <EricDalquist> if not something is up there and the uPortal code used to do the export doesn't know how to correctly identify which users are fragment owners

[12:52:56 CDT(-0500)] <b-rock_> I don't see any files with that extension.

[12:53:13 CDT(-0500)] <drewwills> the presence of those files would be a strong indicator that you're using the DB-backed DLM

[12:53:39 CDT(-0500)] <b-rock_> yeah. I didn't know we could use the db-backend for that so we probably arent.

[12:53:44 CDT(-0500)] <EricDalquist> so your 3.2 export, you're using the EXACT same code and config that runs the uPortal environment you're exporting from?

[12:53:58 CDT(-0500)] <drewwills> so to recap: you have some fragments listed in dlm.xml, but no corresponding fragment-layout files? or was it vice versa?

[12:53:58 CDT(-0500)] <b-rock_> yes.

[12:54:54 CDT(-0500)] <b-rock_> yes thats it. we have files in "fragment_layout" for users who are not in the dlm.xml file and files in "layout" for users who are listed in dlm.xml

[12:55:55 CDT(-0500)] <EricDalquist> are the files in fragment_layout in your export suffixed with .fragment-layout?

[12:56:54 CDT(-0500)] <b-rock_> sorry, yes they are but they are the users who are not in the dlm.xml file

[12:57:40 CDT(-0500)] <EricDalquist> are they just random users? Are they uPortal default users?

[12:57:50 CDT(-0500)] <b-rock_> they are the portal default users

[12:58:10 CDT(-0500)] <drewwills> that's surprising... is it a perfect switch? meaning, are all the users in layout/ ones that appear in dlm.xml, and are all other users in fragment_layout/?

[12:58:13 CDT(-0500)] <b-rock_> so they probably got in there from in earlier install but aren't uset

[12:58:39 CDT(-0500)] <EricDalquist> right but they should only be exported as fragment_layouts if they are listed in dlm.xml

[12:58:54 CDT(-0500)] <b-rock_> I think just the guest-lo owner for the Guests fragment is in the fragment_layouts folder

[12:58:56 CDT(-0500)] <EricDalquist> are you sure the uPortal code you're using to do the export has a correctly configured dlm.xml?

[12:59:40 CDT(-0500)] <EricDalquist> so there is only one fragment_layout file and it is guest-lo.fragment-layout?

[12:59:42 CDT(-0500)] <b-rock_> I assume it works sime we are able to get to the fragments on the front end and see the username

[13:00:16 CDT(-0500)] <b-rock_> there are also fragment_layout files for admin-lo, welcome-lo, developer-lo

[13:00:43 CDT(-0500)] <EricDalquist> ok

[13:00:51 CDT(-0500)] <EricDalquist> so the only possible way for those to appear in an export

[13:01:15 CDT(-0500)] <b-rock_> looks like the default users that ship with uportal

[13:01:21 CDT(-0500)] <EricDalquist> is for those users to be listed in the dlm.xml file in the uPortal instance wher you run "ant crn-export"

[13:01:50 CDT(-0500)] <b-rock_> gonna look there now...

[13:03:34 CDT(-0500)] <b-rock_> thats it.

[13:03:53 CDT(-0500)] <b-rock_> so I need to re-run the export with the "real" dlm.xml

[13:04:00 CDT(-0500)] <EricDalquist> yes

[13:04:14 CDT(-0500)] <b-rock_> apologies for the confusion.

[13:04:21 CDT(-0500)] <EricDalquist> you have to run the export with the EXACT same configuration you're using for the uPortal instance that you are running

[13:04:23 CDT(-0500)] <EricDalquist> so not just dlm

[13:04:30 CDT(-0500)] <EricDalquist> but group store, pags, user attributes

[13:04:43 CDT(-0500)] <EricDalquist> export touches pretty much everything in the portal

[13:05:01 CDT(-0500)] <EricDalquist> and if it can't correctly resolve information about users, layouts, portlets, etc you will get bad output

[13:05:59 CDT(-0500)] <b-rock_> ahh. thanks for the tip. I'm thinknig now that I just overworte the db connections for the 3.2.5 patches branch with the default configs. I'll make the mods and re-run the export.

[13:25:06 CDT(-0500)] <Arvids> Any comments about Translator portlet implementation?

[13:26:14 CDT(-0500)] <EricDalquist> haven't had any time to look at it yet

[13:26:19 CDT(-0500)] <EricDalquist> probably won't for a few days

[13:30:12 CDT(-0500)] <Arvids> ok, I'd be glad if someone from UI folks would review javascript code there

[13:30:54 CDT(-0500)] <Arvids> Fluid requires a lot of learning

[13:31:42 CDT(-0500)] <athena> it does

[13:31:54 CDT(-0500)] <athena> though luckily the fluid folks are also really friendly and helpful

[13:32:03 CDT(-0500)] <athena> they're over in #fluid-work, incidentally

[13:32:07 CDT(-0500)] <colinclark> We try our best

[13:33:55 CDT(-0500)] <Arvids> I believe that could help me next time

[13:35:07 CDT(-0500)] <colinclark> We're always happy to help if we can, Arvids

[13:35:22 CDT(-0500)] <colinclark> You can ping a few of us in here or lots of others in #fluid-work as athena mentioned.

[13:35:42 CDT(-0500)] <Arvids> athena, I assume you were the author or maven translator plugin, weren't you?

[13:35:46 CDT(-0500)] <athena> yes

[13:36:07 CDT(-0500)] <athena> needs some updating - a few of the last changes i made were eaten in a hard drive tragedy

[13:36:20 CDT(-0500)] <athena> also google seems inclined to stop offering that service

[13:36:43 CDT(-0500)] <EricDalquist> they still have a for-pay service

[13:36:45 CDT(-0500)] <athena> but my rework also included something that would report missing strings, which is useful regardless of whether we do auto-translation or not

[13:36:46 CDT(-0500)] <athena> yeah

[13:36:47 CDT(-0500)] <Arvids> yes, i encountered that yesterday

[13:36:52 CDT(-0500)] <EricDalquist> and I think jasig could pay for it

[13:36:57 CDT(-0500)] <EricDalquist> its REALLY cheap for our needs

[13:36:57 CDT(-0500)] <athena> seems reasonable to me

[13:37:01 CDT(-0500)] <EricDalquist> like a few dollars a year

[13:37:33 CDT(-0500)] <Arvids> yeah, when i ran it yesterday, it complained something like "too much requests received from your host"

[13:37:40 CDT(-0500)] <athena> yeah

[13:37:48 CDT(-0500)] <athena> it'll do that if you're running a whole lot of stuff

[13:37:50 CDT(-0500)] <Arvids> but it's very helpful for all those translations

[13:37:51 CDT(-0500)] <athena> complains less the next time

[13:37:54 CDT(-0500)] <athena> yeah

[13:37:57 CDT(-0500)] <athena> i'm sure the translations aren't great

[13:38:06 CDT(-0500)] <athena> but seems easier to fix the broken ones than do it all from scratch?

[13:39:08 CDT(-0500)] <Arvids> hmm... on the other hand - inserting keys with default (English) translation would help too...

[13:39:33 CDT(-0500)] <athena> well, the key name itself is now mostly the english message

[13:39:36 CDT(-0500)] <athena> so hopefully that'll help too

[13:39:57 CDT(-0500)] <athena> i'm told that w/ the eclipse resource bundle editor thing you can see all the translations for a string side by side, which also seems helpful

[13:40:17 CDT(-0500)] <Arvids> yes, i'm using it

[13:40:26 CDT(-0500)] <Arvids> but do adopters use it?

[13:40:33 CDT(-0500)] <athena> i've heard the french community uses it

[13:41:06 CDT(-0500)] <athena> you're really the first person with much internationalization expertise to be really involved in trunk dev though

[13:41:21 CDT(-0500)] <athena> sadly we've of course had a lot of language barriers that have made it harder for everyone to collaborate

[13:42:35 CDT(-0500)] <Arvids> Each large nation values its language a lot... it's not the case for such little nation as mine

[13:42:49 CDT(-0500)] <Arvids> I'm forced to know at least 3 languages here

[13:43:18 CDT(-0500)] <athena> yeah, you're much more educated than we are

[13:44:07 CDT(-0500)] <Arvids> Heh... i could even do the basic translation for Russian language too

[13:45:35 CDT(-0500)] <Arvids> that reminds me that we have some folks on user list from russia... i'm wondering why aren't they asking for their locale provided out of the box

[13:48:10 CDT(-0500)] <athena> i'd be all for a russian translation

[13:48:21 CDT(-0500)] <athena> if you're up for QAing it all the better

[13:48:27 CDT(-0500)] <athena> think we might have foudn someone to do arabic too

[13:48:28 CDT(-0500)] <Arvids> I was just looking trhough uPortal manual and couldn't find a clue regarding i18n

[13:48:35 CDT(-0500)] <athena> errr yeah we should add some stuff

[13:48:43 CDT(-0500)] <athena> if you're interested in helping . . .

[13:49:35 CDT(-0500)] <Arvids> I'm not qualified translator, but i can try my best

[13:50:33 CDT(-0500)] <Arvids> I have some colleagues that I can ask for a help

[13:51:40 CDT(-0500)] <athena> awesome

[13:51:53 CDT(-0500)] <athena> and honestly, even just some basic fixing is way better than nothing

[13:53:26 CDT(-0500)] <Arvids> So... could you create the initial message files for Russian?

[13:53:41 CDT(-0500)] <athena> yeah, we can just use the translator plugin to do that

[13:53:52 CDT(-0500)] <Arvids> ... if google's translate service is working for you

[13:53:54 CDT(-0500)] <athena> i'll fix that thing up again to take a configurable list of languages

[13:53:57 CDT(-0500)] <athena> well . . . yes

[13:54:04 CDT(-0500)] <athena> if not i have some other ideas

[13:54:54 CDT(-0500)] <Arvids> sweet

[18:35:27 CDT(-0500)] <drewwills> arg... my eclipse wants to build uportal-war constantly... making the IDE unresponsive... are there any known setup tips for making eclipse behave reasonably here?

Browser not supported