[10:29:22 CDT(-0500)] <rlewis> Hi, I need to change the JVM memory settings. Where do I do that? Thanks!
[10:30:11 CDT(-0500)] <EricDalquist> so you need to change the JVM memory settings for uPortal?
[10:31:38 CDT(-0500)] <rlewis> yes.
[10:32:11 CDT(-0500)] <rlewis> i see some related things in catalina.bat
[10:33:10 CDT(-0500)] <EricDalquist> so on *nix you do:
[10:33:10 CDT(-0500)] <EricDalquist> export CATALINA_OPTS="-Xmx1024m"
[10:33:24 CDT(-0500)] <EricDalquist> there might be a way you can just set CATALINA_OPTS in catalina.bat
[10:34:03 CDT(-0500)] <rlewis> ok. env variables are used. I will do that. I see JAVA_OPTS in catalina.bat
[10:34:12 CDT(-0500)] <EricDalquist> that works too
[10:34:21 CDT(-0500)] <rlewis> Thanks
[10:34:34 CDT(-0500)] <EricDalquist> did you find an OOM error with the 4.0.6 quickstart?
[10:59:23 CDT(-0500)] <EricDalquist> rlewis: I looked at your catalina.out and there isn't much there that helps
[10:59:29 CDT(-0500)] <EricDalquist> can you take a look in uPortal.log?
[11:33:56 CDT(-0500)] <rlewis> I do not have a uPortal.log. I guess it didn't get that far. Tomcat is running but uPortal does not deploy
[11:36:42 CDT(-0500)] <EricDalquist> do you have a localhost.2012-08-20.log file? could you pass that along?
[11:40:03 CDT(-0500)] <EricDalquist> arg ... went to boot up my windows vm to test the quickstart there
[11:40:15 CDT(-0500)] <EricDalquist> now I get to spend 20 minutes waiting for it to install updates
[12:05:28 CDT(-0500)] <rlewis> Hi Eric, When I put any JAVA_OPTS on there at all tomcat will not start. I am running on Windows Server.
[12:07:37 CDT(-0500)] <EricDalquist> oh ... is this using the quickstart?
[12:29:53 CDT(-0500)] <EricDalquist> rlewis: I'm at a bit of a loss as to what is going on
[12:30:19 CDT(-0500)] <EricDalquist> it seems like the uPortal webapp is partially missing or corrupt or something
[14:56:12 CDT(-0500)] <drewwills> athena I pushed that change from earlier to a branch on my local fork: https://github.com/drewwills/uPortal/commit/0e5afd5d3bdfcd95587bf2f0f12be2e1ba78f2d3
[14:57:13 CDT(-0500)] <drewwills> i'd love to discuss the divide between that and the the stuff forming on the wiki page
[14:57:36 CDT(-0500)] <drewwills> what lies in the middle, and how to get from a to b
[15:02:42 CDT(-0500)] <athena> i guess i'm not really clear on what this patch accomplishes
[15:02:51 CDT(-0500)] <athena> maybe you could describe what you're trying to do there?
[15:03:43 CDT(-0500)] <drewwills> allow non-local accounts to have some attributes set in the uPortalAccountUserSource
[15:04:11 CDT(-0500)] <EricDalquist> seems reasonable
[15:04:18 CDT(-0500)] <drewwills> i'd like to be able to click the "Edit" buttn on a non-local account in User Manager
[15:04:30 CDT(-0500)] <EricDalquist> so an account from some exterior source is also pulling in user attributes from the local db
[15:04:41 CDT(-0500)] <athena> would probably need additional configuration to specify exactly which attributes can be persisted, and for which group
[15:04:44 CDT(-0500)] <drewwills> yep, that's it in a nutshell
[15:05:23 CDT(-0500)] <drewwills> i'd like to develop the wiki page we started to form a plan in that respect
[15:05:33 CDT(-0500)] <athena> ok
[15:05:39 CDT(-0500)] <athena> what do we think of what's on the wiki page now?
[15:06:15 CDT(-0500)] <drewwills> i think i may not have visited since the last change... will do so
[15:06:24 CDT(-0500)] <drewwills> i have to hop on a quick call though
[15:28:31 CDT(-0500)] <drewwills> athena it looks like your notes imagine tackling these changes (at least partially) through the PersonDir API, which I would agree with
[15:28:54 CDT(-0500)] <drewwills> it may be an opportunity to apply some polish there... smooth over some rough edges
[15:30:04 CDT(-0500)] <drewwills> I wonder if we need some sort of IPersonAttributeDaoMetaData type
[15:30:18 CDT(-0500)] <drewwills> so that DAOs can tell you what features they support
[15:30:29 CDT(-0500)] <drewwills> and so forth
[15:30:38 CDT(-0500)] <EricDalquist> I would do this in teh spirit of PD
[15:30:41 CDT(-0500)] <EricDalquist> and NOT as part of that API
[15:30:50 CDT(-0500)] <EricDalquist> that is going to be nightmare to make that API 2 way
[15:31:56 CDT(-0500)] <drewwills> have you ever considered @Depricating IPersonAttributeDao, then starting over with a much simpler API and class hierarchy?
[15:32:02 CDT(-0500)] <EricDalquist> yes
[15:32:10 CDT(-0500)] <EricDalquist> I have a bunch of notes on paper on doing just that
[15:32:15 CDT(-0500)] <drewwills> you could re-impl the old api on the back of the new
[15:32:49 CDT(-0500)] <drewwills> if that work were done, do you think 2 way would be less of a nightmare?
[15:33:19 CDT(-0500)] <EricDalquist> that would require redesign of my current on-paper notes
[15:33:28 CDT(-0500)] <EricDalquist> so it could be considered as a feature for the redesign work
[15:33:41 CDT(-0500)] <EricDalquist> but right now I think the best bet is a small out-of-band add on
[15:33:54 CDT(-0500)] <EricDalquist> essentially like athena described
[15:33:54 CDT(-0500)] <athena> drewwills: i should have made that more clear. actually i didn't think using person directory was going to be a good idea
[15:33:55 CDT(-0500)] <drewwills> fwiw i think that if personDir were easier to grok & configure, they'd be lining up to thank you at the next conference
[15:34:05 CDT(-0500)] <EricDalquist> oh I know
[15:34:07 CDT(-0500)] <athena> perhaps it'd be better to name that interface more clearly to signal that separation
[15:34:25 CDT(-0500)] <drewwills> yes athena I think it would be
[15:34:30 CDT(-0500)] <EricDalquist> a service that handles describing which attributes are mutable for which groups
[15:34:38 CDT(-0500)] <EricDalquist> and then a dao interface for doing that
[15:34:41 CDT(-0500)] <athena> right
[15:34:47 CDT(-0500)] <EricDalquist> and then for your need you can write an impl that goes to ldap
[15:34:49 CDT(-0500)] <EricDalquist> or local accounts
[15:34:51 CDT(-0500)] <EricDalquist> or whatever
[15:34:52 CDT(-0500)] <athena> i think that's roughly what the wiki describes?
[15:34:55 CDT(-0500)] <EricDalquist> yup
[15:35:01 CDT(-0500)] <EricDalquist> and we take that as a note
[15:35:06 CDT(-0500)] <EricDalquist> and keep it in mind for a PD rewrite
[15:35:41 CDT(-0500)] <athena> so other than the naming change, are there other things we'd like on that wiki plan?
[15:36:57 CDT(-0500)] <drewwills> fyi the main side effect of the patch i posted seems to be that you can enter a password for local auth
[15:37:11 CDT(-0500)] <drewwills> don't know it that's a feature or a bug
[15:37:37 CDT(-0500)] <EricDalquist> depends on how you have your security config setup
[15:37:39 CDT(-0500)] <EricDalquist> if you have local auth off it doesn't matter
[15:37:51 CDT(-0500)] <drewwills> that's true
[15:38:12 CDT(-0500)] <athena> right
[15:38:18 CDT(-0500)] <athena> so depends on what you want and what you want the permissions to be
[15:38:33 CDT(-0500)] <athena> i think the plan in the wiki would cover this, since you could simply leave password off the list for everyone but local users
[15:38:39 CDT(-0500)] <EricDalquist> yup
[15:38:47 CDT(-0500)] <athena> and we could assume that attributes that aren't persistable shouldn't be in the editing interface
[15:39:21 CDT(-0500)] <drewwills> sounds good
[15:39:30 CDT(-0500)] <athena> and then your line to actually create a user should be in the local-specific implementation, of course
[15:41:01 CDT(-0500)] <drewwills> i think i follow... the dao.createUser() call would get moved into the LocalPersistingPersonAttributeDAO?
[15:41:23 CDT(-0500)] <drewwills> and the useraccounthelper would know about IPersistingPersonAttributeDAOs?
[15:41:37 CDT(-0500)] <drewwills> something along those lines
[15:42:31 CDT(-0500)] <athena> yeah
[15:44:46 CDT(-0500)] <drewwills> for the moment, do you think the ability to edit attributes for non-local users should be a config setting? (this line – if (false / TODO: config / && !isLocalAccount(target)) {) and if so, should it be on or off?
[15:45:45 CDT(-0500)] <drewwills> i would say it should, but I know there's sometimes issues with options that are off by default and atrophy
[15:46:35 CDT(-0500)] <athena> no, i don't think we need a boolean setting there
[15:47:13 CDT(-0500)] <athena> if there aren't any non-local user attribute mappings provided, it'll have the effect of not persisting credentials anywhere else
[15:47:41 CDT(-0500)] <drewwills> yeah we wouldn't want that
[15:48:35 CDT(-0500)] <drewwills> a couple questions about this line: The configuration should enable statements like "Persist user attribute 'a' via persistence implmenetation 's' for users in group g".
[15:48:51 CDT(-0500)] <drewwills> (1) is that user-manager config? or something broader
[15:49:42 CDT(-0500)] <athena> i think that maps to what eric described as "a service that handles describing which attributes are mutable for which groups"
[15:49:54 CDT(-0500)] <athena> so no, that's not user-manager config
[15:49:59 CDT(-0500)] <drewwills> (2) would the config be a list of these: <bean class="org.jasig.portal.portlets.account.PreferenceInputFactory" factory-method="createSingleTextPreference"><constructor-arg value="telephoneNumber"/><constructor-arg value="attribute.displayName.telephoneNumber"/></bean>
[15:50:25 CDT(-0500)] <athena> the config needs to be something more than that - needs to include the group and DAO impl mapping
[15:50:32 CDT(-0500)] <athena> but yes, plausible that it should also include the input method