[05:59:26 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal <EricDalquist> <pathelement location="$ " /> <EricDalquist> <artifact:pom file="@ /pom.xml" id="@ .pom" /> <EricDalquist> <artifact:dependencies pathid="@ .classpath" verbose="false"> <EricDalquist> <pom refid="@ .pom" />
[08:33:37 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:42:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
[08:42:33 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[08:56:50 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[09:15:28 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined ##uportal
[09:16:48 EDT(-0400)] <dstn> So I have a subscribe_id n958 in this external table but in up_layout_struct I see no struct_id of 958. Does this mean the channel was deleted? Do values get deleted out of up_layout_struct when you delete a channel?
[09:17:18 EDT(-0400)] <EricDalquist> the user probably removed the channel from their layout
[09:18:08 EDT(-0400)] <EricDalquist> and no, when you delete a channel nothing gets deleted from the layouts
[09:18:17 EDT(-0400)] <EricDalquist> actually nothing gets delete from up_channel
[09:18:31 EDT(-0400)] <EricDalquist> the channel is really just marked inactive
[09:20:08 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined ##uportal
[09:38:01 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[09:41:51 EDT(-0400)] <EricDalquist> hrm ... just found an annoying channel/portlet missmatch
[09:42:12 EDT(-0400)] <EricDalquist> the error channel is essentially a portlet entity level thing
[09:42:42 EDT(-0400)] <EricDalquist> so as support for transient portlet windows (exclusive/detached) appears the error handling gets confusing
[09:42:50 EDT(-0400)] <athena> ah
[09:42:51 EDT(-0400)] <athena> hm
[09:43:00 EDT(-0400)] <EricDalquist> I'm not sure how much longer we can keep up the portal>channel>portlet abstraction
[09:43:26 EDT(-0400)] <athena> is it a useful abstraction to maintain going forward?
[09:43:29 EDT(-0400)] <EricDalquist> I'm thinking the rendering code is going to need to be refactored fairly soon to make portlets top-level items
[09:43:32 EDT(-0400)] <EricDalquist> not really
[09:43:34 EDT(-0400)] <athena> gotcha
[09:43:39 EDT(-0400)] <EricDalquist> it was left because it was easier
[09:43:42 EDT(-0400)] * athena advocates death to channels
[09:43:57 EDT(-0400)] <EricDalquist> I'm guessing that when we try to integrate portlet 2.0 it will have to go away
[09:44:10 EDT(-0400)] <EricDalquist> I think having a channel adaptor portlet would be doable though
[09:44:45 EDT(-0400)] <EricDalquist> I did get detached working for portlets though 
[09:45:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
[09:46:26 EDT(-0400)] <athena> awesome
[09:46:35 EDT(-0400)] <EricDalquist> yeah
[09:46:39 EDT(-0400)] <athena> and i like the idea of having a channel adaptor portlet, for backwards compatibility
[09:46:46 EDT(-0400)] <EricDalquist> should work well if a portlet needs to do a pop-up
[09:46:52 EDT(-0400)] <athena> awesome
[09:49:49 EDT(-0400)] <EricDalquist> I wish there was a css "reset" style
[09:50:06 EDT(-0400)] <EricDalquist> so I could stick it around the inner most portal rendered div that wraps each portlet
[10:10:55 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[10:22:52 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:41:33 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:49:37 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:06:37 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[11:07:41 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
[11:13:32 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:22:10 EDT(-0400)] <athena> EricDalquist: do you know where the uportal-impl.classpath gets generated in the uportal build.xml?
[11:22:27 EDT(-0400)] <EricDalquist> heh, yeah ... just a sec
[11:22:43 EDT(-0400)] <athena> sure, thanks
[11:23:00 EDT(-0400)] <EricDalquist> line 817 in trunk
[11:23:00 EDT(-0400)] <EricDalquist> <macrodef name="uportal-impl-macro">
[11:23:22 EDT(-0400)] <EricDalquist> uportal-impl.classpath is generated by the maven-artifact-macro
[11:23:28 EDT(-0400)] <athena> hm, ok
[11:23:41 EDT(-0400)] <EricDalquist> it should include all dependencies declared in the uportal-impl pom
[11:23:48 EDT(-0400)] <athena> i guess i don't quite understand how it works
[11:24:08 EDT(-0400)] <EricDalquist> so go to line 721
[11:24:17 EDT(-0400)] <EricDalquist> <macrodef name="maven-artifact-macro">
[11:24:33 EDT(-0400)] <EricDalquist> that macro takes a project name & path
[11:24:40 EDT(-0400)] <EricDalquist> a project corresponds with a pom.xml file here
[11:24:57 EDT(-0400)] <EricDalquist> line 732-735 use the Maven ant tasks JAR
[11:25:00 EDT(-0400)] <athena> oh! this is all different in 3.1
[11:25:16 EDT(-0400)] <EricDalquist> it should be essentially the same since 3.0
[11:25:17 EDT(-0400)] <athena> i think this makes more sense now
[11:25:29 EDT(-0400)] <EricDalquist> line #s are probably different
[11:25:38 EDT(-0400)] <athena> actually it looks a lot different
[11:25:41 EDT(-0400)] <EricDalquist> but the way the macros work has not changed since the very first 3.0 release
[11:26:00 EDT(-0400)] <EricDalquist> what are you looking at that is different?
[11:26:05 EDT(-0400)] <athena> i was confused by the code in 3.0 that seemed to be combining the uportal-impl.classpath into uportal-impl-full.classpath
[11:26:09 EDT(-0400)] <athena> but that all seems to be gone now
[11:26:21 EDT(-0400)] <EricDalquist> it is still there
[11:26:32 EDT(-0400)] <EricDalquist> line 828
[11:26:36 EDT(-0400)] <EricDalquist> <path id="uportal-impl-full.classpath">
[11:26:36 EDT(-0400)] <EricDalquist> <path refid="uportal-impl.classpath" />
[11:26:37 EDT(-0400)]
[11:26:37 EDT(-0400)] <EricDalquist> </path>
[11:26:51 EDT(-0400)] <athena> ah, there we go
[11:27:20 EDT(-0400)] <EricDalquist> so the uportal-impl.classpath and uportal-impl.artifact are both created by the maven-artifact-macro
[11:27:27 EDT(-0400)] <athena> so uportal-impl.classpath gets generated by the maven-artifact-macro, and then uportal-impl-macro putts then together?
[11:27:32 EDT(-0400)] <EricDalquist> right
[11:27:47 EDT(-0400)] <athena> thanks, i think that makes more sense now
[11:28:20 EDT(-0400)] <athena> i think i had some problems before w/ the database jar not ending up on that classpath when the jdbc dependency properties were specified on the command line
[11:28:41 EDT(-0400)] <EricDalquist> that wouldn't supprise me
[11:28:49 EDT(-0400)] <athena> i'll have to try again and see
[11:28:57 EDT(-0400)] <athena> would you expect profiles to have problems as well?
[11:29:03 EDT(-0400)] <EricDalquist> no
[11:29:11 EDT(-0400)] <EricDalquist> well
[11:29:12 EDT(-0400)] <EricDalquist> hrm
[11:29:28 EDT(-0400)] <EricDalquist> the issues would be with:
[11:29:29 EDT(-0400)]
[11:29:29 EDT(-0400)]
[11:29:29 EDT(-0400)]
[11:29:30 EDT(-0400)] <EricDalquist> </artifact:dependencies>
[11:29:36 EDT(-0400)] <EricDalquist> I have no idea how to tell those which profile to use
[11:30:29 EDT(-0400)] <athena> ok, i'll take a look at it
[11:30:53 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:31:33 EDT(-0400)] <athena> stuff like this is part of why i'd really like to move to all maven
[11:31:41 EDT(-0400)] <EricDalquist> yup
[11:31:43 EDT(-0400)] <EricDalquist> me too
[11:31:50 EDT(-0400)] <EricDalquist> we need to start documenting how that would happen
[11:32:39 EDT(-0400)] <athena> that'd be fantastic
[11:32:40 EDT(-0400)] <athena>
[11:33:04 EDT(-0400)] <athena> i don't know whether we'd wind up needing a maven plugin or not
[11:33:09 EDT(-0400)] <athena> but we can look into our options
[11:33:20 EDT(-0400)] <EricDalquist> yeah
[11:34:48 EDT(-0400)] * athena kicks maven.apache.org
[11:41:23 EDT(-0400)] <EricDalquist> biab
[11:46:15 EDT(-0400)] <athena> ugh, apparently profiles are not supported
[11:53:41 EDT(-0400)] * Sememmon (n=Sememmon@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:09:39 EDT(-0400)] <EricDalquist> :/
[12:15:23 EDT(-0400)] <awills> EricDalquist – does it make sense to configure Attributes.CACHE for imp/exp something like this: http://uportal.pastebin.com/dfe92700
[12:15:53 EDT(-0400)] <EricDalquist> hrm
[12:16:03 EDT(-0400)] <EricDalquist> for the command line usage, probably not
[12:16:11 EDT(-0400)] <EricDalquist> those are so short lived
[12:16:18 EDT(-0400)] <awills> ehcache.xml > cacheContext.xml > importExportContext.xml
[12:16:18 EDT(-0400)] <EricDalquist> but for usage within the portal
[12:16:27 EDT(-0400)] <EricDalquist> then yeah that makes a little more sence
[12:16:50 EDT(-0400)] <awills> we could give a shorter time-to-live?
[12:17:25 EDT(-0400)] <awills> i guess the 1st question is: do the ehcache-backed maps have the threading characteristics we need?
[12:17:34 EDT(-0400)] <EricDalquist> yes, they are inherently thread-safe
[12:18:06 EDT(-0400)] <EricDalquist> so I don't think there would be a big downside to that
[12:18:08 EDT(-0400)] <awills> then can we pick a config that works well enough for both?
[12:18:10 EDT(-0400)] <EricDalquist> though, the more I think about it
[12:18:29 EDT(-0400)] <EricDalquist> I think the cache one level makes more sense for i/e scripts running in the portal
[12:18:34 EDT(-0400)] <EricDalquist> they aren't going to be heavily used
[12:19:04 EDT(-0400)] <EricDalquist> and the one/forever model that is used by default helps keep the cost of XML/CRN/Script parsing down
[12:19:34 EDT(-0400)] <EricDalquist> the larger LRU cache approach for the command line works there because memory is cheap in that case and the data only lives until the large scale import/export is done
[12:19:56 EDT(-0400)] <EricDalquist> using the ehcache backing for the command line would be fine though it would likely be more overhead for very little benefit
[12:20:19 EDT(-0400)] <EricDalquist> the problem with the ehcache in the running portal for i/e is we could potentially cache a lot of stuff
[12:20:25 EDT(-0400)] <EricDalquist> and shortening the TTL helps
[12:20:43 EDT(-0400)] <EricDalquist> but then we loose the cached CRN/XML/Script parsing
[12:20:51 EDT(-0400)] <EricDalquist> so those portlets would be slow if they aren't used regularly
[12:23:22 EDT(-0400)] <awills> well, i'm moving many individual tasks and their config to importExportCache.xml (as discussed), and I have the chance to manage Attributes.CACHE in spring too
[12:23:32 EDT(-0400)] <EricDalquist> yeah
[12:23:36 EDT(-0400)] <EricDalquist> I see where you're coming from
[12:23:51 EDT(-0400)] <EricDalquist> I'm just a little worried that moving to an EHCache backed Map would actually hurt a bit
[12:24:04 EDT(-0400)] <awills> certainly i can just create a bean based on a synchronized map
[12:24:07 EDT(-0400)] <EricDalquist> unless we want the ability to reparse .crn files in a running portal or some such
[12:24:10 EDT(-0400)] <awills> or concurrenthashmap
[12:24:20 EDT(-0400)] <EricDalquist> well for the command line you need something like the exisitng LRU Map
[12:24:28 EDT(-0400)] <EricDalquist> otherwise you'll fill up the heap
[12:24:53 EDT(-0400)] <awills> does the existing LRU map include ttl?
[12:25:04 EDT(-0400)] <EricDalquist> no
[12:25:10 EDT(-0400)] <EricDalquist> it just has a fixed number of elements
[12:25:19 EDT(-0400)] <EricDalquist> it is designed for the command-line usecase
[12:25:34 EDT(-0400)] <EricDalquist> where there is no long-term execution plan, just do all the import or export and quit
[12:25:47 EDT(-0400)] <EricDalquist> with the LRU map being a limit on how much memory is used
[12:26:13 EDT(-0400)] <awills> k, i think i see where you're thinking is here
[12:26:32 EDT(-0400)] <awills> there may be some CACHE_ALL in the existing imp/exp setup
[12:26:40 EDT(-0400)] <EricDalquist> right
[12:26:47 EDT(-0400)] <awills> if it were CACHE_ONE it mightn't be an issue
[12:26:48 EDT(-0400)] <EricDalquist> which is a very good thing for the command line imp/exp
[12:26:58 EDT(-0400)] <awills> sure
[12:27:01 EDT(-0400)] <EricDalquist> CACHE_ONE is quite a bit slower when doing layout or channel work
[12:27:24 EDT(-0400)] <EricDalquist> where as when running in the portal CACHE_ONE is probably more appropriate
[12:27:36 EDT(-0400)] <awills> yeah exactly
[12:27:41 EDT(-0400)] <EricDalquist> in which case the only advantage of a ehcache backed Map would be the TTL
[12:27:49 EDT(-0400)] <awills> no worries, i can do something appropriate
[12:27:50 EDT(-0400)] <EricDalquist> so do we want cached CRN data to eventually expire?
[12:28:18 EDT(-0400)] <EricDalquist> oh, do you have an idea of what the new .layout format is going to look like?
[12:28:24 EDT(-0400)] <awills> i can leave it the way it is until we get some further analysis
[12:28:29 EDT(-0400)] <awills> sure
[12:29:06 EDT(-0400)] <awills> this is not finished, but it gives the general idea: http://uportal.pastebin.com/d37d18626
[12:29:22 EDT(-0400)] <awills> needs UP_SS_USER_ATTS, portlet preferences
[12:29:27 EDT(-0400)] <EricDalquist> ok
[12:29:38 EDT(-0400)] <EricDalquist> and the DLM: stuff will turn into noderefs like we have now?
[12:29:49 EDT(-0400)] <awills> also DLM_NODEREF translation... which is what i was last working on
[12:29:57 EDT(-0400)] <EricDalquist>
[12:30:03 EDT(-0400)] <awills> yes, exactly what we do now
[12:30:14 EDT(-0400)] <EricDalquist> looks good
[12:31:09 EDT(-0400)] <athena> are the maven ant tasks built into ant?
[12:31:16 EDT(-0400)] <awills> i can inject the lookup-dlm-noderef task into my instance of rdbmdistributedlayoutstore, which i inject into export-layout...
[12:31:23 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:31:39 EDT(-0400)] <EricDalquist> no
[12:31:43 EDT(-0400)] <EricDalquist> it is an external jar
[12:31:46 EDT(-0400)] <EricDalquist> in bootstrap
[12:31:46 EDT(-0400)] <athena> oh awesome
[12:31:46 EDT(-0400)] <athena> thanks
[12:32:04 EDT(-0400)] <awills> the reason i started asking cache questions was b/c i was looking for a way to inject Attributes.CACHE into lookup-dlm-noderef
[12:32:09 EDT(-0400)] <EricDalquist> brb
[12:32:27 EDT(-0400)] <athena> it'd be nice if this ticket included a little more info: http://jira.codehaus.org/browse/MANTTASKS-56
[12:33:04 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:33:42 EDT(-0400)] <EricDalquist> http://jira.codehaus.org/browse/MANTTASKS-35
[12:33:47 EDT(-0400)] <EricDalquist> looks like it is still open
[12:33:50 EDT(-0400)] <EricDalquist> brb again
[12:34:07 EDT(-0400)] <athena> yeah
[12:34:12 EDT(-0400)] <athena> i'm not sure why the other ticket is closed though
[12:34:16 EDT(-0400)] <athena> going to look at the source
[12:50:36 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[13:18:46 EDT(-0400)] <athena> does anyone happen to know where the maven svn repository is?
[13:18:59 EDT(-0400)] <athena> i can't get any of the relevant apache documentation pages to load
[13:19:22 EDT(-0400)] <EricDalquist> hrm
[13:20:03 EDT(-0400)] <athena> i can only find the viewvc link, which isnt' really what i want
[13:20:10 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:20:10 EDT(-0400)] <EricDalquist> http://maven.apache.org/source-repository.html that works for me
[13:20:17 EDT(-0400)] <EricDalquist> http://svn.apache.org/repos/asf/maven
[13:20:19 EDT(-0400)] <EricDalquist> that is the repo
[13:20:29 EDT(-0400)] <athena> oh! thanks
[13:20:37 EDT(-0400)] <athena> interesting that that link doesn't work for me
[13:20:41 EDT(-0400)] <athena> wonder if it's the yale network then
[13:20:45 EDT(-0400)] <EricDalquist> yeah
[13:20:53 EDT(-0400)] <athena> weird because most other stuff works fine
[13:20:54 EDT(-0400)] <EricDalquist> http://svn.apache.org/repos/asf is actually the root apache svn repo
[13:21:05 EDT(-0400)] <athena> thanks eric
[13:21:48 EDT(-0400)] <athena> weird - the svn stuff works perfectly
[13:21:56 EDT(-0400)] <athena> but maven.apache.org, not so much
[13:25:53 EDT(-0400)] <EricDalquist> np
[13:26:03 EDT(-0400)] <EricDalquist> I'll be back in in ~ 45
[13:33:22 EDT(-0400)] * athena (n=athena@dhcp128036007132.central.yale.edu) has joined ##uportal
[14:15:42 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[14:16:41 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[16:04:53 EDT(-0400)] * SusanB (i=user@susan-x200.its.yale.edu) has joined ##uportal
[16:19:39 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[17:02:07 EDT(-0400)] <awills> EricDalquist I believe this layout representation includes all necessary data: http://uportal.pastebin.com/d6e1c80fe
[17:02:49 EDT(-0400)] <EricDalquist> looks like it to me too
[17:03:17 EDT(-0400)] <awills> now to reverse-engineer that on import O.o
[17:03:23 EDT(-0400)] <EricDalquist>
[17:04:51 EDT(-0400)] <awills> but first a quick question: looks like folder attributes are structure transform only... does that mean that channel attributes are theme transform only?
[17:05:01 EDT(-0400)] <EricDalquist> I think so
[17:05:10 EDT(-0400)] <EricDalquist> but I'm not 100% sure
[17:05:14 EDT(-0400)] <awills> good... from UP_SS_USER_ATTS
[17:05:20 EDT(-0400)] <EricDalquist> but that shouldn't affect i/e
[17:05:22 EDT(-0400)] <awills> well we'll learn soon
[17:05:27 EDT(-0400)] <EricDalquist> well ...
[17:05:37 EDT(-0400)] <EricDalquist> is there a type column in UP_SS_USER_ATTS?
[17:05:45 EDT(-0400)] <awills> i had to integrate those atts
[17:06:10 EDT(-0400)] <awills> yeah there's an SS_TYPE and STRUCT_ID
[17:06:34 EDT(-0400)] <awills> so if SS_TYPE=theme, the struct_id should point to a channel?
[17:06:35 EDT(-0400)] <EricDalquist> I'm trying to remember what SS_TYPE is for
[17:06:42 EDT(-0400)] <awills> 1 or 2
[17:06:50 EDT(-0400)] <EricDalquist> yeah
[17:06:57 EDT(-0400)] <EricDalquist> so I think those attrs can point to any node
[17:07:03 EDT(-0400)] <EricDalquist> for any type
[17:07:10 EDT(-0400)] <EricDalquist> and 1 == struct, 2 == theme
[17:07:19 EDT(-0400)] <EricDalquist> channel properties are separate from UP_SS_USER_ATTS
[17:07:35 EDT(-0400)] <EricDalquist> they are incorporated into the layout at a different point
[17:07:44 EDT(-0400)] <EricDalquist> but I don't think that matters for this
[17:07:49 EDT(-0400)] <EricDalquist> since they are exported as part of the .channel
[17:07:50 EDT(-0400)] <awills> well, the ThemeStylesheetUserPreferences class does not have a getFolderAttributeNames() method and so forth
[17:08:39 EDT(-0400)] <awills> but the StructureStylesheetUserPreferences does have a getChannelAttributeNames() method (through inheritance)
[17:08:52 EDT(-0400)] <EricDalquist> heh
[17:08:55 EDT(-0400)] <awills> lol
[17:08:56 EDT(-0400)] <EricDalquist> yeah, I'm not sure
[17:09:04 EDT(-0400)] <EricDalquist> without actually digging into the rendering pipeline code
[17:09:37 EDT(-0400)] <awills> i bet struct can have both, but not theme
[18:13:51 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[19:21:55 EDT(-0400)] <holdorph> has anyone tried to build uPortal with maven 2.1.0 ? just wondering if it's known to work or not, before I bother setting up an environment with it
[19:26:47 EDT(-0400)] <athena> holdorph: i think it works
[19:26:57 EDT(-0400)] <athena> er
[19:27:03 EDT(-0400)] <athena> no i updated to 2.0.10 i think?
[19:27:55 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[21:00:46 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
Unknown macro: {uportal-impl.artifact}
Unknown macro: {project-path}
Unknown macro: {project-name}
Unknown macro: {project-name}
Unknown macro: {project-name}
General
Content
Integrations