Re: PSML caching, PSML reference customization storage, User/Role PSM L integration

[Todd Kuebler <tk...@cisco.com>]

First of all turn off PSML caching in JR.p.  that might solve some of your 
concurrency issues.

Do you know about the PSMLManager interface 
(org.apache.jetspeed.services.psmlmanager.*)?  This sounds like the point 
you could integrate this merge thing much smoother by dynamically creating 
a psml document from user + role documents, and managing keeping user prefs 
up to date.  Also, are you manipulating the psml documents as DOM/whatever 
objects or doing string manipulation on the content?

role <-> user psml merging is supported sort of how you describe in later 
versions of jetspeed through a psml link in user psml.  however since the 
linked psml document itself is shared across uses writes to that portion of 
the psml is disabled, so users can't set their own preferences for those 
portlets.

I would really recommend planning on updating to 1.5 when it comes out (soon?).

-tk


btw, it should be easy to write that un compression algorithm if you are 
not interested in merely duplicating the original document. ;)


At 11:03 AM 8/22/2003 -0400, Wolgemuth, Gregory wrote:
>Greetings and salutations to all
>
>I'm a summer student working with a team that's doing evaluation of Jetspeed
>for use as an information portal system for our company. One of our
>requirements is to have strong binding between roles and users in the
>portal. To be more specific, each role we create will have a very specific
>set of portlets available to it, and only it. This means we'd like for a
>user to have their initial set of portlets be set based on their roles.
>We've got that functionality working by disabling the new-user template and
>building default role PSML.
>
>However, we need this functionality to extend further into the user's
>lifespan. Basically, if a user receives a new role, we'd ideally like their
>PSML to automatically pick up the PSML of the new role. The solution I tried
>to implement was a 'merge' tool, which would at the least enable an admin to
>place a reference to role PSML or the role PSML itself into the user PSML.
>
>I'm e-mailing this list as my attempts to do that have been ... 'disastrous'
>would seem to be a good way to put it!
>
>What I've done to date is:
>Modify the appropriate velocity templates in the PSML browser to show a
>'Merge' option for each PSML file, and also show an interface.
>My first attempt to 'Merge' used this algorithim:
>Open the XML file to be merged from, pull out all the relevant information
>(basically, all that lives between the first <meta-info> tagset and the last
></portlets> tag)
>Slap all that into the destination PSML file before the last </portlets>
>Needless to say, the above simply caused the afflicted user to stop working
>- conflict with ID numbers and formatting would be my best guess as to why.
>My second attempt to do a merge was much like the first, only it used a
>reference with a unique ID number - which almost worked.
>
>My issue now is overcoming the way in which PSML for the user gets cached -
>as my silly hack to get around my total lack of knowledge regarding the API
>is at best horribly unstable (I've gotten very used to restarting Tomcat
>every time I do something new and seeing StackOverflow messages every minute
>or two). After updating the PSML, logging in as the updated user, logging
>out, updating the PSML again, and logging back in as the updated user, only
>the first update to the PSML is acknowledged (assuming PSML is cached and
>not restored from disk b/c I'm not using API call).
>
>So, my request to any more learned developers (ie: anyone who knows how to
>find what they're looking for in the source documents) is for suggestions to
>implement this improvement or at least a pointer to a Jetspeed source doc
>which contains similar code I can learn from (my attempts to navigate and
>find the appropriate source files have worked just as well as my
>'improvements' to JetSpeed)
>
>Sorry for the length of the e-mail, but I wanted to be clear on the
>requirement/background and the implementation routes I've already tried (so
>that if I've missed the obvious, someone can fill me in quickly :)
>
>Oops, almost forgot - We're using 1.4b3 for our dev work, with Tomcat
>running as the webserver. My dev work is being done on Win2K pro, other
>people are doing dev work with other Win versions, and various Linux
>distros. Final version (if we're ever satisfied enough to deploy one :P)
>will most likely be on a Redhat Linux server, with Apache running over
>Tomcat/Jetspeed. I think that covers all the bases - again, sorry for the
>length :)
>
>
>
>Greg 'Woogie' Wolgemuth
>"Wow, your compression algorithim got that 300 megabyte file down to ... 3
>bytes"
>"It's great, isn't it?"
>"I take it there's no decompression algorithim yet"
>"...it's harder than it looks"


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org