Re: [uportal-dev] Help with @Autowired

[Eric Dalquist]

Spring app contexts in a web/portlet application form a tree, contexts
further down in the tree can look directly up the tree to resolve
dependencies.

There is usually a listener in web.xml that defines the root application
context
Then each servlet/portlet has its own app context with the root as the
parent

This allows individual servlets and portlets to have their own view
resolvers, controllers, etc without having to worry about stomping on the
rest of the system.

On Thu, May 21, 2015 at 9:16 AM James Wennmacher 
wrote:

>  IM me and I'll see if I can help you out.
>
> James Wennmacher - Unicon
> 480.558.2420
>
> On 05/20/2015 11:48 PM, Benito J. Gonzalez wrote:
>
> Devs,
>
>  Wondering if someone can help me out.
>
>  I am writing a class in *org.jasig.portal.portlets.groupadmin* that is
> similar to the existing helper class there. Both are annotated with
> @Service. The existing one uses @Autowired on a setter for
> IGroupListHelper. In my class, I use the annotation on the field, which
> compiles and deploys just fine.
>
>  In my class, I have three DAOs from the PAGS JPA package. They are
> annotated with @Repository. For example,
> @Repository("personAttributesGroupDefinitionDao”) is one. My understanding
> is that this creates a bean with the specified ID.
>
>  In my class, I have tried
>
>  @Autowired
>
> private JpaPersonAttributesGroupDefinitionDao 
> personAttributesGroupDefinitionDao;
>
>  And
>
>  @Resource(name="personAttributesGroupDefinitionDao")
>
> private JpaPersonAttributesGroupDefinitionDao 
> personAttributesGroupDefinitionDao;
>
>  Both compile but when the war file is deployed uPortal fails. If I
> comment out the annotation for the DAO, uPortal works fine. (The class is
> not used yet.)
> Exceptions all over catalina.out on failure is:
>
>  java.lang.IllegalStateException: Illegal access: this web application
> instance has been stopped already. Could not load
> [META-INF/services/javax.xml.stream.XMLInputFactory].
>
>  @Autowired is suppose to match on class, so I tracked down a duplicate
> DAO bean in the import/export context. I removed those beans and switched
> the  references in that file to the IDs used in the @Repository annotation
> in the three DAO classes. The import works fine with this change.
>
>  Digging further, I noticed that some packages are excluded in the main
> context scan directive. In particular, the portlets package my class is in
> is excluded. The package is included in another context:
> *mvcServletContext.xml*.
>
>  I am a bit stumped at this point. Anyone have advice on what to try
> next? Any overview on the contexts?
>
>  Thank you and good night!
>
>   Benito J. Gonzalez - Unicon
> bgonza...@unicon.net
> 480.558.2360
>
>
>
>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> jwennmac...@unicon.net
>
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PersonDir: v2: status and goals?

[Eric Dalquist]

Andrew is pretty spot on in his assessment of things.

The code that does exist lives here:
https://github.com/Jasig/person-directory/tree/pd-2-dev

There is something that might pass for a design (well more like a brain
dump) in https://github.com/Jasig/person-directory/blob/pd-2-dev/notes.txt

The goals were:

   - Fix the API and the horrible abstraction mess in PD1.X. A big part of
   this was creating an external API that things that used PD2 would call and
   then an internal SPI that things that provided attributes would implement.
   This simplified things A LOT on the attribute source side.
   - Fix the project structure. You'll notice there are api, spi, core,
   util, and jdbc modules. core is where all the actual attribute resolution,
   concurrency, merging, etc logic lives. jdbc is an example spi producer with
   the intent that there would be many more to come.
   - Improve performance by making all attribute lookup concurrent
   - Simplify configuration. The idea is you'd just configure a bunch of
   attribute sources. No need to define call order, chaining, etc. The core
   logic figures out which sources to call and in which order to satisfy the
   query.
   - Add a real query API via critera
   

   classes, this allowed for actual logical queries to be executed and subsets
   of those to get executed against attribute sources.

So with all that, the code that is there is semi-functional but it isn't
great code. It is the result of me hacking on something in my spare time
and more idealistic and realistic at this point. I still think there are
some great ideas and the code just needs some real cleanup (and probably a
real design doc first). I honestly think it could be very valuable to
schools that have more than a few attribute sources in person directory.
All that IO of serially searching for attributes for a user is REALLY
expensive and slows down login quite a bit. Also getting rid of the giant
and complex configuration in favor of a flag collection of attribute
sources that the rest of the code just knows how to use would go a long way
in improving things too.

Hope that all helps and good luck with whatever you do with it.

On Wed Dec 17 2014 at 8:31:28 PM Andrew Petro 
wrote:

>
> 1. Goals:
>
>  * Improved performance through among other things better concurrency ?
>  * Perhaps beat back the significant complexity and
> inheritance-over-composition that has grown into the PersonDirectory
> codebase over time?
>
> 2. Accomplished?
>
>  * there's some code
>  * it's abandonware that could be adopted and un-abandoned
>
> 3. What next?
>
> Well, either finish it, or find a way not to need it (instead adopting,
> say, the Shibboleth IdP AttributeResolver APIs?  Something else?  Has
> anyone other than Jasig / uPortal / Apereo nailed the problem of querying
> user attributes?  Gathering and transforming user attributes is one of
> those things that an Identity Provider is *about*, so maybe there's a way
> to use those APis and implementations and not have to develop and maintain
> PersonDirectory code anymore?)
>
> :)
>
> Adopters of Shibboleth and of uPortal might appreciate the synergy in the
> attribute gathering plugins being the same API to plug in to so that
> attribute gathering configuration solutions that have been developed for
> one product are more readily applicable to the other product.
>
> Kind regards,
>
> Andrew
>
>
>
>
>
> On Wed Dec 17 2014 at 5:14:34 PM Misagh Moayyed 
> wrote:
>
>> Eric (and others),
>>
>> I wasn’t sure what would be the best forum to talk person directory, and
>> so I’ll get started here and you can tell me if this can better be
>> discussed offline, etc.
>>
>>
>>
>> I am interested to learn more about person directory v2 and what we can
>> do to complete it. I know Eric was working on that project for some time
>> but I am not sure where we ended up with that. So I would appreciate if
>> anybody, especially Eric, could share insight on:
>>
>>
>>
>> 1.  What does v2 plan to accomplish in terms of goals?
>>
>> 2.  What has so far been accomplished in view of those goals?
>>
>> 3.  What is left to do?
>>
>> 4.  What can we do to help?
>>
>>
>>
>> Any form of documentation, short of looking at the code, would be great
>> to get started.
>>
>>
>>
>> Misagh
>>
> --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> apetro.li...@gmail.com
>>
>>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, cha

Re: [uportal-dev] uPortal database connection pool size

[Eric Dalquist]

That should be right. The raw events DB pool likely never gets above 2
concurrent connections, one for writing raw events and one for reading. The
aggregate pool needs 1 connection for aggregation and then one per
concurrent query that is run which is likely very low since the reporting
tools are generally admin only.

On Tue Dec 02 2014 at 11:22:31 AM James Wennmacher 
wrote:

>  Answering the question below on the uportal-user list got me thinking (a
> dangerous thing indeed ... :-) ).
>
> Currently all 3 of the uPortal DB connection pool sizes defined in
> datasourceContext.xml are all set to the same max value (of 75 by
> default).  In glancing at the code I am thinking that the raw events DB
> pool and the aggregation events DB pool are running on timed threads and
> only use 1 DB connection each (see
> https://github.com/Jasig/uPortal/blob/uportal-4.1.2/uportal-war/src/main/java/org/jasig/portal/events/handlers/QueueingEventHandler.java#L41
> and
> https://github.com/Jasig/uPortal/blob/uportal-4.1.2/uportal-war/src/main/resources/properties/contexts/schedulerContext.xml#L73).
> They can both have a smaller maxActive value to limit the exposure of an
> error somehow consuming large numbers of DB connections and impacting
> uPortal and portlets (via consuming too many DB connections on the DB
> server).  I was thinking of setting their maxActive value to 5 to allow
> simultaneous threads for saving, purging, and querying.
>
> Does anyone see a problem with this strategy?  UWMadison or someone with
> an active system can you glance at the DB MBeans AggrEventsDB and
> RawEventsDB in uPortal/Datasource and see if the NumActive + NumIdle are
> even close to 5 on your system?  (unfortunately without monitoring tools I
> don't see how you'd find out what the max # of connections ever made was).
>
> Thanks in advance for your insights and thoughts.
>
> James Wennmacher - Unicon
> 480.558.2420
>
>
>
>  Forwarded Message   Subject: Re: [uportal-user] Increase
> database connection pool size  Date: Tue, 02 Dec 2014 11:02:02 -0700  From:
> James WennmacherTo:
> uportal-u...@lists.jasig.org
>
> Database connection counts are defined in
> uportal-war/src/main/resources/properties/contexts/datasourceContext.xml.
>
> uPortal uses the DB connections for a fairly brief period of time.  The
> message 'none available[size:75; busy:0; idle:0; lastwait:5000]' plus
> your comment about leaving it overnight  makes me wonder if somehow the
> connections are being lost and not reclaimed.  I suggest:
>
> 1. Insure that the load test is not hitting servers too heavily; e.g. load
> is distributed evenly.  I could see running out of DB connections happening
> if a server gets hammered (though the connections should be freed up at
> some point later).  Does it happen primarily to one or two servers and not
> all of them?
>
> 2. Try adding the following properties to the basePooledDataSource bean in
> datasourceContext.xml:
>
> 
> 
>
> This may not resolve the issue, but perhaps the logging will provide a
> clue to what's going on.  However it is likely the additional logging will
> not trigger.  The property minEvictableIdleTimeMillis is supposed to
> release a connection after it has been idle for the specified number of
> milliseconds, and the properties abandonWhenPercentageFull,
> removeAbandoned, and removeAbandonedTimeout which are specified are
> supposed to clean up abandon connections (allocated but not used in
> removeAbandonedTimeout seconds when a new connection is requested but none
> are available).  However in a load test scenario, especially one where a
> server is taxed very heavily, the removeAbandonedTimeout value may be too
> high (value is 300 sec) if connections are heavily used so no connections
> may be considered abandoned and harvested during the test.  However I
> wouldn't change removeAbandonedTimeout just yet.  After the test completes
> however there may be some useful log messages if some connections were
> consumed and not released.  If nothing else 5 minutes after the test
> completes you should be able to log onto the server even if all connections
> are consumed since it should consider at least some of the connections as
> abandoned and eligible for harvesting.  However your comment about leaving
> the system overnight and the issue still exists makes me think the abandon
> connections will not be harvested.  Still worth trying logAbandoned to see
> if it provides more info.
>
> 3. Are there other DB connection error messages?  The ones you mentioned
> are for event aggregation (runs periodically to aggregate and purge raw
> portal activity event data) and for jgroups (used for distributed cache
> management to allow uPortal nodes to notify other uPortal nodes about cache
> replication or invalidation).  Were there any for uPortal activity not
> having a database connection?
>
> 4. It would be great to get more information so we can try to fix the
> issue of the connections no

Re: [uportal-dev] Inactive committers

[Eric Dalquist]

You can remove mine as well, as much as I'd like to contribute code the
realities of the world are that list participation is about as much as I
can swing right now.

On Fri Nov 07 2014 at 7:53:20 AM Andrew Petro 
wrote:

> Tim,
>
> Done.
>
> Again, not my preferred resolution to committer inactivity.  Please do
> discover that you desperately want to be actively contributing code to
> uPortal in the future, and that there's something other uPortal committers
> can be doing to help make that happen. :)
>
> Kind regards,
>
> Andrew
>
> On Fri, Nov 7, 2014 at 9:50 AM, Carroll, Tim 
> wrote:
>
>>  you can pull mine.
>>
>>
>>  On Nov 7, 2014, at 10:45 AM, Andrew Petro 
>> wrote:
>>
>>  Cris,
>>
>>  CH> makes the list somehow cleaner
>>
>>  Does,
>>
>>  CH> You could remove my committer-ship
>>
>>  Done, though I emphasize that was only one of the possible outcomes,
>> and I’ll like it even better when you're actively contributing code to
>> uPortal. :)
>>
>>  Andrew
>>
>> On Fri, Nov 7, 2014 at 9:10 AM, Cris J Holdorph 
>> wrote:
>>
>>> You could remove my committer-ship if you want, and that makes the list
>>> somehow cleaner for you.  I have not committed anything recently. However,
>>> I do believe I am still an active member of the community.
>>>
>>>  Cris J H
>>>
>>>
>>> On 11/07/2014 07:08 AM, Andrew Petro wrote:
>>>
  uPortal committers,

 These committers are members of the uportal-developers GitHub team (
 https://github.com/orgs/Jasig/teams/uportal-developers )  but have zero
 commits in Jasig/uPortal/master in the last year (
 https://github.com/Jasig/uPortal/graphs/contributors?
 from=2013-11-07&to=2014-11-07&type=c
 ).

   * Are you active in other GitHub projects that complectedly grant
 their committership through the uportal-developers Team rather than via
 a portlet-specific Team (if so, sorry for the bother!)?
   * Are you active in merging Pull Requests rather than by writing new
 code (if so, sorry for the bother, the naive GitHub reporting doesn't
 credit merge commits.)
   * Is there something active developers can do to help you to again
 become active in contributing code to uPortal?
   * Are you on hiatus but expect to return to activity?
   * Or, sadly, is it time to retire your uportal-developers Team
 membership, no doubt with leave to joyously be re-welcomed in a happily
 more active future?

 Inactive:

 agherna
 agrabovskis
 bourey
 dmccallum
 holdorph
 jeffbcross
 steveswinsburg
 timit
 tuyly
 waymirec
 wgthom

 Kind regards,

 Andrew


  --

 You are currently subscribed to uportal-dev@lists.ja-sig.org as:
 holdo...@unicon.net
 To unsubscribe, change settings or access archives, see
 http://www.ja-sig.org/wiki/display/JSG/uportal-dev


>>> --
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>>> apetro.li...@gmail.com
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>
>>
>>  --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> tcarr...@illinois.edu
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>
>>  --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> apetro.li...@gmail.com
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Adopting Google Style for next major release

[Eric Dalquist]

The line length limit really isn't too terribly bad to get used to, and
really if you consistently have lines longer than 100 characters in Java
your code could probably use some refactoring to become more readable.

The history part is an issue but if the refactoring was done as part of the
modularization it would be much less disruptive. Move a block of related
code into a new module and with that reformat it and enable checkstyle.

On Thu Nov 06 2014 at 2:40:38 PM Cris J Holdorph 
wrote:

> One other 'con' I'd like to bring up, besides Josh's (which I agree 100%
> with), is the following.
>
> I find inconsistent style frustrating, true.  But what I find even more
> frustrating is when I'm trying to debug and I want to know why a line of
> code was last changed.
>
> If you reformat the entire codebase, even for something like uPortal
> 5.0.  Then the history of trying to determine why a line of code is what
> it is, will be difficult, to potentially impossible (depends on how the
> change is made).
>
> It's not enough of a reason to say don't do this.  But for me, it would
> actually be more annoying then the style problems are themselves.
>
>  Cris J H
>
> On 11/06/2014 03:32 PM, James Wennmacher wrote:
> > 100 (or worse yet 80) characters on a line!  Oh man!  I'm going to have
> > to use shorter variable and method names.  At least I only need to
> > indent 2 spaces now.  That will help.  :-)
> >
> > +1 on a 'common' standard, especially if we can get it enforced in the
> > build (as annoying as I find that is sometimes).  Google's is great.
> >
> > James Wennmacher - Unicon
> > 480.558.2420
> >
> > On 11/06/2014 08:04 AM, Andrew Petro wrote:
> >> uPortal developers,
> >>
> >> I think it would be wise for uPortal to adopt tighter code style
> >> conventions (and to enforce these in the release process via build
> >> automation, since without automation style conventions will not be
> >> adhered to.)
> >>
> >> I think those code conventions should be Google's.
> >>
> >> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html
> >>
> >> https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
> >>
> >> etc.
> >>
> >> The product has a heap of code of varying style.  I'd see a changeset
> >> to pervasively adjust style to the convention as only appropriate for
> >> a MAJOR release.  As in, uPortal 5.
> >>
> >> So.  This is the initial conversation-starting email expressing
> >> intention to advocate for this improvement for uPortal 5.
> >>
> >> Andrew
> >>
> >> --
> >>
> >> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> >> jwennmac...@unicon.net
> >> To unsubscribe, change settings or access archives, see
> >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> >
> >
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Adopting Google Style for next major release

[Eric Dalquist]

+1 to what Andrew said.

I've contributed to a lot of different OSS projects pretty much every "big"
project (Spring, Hibernate, Jackson, Ehcache) have strictly enforced style
guides. Did I agree with all the rules of each of these style guides? No,
of course not. Did that make it harder to contribute to them? No, of course
not. It was just a matter of setting the style guide for the project in my
IDE and letting it do the work.

The initial switch can seem like a lot of work and take some time to get
used to. BUT going forward you get tremendous value out of a consistent
code base.

The follow on to a style guide would be running static analysis tools
agains the code base as well.

On Thu Nov 06 2014 at 7:56:05 AM Andrew Petro 
wrote:

> > don't like the recommendation of 2 space indent w/ 4 space continuing
> indent.
>
> No doubt.
>
> But go down that road, and then we have to talk about defining style, and
> your preferences, and my preferences, and then we need to maintain our own
> guide, and then we need to figure out how to automate guiding adherence to
> it and innovate on enforcing our own styles.
>
> Let me be blunt: that will fail.
>
> Or our entire style guide can be "We adopt Google Style."  Done.  Google
> publishes it, Google provides the Eclipse profile that helps your IDE help
> you code to the style, Google updates the guide.
>
> And so instead of working and innovating on defining code style guides, we
> can instead work and innovate on higher education self-service and portal
> experiences.  Let's focus on that and delegate defining code style to
> Google.
>
> I don't personally love every detail of Google Style.  I would be elated
> if we can all agree to sacrifice our personal code style preferences on the
> altar of adopting Google Style as being the feasible, efficient, and
> sustainable coding style to be using in our projects.
>
> :)
>
> Andrew
>
>
>
> On Thu, Nov 6, 2014 at 9:37 AM, Josh Helmer  wrote:
>
>> I mostly good with that, although I really don't like the recommendation
>> of 2
>> space indent w/ 4 space continuing indent.I personally *really*
>> prefer 4
>> space indent and find 2 space indent difficult to read.   Other than
>> that, I
>> don't see anything too objectionable in the google recommendations.
>>
>> On the JS side, again, I'm in favor of some sort of recommended standard,.
>> Something I would think is probably even more important would be a push to
>> move as much of the JS out of the JSPs as possible and then try to use
>> js[hl]int on the code as part of our maven build.  That will catch some
>> of the
>> stylistic things but will also enforce best practices on the JS code (eg.
>> must
>> use var, must use semicolons, etc) which is probably even more valuable.
>>
>> It would be nice to try and move the CSS out of the JSP too.  Then we
>> could
>> use some tooling to enforce best practices and move more of the styling to
>> less.   CSS is just a lot tricker to move though because of the
>> namespacing
>> issues unless we want to discourage the use of IDs in CSS rules (which
>> might
>> not be so bad?)
>>
>> My $0.02.
>> Josh
>>
>>
>> On Thursday, November 06, 2014 09:04:58 AM Andrew Petro wrote:
>> > uPortal developers,
>> >
>> > I think it would be wise for uPortal to adopt tighter code style
>> > conventions (and to enforce these in the release process via build
>> > automation, since without automation style conventions will not be
>> adhered
>> > to.)
>> >
>> > I think those code conventions should be Google's.
>> >
>> > https://google-styleguide.googlecode.com/svn/trunk/javaguide.html
>> >
>> > https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
>> >
>> > etc.
>> >
>> > The product has a heap of code of varying style.  I'd see a changeset to
>> > pervasively adjust style to the convention as only appropriate for a
>> MAJOR
>> > release.  As in, uPortal 5.
>> >
>> > So.  This is the initial conversation-starting email expressing
>> intention
>> > to advocate for this improvement for uPortal 5.
>> >
>> > Andrew
>>
>>
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> apetro.li...@gmail.com
>
>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Rendering Pipeline components for branching and redirecting

[Eric Dalquist]

+1

the rendering pipeline is supposed to be flexible enough to do whatever you
need to do for making the portal render, escaping with a redirect seems
perfectly fine to me.

On Fri, Oct 3, 2014 at 1:30 PM, Andrew Petro  wrote:

> uPortal developers,
>
> I think MyUW has a local need to conditionally branch the rendering
> pipeline (and to terminate it in a redirect on one of those branches).
>
> Design sketch here:
>
> http://apetro.ghost.io/pipelines-need-valves/
>
> I'd love your perspectives and feedback.
>
> I expect that one way or another there will be some portions of the
> eventual solution that should make their way into the uPortal
> framework.
>
> Kind regards,
>
> Andrew
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PortletExecutionManager and extendedTimeoutExecutions

[Eric Dalquist]

It was there to deal with portlets that are slow to warm up. The default
config appears to multiply the portlet's configured timeout by 20 the first
5 times it executes. The key appears to be the portlet descriptor so even
if you have the same portlet (web proxy for example) published 20 times
only the first 5 renders of ANY WPP will get the extra time.

https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/portlet/rendering/PortletExecutionManager.java#L112
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/portlet/rendering/PortletExecutionManager.java#L105


On Tue, Aug 26, 2014 at 9:15 AM, Andrew Petro  wrote:

>  ​James,
>
>
>  I don't *know* and I have not yet looked at the code in response to this
> email.
>
>
>  I *suspect* that this is going to end up being about the very
> interesting case where though a portlet has missed its timeout window to
> render *for this response* there is nonetheless value in allowing it to
> complete rendering and thereby populate caches in support of subsequent
> requests and there's risk in prematurely arresting its thread.
>
>
>  Perhaps that helps.
>
>
>  Kind regards,
>
>
>  Andrew
>
>
>  --
> *From:* bounce-35984534-81063...@lists.wisc.edu <
> bounce-35984534-81063...@lists.wisc.edu> on behalf of James Wennmacher <
> jwennmac...@unicon.net>
> *Sent:* Tuesday, August 26, 2014 11:00 AM
> *To:* uportal-dev@lists.ja-sig.org
> *Cc:* Eric Dalquist
> *Subject:* [uportal-dev] PortletExecutionManager and
> extendedTimeoutExecutions
>
>  Hi  everyone,
>
> Can someone with a bit of history explain what extendedTimeoutExecutions
> in PortletExecutionManager (
> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/portlet/rendering/PortletExecutionManager.java#L814)
> is used for?  Why would a portlet run for a multiple of
> extendedTimeoutExecutions instead of just its configured timeout value?
>
> Thanks,
>
> --
> James Wennmacher - Unicon480.558.2420
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> andrew.pe...@wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] sequential IDs in layout-fragment.xml files contributing to commit noise

[Eric Dalquist]

The nodeIds don't really have anything to do with the database, though the
data model is dirty and uses that id for both a DB key and a node
identifier. The reason those nodeIds exist and can't just change is DLM.
DLM creates compound node ids that look like u2l3n4 which translates into
"nodeId 4 of layoutId 3 for userId 2". These are then used in the
modifications that users make to their layouts like "u2l3n4 moved under
u2l3n8" so these modifications reference nodes from the fragment layouts.
This is a design constraint of DLM and isn't easily removed from the
current data structure. When you export the data you need some way in user
X's layout file to reference specific nodes from template user Y's layout
file. Numeric IDs are about the easiest option to deal with. Without them
if you modify the fragment layout how will the system know that was used to
be node 8 is actually now node 9 and ensure users see the expected content.


On Fri, Jul 25, 2014 at 3:48 PM, Andrew Petro  wrote:

>  Yes, a solution that eliminates node identifiers in the import/export
> XML would be even better.  I considered being against this idea on the
> basis that that's what we should actually be working on.  Then I figured
> let's take a bit of progress where we can get it.  :)​
>
>
>  Andrew
>
>
>
>
>  --
> *From:* bounce-35785568-81063...@lists.wisc.edu <
> bounce-35785568-81063...@lists.wisc.edu> on behalf of Anthony Colebourne <
> anthony.colebou...@manchester.ac.uk>
> *Sent:* Friday, July 25, 2014 5:06 PM
> *To:* uportal-dev@lists.ja-sig.org
> *Subject:* [uportal-dev] Re: [uportal-dev] sequential IDs in
> layout-fragment.xml files contributing to commit noise
>
>   Hi,
>
>  I always thought the long term aim was to move away from serializing the
> xml across database rows?
>
>  This solution would probably work well for a long time, but if we don't
> like id's then shouldn't we try to eliminate them?
>
>  Anthony.
>
>  Sent from my HTC
>
> - Reply message -
> From: "Andrew Petro" 
> To: 
> Subject: [uportal-dev] sequential IDs in layout-fragment.xml files
> contributing to commit noise
> Date: Fri, Jul 25, 2014 22:46
>
>  +1, especially as base-10-ized by Dalquist's suggestion.
>
>  I'd only expect to see this sort of change come into master towards 4.2
> and not come into a patches branch.
>
>  I'd love to see the convention documented in a README.md co-located with
> the layout-fragment.xml files it describes, and I'd love to see an
> automated convention-adherence-check included in the product test suite and
> executed by travis-ci so as to avoid forgetting about the convention and
> regressing in the product.
>
>  PS: This reminds me of conventions about Applesoft Basic line numbers.
>
>
>
> On Fri, Jul 25, 2014 at 2:56 PM, James Wennmacher 
> wrote:
>
>>  That's a good idea.  Even simpler.  Thanks!
>>
>> James Wennmacher - Unicon480.558.2420
>>
>>  On 07/25/2014 12:36 PM, Eric Dalquist wrote:
>>
>>  I'd go even further and start at 100 instead of 10 to give you more
>> space since most layouts only have 3 levels
>>
>>
>>- 1
>>   - 100
>>  - 110
>>  - 120
>>   - 200
>>  - 210
>>  - 220
>>
>>
>>
>>
>> On Fri, Jul 25, 2014 at 10:00 AM, James Wennmacher <
>> jwennmac...@unicon.net> wrote:
>>
>>> Inspired by https://github.com/Jasig/uPortal/pull/392/files#r15399346,
>>> I'll state that I've found it annoying that we tend to have sequential #s
>>> in the IDs in the layout-fragment.xml files.  I propose we adopt a
>>> numbering convention that spaces the IDs out so changes to a file generally
>>> don't incorporate a lot of unneeded noise of renumbering IDs throughout the
>>> rest of the xml file.
>>>
>>> My proposal is:
>>>
>>> - root folder has an ID of 1
>>> - folders under root are spaced 30 apart, first one starting with ID=10
>>> to allow for 2 or 3 columns
>>> - column folders are spaced 10 apart starting with the next sequential #
>>> - portlets just take the next available sequence number under their
>>> corresponding folder
>>>
>>> so something like (contents abbreviated to show concept)
>>>
>>> 
>>>   
>>>   
>>>   
>>>   
>>> 
>>> 
>>>   
>>> 
>>> 
>>>   
>>>   

Re: [uportal-dev] sequential IDs in layout-fragment.xml files contributing to commit noise

[Eric Dalquist]

I'd go even further and start at 100 instead of 10 to give you more space
since most layouts only have 3 levels


   - 1
  - 100
 - 110
 - 120
  - 200
 - 210
 - 220




On Fri, Jul 25, 2014 at 10:00 AM, James Wennmacher 
wrote:

> Inspired by https://github.com/Jasig/uPortal/pull/392/files#r15399346,
> I'll state that I've found it annoying that we tend to have sequential #s
> in the IDs in the layout-fragment.xml files.  I propose we adopt a
> numbering convention that spaces the IDs out so changes to a file generally
> don't incorporate a lot of unneeded noise of renumbering IDs throughout the
> rest of the xml file.
>
> My proposal is:
>
> - root folder has an ID of 1
> - folders under root are spaced 30 apart, first one starting with ID=10 to
> allow for 2 or 3 columns
> - column folders are spaced 10 apart starting with the next sequential #
> - portlets just take the next available sequence number under their
> corresponding folder
>
> so something like (contents abbreviated to show concept)
>
> 
>   
>   
>   
>   
> 
> 
>   
> 
> 
>   
>   
>   
>   
>   
>   
>   
>   
> 
> 
>   
> 
>   
> 
>
> This would reduce time when making manual layout changes, and reduce the
> noise in some of the commits.  We could forgo sequential numbering
> altogether, but I think something like this would strike a reasonable
> balance to make it easier to avoid duplicating ID #s, and it would reduce
> the confusion of new adopters that wouldn't immediately realize that the
> s#s and the n#s have to be unique within the file.  This might reduce a few
> stubbed toes.
>
> Thoughts?
>
> --
> James Wennmacher - Unicon
> 480.558.2420
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Coveralls for test coverage monitoring

[Eric Dalquist]

Very cool!


On Fri, Jun 20, 2014 at 2:20 PM, Andrew Petro  wrote:

> uPortal developers,
>
> I'd like to add Coveralls test coverage monitoring to the Travis-CI
> continuous build triggered off of master commits and pull requests.
>
> https://github.com/Jasig/uPortal/pull/352
>
> This would provide a bit more transparency and feedback in between
> releases about how product unit test coverage is doing and gamifies it a
> bit by providing that bit of dopamine in Coveralls automatically commenting
> on your Pull Request to say that it increased test coverage by 0.08%, or
> whatever.
>
> Kind regards,
>
> Andrew
>
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency

[Eric Dalquist]

Oh right, running a local Nexus instance as a proxy is very valuable. Being
able to always reproduce previous builds and insulating your build process
from external failures is quite valuable.


On Fri, Jun 13, 2014 at 11:09 AM, Cris J Holdorph 
wrote:

> Well yes, that's all good and definitely encouraged for any maven project
> you are in control of.
>
> But I also think it's worth standing up an artifact repository at your own
> organization and having that 'mirror' every repository.  So that you
> actually don't go out and hit any repository directly yourself.  Instead
> you only hit your own artifact repository, and that repository in turn will
> hit the internet.  This is kind of the equivalent of fixing, at an
> organizational level the difference between a developer who has been around
> for a while and has a pretty full personal maven repo, and his builds work,
> and a new developer who has an empty personal maven repository and his
> build does not work.
>
> I'm NOT suggesting this is INSTEAD of putting things into central, but
> more of an additional thing an organization can do to help bring new
> developers on board.
>
>  Cris J H
>
>
> On 06/13/2014 11:01 AM, Andrew Petro wrote:
>
>> Cris,
>>
>> True, dependencies in Central can have dependencies on external repos.
>>
>> But that is at least discouraged:
>>
>> https://docs.sonatype.org/display/Repository/Sonatype+
>> OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.
>> CentralSyncRequirement
>>
>>
>> and in some happy future might even be enforced or at least mostly
>> respected such that getting a dependency from Central is an indication
>> that it doesn't have this problem.
>>
>> So, you're all right: getting the dependencies from Central doesn't
>> solve all problems, but the more dependencies are entirely realizable
>> via only-in-Central dependencies, the better.
>>
>> :)
>>
>> Kind regards,
>>
>> Andrew
>>
>>
>>
>> On 6/13/14, 12:54 PM, Cris J Holdorph wrote:
>>
>>> It's not just a simple matter of putting YOUR dependencies into
>>> central and not putting repositories into YOUR pom files.  With
>>> transitive dependencies, ESPECIALLY specific versions, this can happen
>>> through a dependency that came in from a transitive dependency.
>>>
>>> Example:
>>>
>>>   I specify I want to use "Foo" version "1.1".  At the time of my
>>> using it, it is in central, so I don't think anything more of it.
>>>
>>>   I do not notice, but Foo version 1.1, uses "bar" 2.0.
>>>
>>>   Bar 2.0 uses crud 3.0.
>>>
>>>   crud 3.0 specifies a respository in it's pom.xml file to go get
>>> "blah" version 1.2.3 from some weird repo.
>>>
>>>   Final result, my project is now dependent on some weird repo for
>>> version 1.2.3 of "blah".
>>>
>>>  Cris J H
>>>
>>> On 06/13/2014 09:57 AM, Eric Dalquist wrote:
>>>
>>>> This highlights the very real danger of adding extra repositories. It
>>>> may be more work up front to get all the deps you need into central but
>>>> it is very much worth it long term to avoid this sort of dependency hell
>>>> pain.
>>>>
>>>>
>>>> On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph >>> <mailto:holdo...@unicon.net>> wrote:
>>>>
>>>> This is probably not your problem, but I thought I would share some
>>>> recent experience with maven, repositories and dependency debugging.
>>>>
>>>> I was trying to set up a local artifact repository to do mirroring
>>>> of maven dependencies.  This is useful for dependencies that are not
>>>> in central, that might disappear.
>>>>
>>>> Anyway, to fully test my 'mirror' I started with an empty repository
>>>> and would try to build my projects.  I discovered a really
>>>> interesting situation.  Take a look at these two pom files from two
>>>> different maven repos.
>>>>
>>>> http://repo1.maven.org/maven2/__commons-dbcp/commons-dbcp/1.
>>>> 2.__2/commons-dbcp-1.2.2.pom
>>>>
>>>> <http://repo1.maven.org/maven2/commons-dbcp/commons-
>>>> dbcp/1.2.2/commons-dbcp-1.2.2.pom>
>>>>
>>>> http://jcenter.bintray.com/__commons-dbcp

Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency

[Eric Dalquist]

This highlights the very real danger of adding extra repositories. It may
be more work up front to get all the deps you need into central but it is
very much worth it long term to avoid this sort of dependency hell pain.


On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph 
wrote:

> This is probably not your problem, but I thought I would share some recent
> experience with maven, repositories and dependency debugging.
>
> I was trying to set up a local artifact repository to do mirroring of
> maven dependencies.  This is useful for dependencies that are not in
> central, that might disappear.
>
> Anyway, to fully test my 'mirror' I started with an empty repository and
> would try to build my projects.  I discovered a really interesting
> situation.  Take a look at these two pom files from two different maven
> repos.
>
> http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2.
> 2/commons-dbcp-1.2.2.pom
> http://jcenter.bintray.com/commons-dbcp/commons-dbcp/1.2.
> 2/#commons-dbcp-1.2.2.pom
>
> Notice how the second one is different then the first.  I suspect the
> second one must have been autogenerated.  In any case though, it causes a
> really big problem if that is where the dependency gets pulled down from.
>
> So, my overall point is, when you're starting from an empty maven repo,
> you can definitely get really weird and odd things happening.  It can be
> really hard to debug.  (in the above problem, it 'manifested' as a junit
> test failure about a missing class!)
>
>  Cris J H
>
> On 06/13/2014 09:37 AM, Drew Wills wrote:
>
>> Folks,
>>
>> I'm encountering a new Maven dependency issue with echcache.  It seems
>> to happen always (small sample size) on a machine that doesn't have
>> these artifacts cached in the local repo.
>>
>> These items do seem to be in m2 central.  I'm not sure how Maven is
>> getting the 'null:ehcache-web:jar:null' (see below) but I suspect it's a
>> factor in the issue.
>>
>> drew
>>
>> ---
>>
>> BUILD FAILED
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:635: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1437: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1372: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1315: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1318: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1375: The following
>> error occurred while executing this line:
>> /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1227: Unable to
>> resolve artifact: Unable to get dependency information: Unable to read
>> the metadata file for artifact 'net.sf.ehcache:ehcache-web:jar': Cannot
>> find parent: net.sf.ehcache:ehcache-web-parent for project:
>> null:ehcache-web:jar:null for project null:ehcache-web:jar:null
>>net.sf.ehcache:ehcache-web:jar:2.0.4
>>
>> from the specified remote repositories:
>>central (http://repo1.maven.org/maven2),
>>sonatype-nexus-snapshots
>> (https://oss.sonatype.org/content/repositories/snapshots),
>>apache-snapshots (http://repository.apache.org/snapshots)
>>
>> Path to dependency:
>>  1) org.jasig.portal:uportal-war:war:4.1.0-SNAPSHOT
>>  2) org.jasig.resourceserver:resource-server-utils:jar:1.0.38
>>
>>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] NaturalIdCache annotation

[Eric Dalquist]

So this was a partially realized feature in Hibernate that I helped them
complete a few years ago. To really understand it you need to first have a
decent grasp of the multi-layer caching system that hibernate uses. I'll
like a bunch of blogs that I would HIGHLY recommend you read but I'll also
give a short summary.

http://www.javalobby.org/java/forums/t48846.html
http://apmblog.compuware.com/2009/02/16/understanding-caching-in-hibernate-part-two-the-query-cache/
http://learningviacode.blogspot.com/2013/12/update-timestamps-cache-in-action.html
http://tech.puredanger.com/2009/07/10/hibernate-query-cache/

The last one is the most relevant to the problem natural id caching solves,
in that it asks the question "Hibernate query cache considered harmful?"

A few terms:

   - *entity* - a hibernate managed persistent object
   - *id *- the primary key of the object. If you're following good data
   design principals this is an auto-generated number with absolutely zero
   business meaning. It should be treated as a completely opaque identifier
   and EVERY entity stored in the DB should have one.
   - *natural id* - the field or combination of fields that make the object
   unique in your application. For example in uPortal a portlet definition has
   a fname and a user has a username. These are immutable, non-nullable,
   unique fields for those objects.


So the short summary of caching layers, this isn't going to be 100%
accurate as I haven't looked at this stuff in a while.

   - *Session Cache (first level) *- Bound to the session (in uPortal this
   is thread/request scoped) caches full constructed entities (and all their
   references) that have been "loaded" into the session by primary id.
   - *Second Level Cache* - This is globally shared (lives in ehcache) and
   caches objects by primary id, hibernate does a bunch of work to keep the
   data in here from getting stale and this is what the jgroups invalidation
   stuff in uPortal helps with by saying "remove entry 12345 from cache 'foo'"
   when that entry is modified. Note that the data cached in here is in an
   intermediate form to deal with referential freshness. If EntityA contains a
   reference to EntityB the cached version of EntityA just contains the id of
   EntityB so that when the data is loaded the freshest version of EntityB is
   used.
   - *Query Cache* - This is a global cache of queries keyed off of the
   query string. For example "select person from Person where person.firstName
   = 'Eric'" would be the key and hibernate caches the RAW SQL RESULT SET
   - *Update Timestamp Cache* - Since the query cache is not keyed off of
   any sort of id hibernate has to be REALLY careful that it doesn't use it
   and get stale data. To that end this cache tracks the timestamp of the last
   time each table it manages was modified. When hibernate gets a result set
   from the query cache it checks to see if it is older than the last
   modification and if it is the cached result set is ignored as hibernate
   cannot be sure if the data it contains is still fresh.
   - *Natural ID Cache* - A very simple cache that maps the natural id of
   the entity to the id of the entity. This cache is never invalidated (your
   natural id never changes right?) and provides very fast lookup from natural
   id -> id -> entity without having to worry about the Update Timestamp Cache.


So to help show how this all works lets talk through a few query/load
scenarios. Like any good software these layer on each other.

   - *load by primary id* - this is nice and easy. You say
   hibernate.load(PortletDefinition.class, 12345); Hibernate looks in the
   Session Cache first for a PortletDefinition with ID 12345. Then it looks in
   the Second Level Cache for a PortletDefinition with ID 12345. Then it does
   a database query for a portlet definition with that primary key value. This
   is the fastest, most efficient way to get at a hibernate managed entity and
   why much of uPortal just passes around primary IDs and ALWAYS goes back to
   the DAO every time the actual object is needed. At worst you get 1 fully
   indexed SQL query for the entire duration of your http request handling
   which then primes the session cache, second level cache and the natural id
   cache. Realistically you only go down to the Second Level Cache and every
   request after that for the rest of each request just hits the session cache
   which doesn't even have to be thread safe so is REALLY fast.
   - *load by natural id* - this is the second best way to load an entity.
   Hibernate looks in the natural id cache for the mapping to the id, if it
   finds it a simple load(id) can be done. If there is a miss hibernate does a
   *much* simpler SQL query to get the id for the natural id then does a
   load(id). At worst here you get 2 fully indexed SQL queries and generally
   the same cache behavior as load by primary key
   - *query* - These are VERY hard to cache for entities where the 

Re: [uportal-dev] maven dependency failure (was Re: [uportal-user] Another day... another dependency build failure)

[Eric Dalquist]

FYI these repos are places deps get pulled from, the distributionManagement
block defines where stuff gets pushed to. That said released code versions
of uPortal should never depend on -SNAPSHOTs and so should never hit those
repos. Non-snapshot repositories should be avoided at all costs in favor of
getting 100% of dependencies from central.

https://maven.apache.org/pom.html


On Wed, Apr 2, 2014 at 10:57 AM, James Wennmacher wrote:

> I guess I should have checked before I posted. :-)
>
> Any thoughts on the 2nd part (do we need to publish snapshots)?
>
> James Wennmacher - Unicon
> 480.558.2420
>
> On 04/02/2014 10:15 AM, Tim Levett wrote:
>
>> Going to http://repository.apache.org/snapshots via your browser you
>> will see they don't redirect to https so we should leave it.
>>
>>
>> Even further if you try going to https it redirects you to http, so we
>> could run into the same problem if that were the case.
>>
>>
>> - Tim
>>
>> On 04-02-14, James Wennmacher  wrote:
>>
>>>
>>>
>>> Hi Tim. I noticed http was changed to https on sonatype, but not apache.
>>> Should it be for both?
>>>
>>> Also does anyone know why the snapshot repositories are listed in the
>>> main pom.xml? Is it required for some process such as bamboo builds or
>>> publishing artifacts to maven central or something? I can't think of why
>>> uPortal would need to have snapshots published since we typically do not
>>> rely on shared snapshot builds.
>>>
>>> I do see that snapshots were built periodically (
>>> https://oss.sonatype.org/content/repositories/snapshots/org/jasig/)
>>> including 4.1.0-snapshot fairly recently ( https://oss.sonatype.org/
>>> content/repositories/snapshots/org/jasig/portal/uportal-platform-api/).
>>> I suspect it is from the bamboo deploy snapshot process; e.g.
>>> https://developer.jasig.org/bamboo/browse/UP-TRUNKMVNDEPLOY. Is this
>>> deploy snapshot process needed for releasing uPortal?
>>>
>>>
>>> James Wennmacher - Unicon 480.558.2420
>>> On 04/02/2014 07:05 AM, Tim Levett wrote:
>>>
>>>
>>>  I can confirm that this does fix the problem you were experiencing.
 There is an issue with maven not following redirects correctly. By changing
 from http to https it avoids the redirect.

 - Tim Levett

 On 04/01/2014 05:54 PM, Drew Wills wrote:

  Tim et al.,
>
> I think this commit fixes what you reported and many of us started
> experiencing...
>
> - https://github.com/Jasig/uPortal/commit/
> 5e197f3712c987294873a2d65ae9a894142f4b7d
>
> drew
>
> On 04/01/2014 02:02 PM, James Wennmacher wrote:
>
>  Tim.? This is a systemic issue (it affected Drew and me anyway).? To
>> get
>> around it I changed the snapshots property to false for the sonatype
>> and
>> apache repository entries in the main pom.xml.?
>> https://github.com/Jasig/uPortal/blob/master/pom.xml#L57
>>
>> Not sure why these repositories are present. I'll take that one to the
>> uportal-dev list.
>>
>> James Wennmacher - Unicon
>> 480.558.2420
>>
>> On 04/01/2014 01:45 PM, Drew Wills wrote:
>>
>>  Tim,
>>>
>>> First thing I would try is...
>>>
>>> ? $mvn clean install
>>>
>>> and then try your ant command again.
>>>
>>> You may simply be stuck in one of the dark corners of the ant/maven
>>> fusion.
>>>
>>> drew
>>>
>>> On 04/01/2014 01:11 PM, Tim Raymond wrote:
>>>
>>>  All I did was point to tomcat 7.0.52 folder and clean deploy-ear?

 Tim Raymond
 Director, Central Applications
 Instructional and Information Technologies
 California State Polytechnic University, Pomona
 Phone: 909.869.6851
 Cell: 909.260.3200
 Fax: 909.979.6406

 PGP Public Key:
 https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=
 0x2FDBD1EADDC19329


 ??? --

 You are currently subscribed to uportal-u...@lists.ja-sig.org <
 uportal-u...@lists.ja-sig.org> as:
 awi...@unicon.net 
 To unsubscribe, change settings or access archives, see
 http://www.ja-sig.org/wiki/display/JSG/uportal-user


  --- You are currently subscribed to uportal-u...@lists.jasig.org <
>>> uportal-u...@lists.jasig.org> as:
>>> jwennmac...@unicon.net 
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>>>
>>>  --
>>
>> You are currently subscribed to uportal-u...@lists.ja-sig.org <
>> uportal-u...@lists.ja-sig.org> as: awi...@unicon.net <
>> awi...@unicon.net>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>>
>>
>>  --- You are currently subscribed to uportal-u...@lists.jasig.org <
> uportal-u...@lists.jasig.org> as: lev...@wisc

Re: [uportal-dev] DLM saveUserLayout() cache invalidation?

[Eric Dalquist]

Yeah, good invalidation cache (what uP does most everywhere) practice is to
remove the cached data on write or delete and cache on read.


On Tue, Mar 4, 2014 at 7:15 AM, Andrew Petro  wrote:

>  Ah.  The layout cache is invalidated at DistributedLayoutManager instance
> init, so long as afterPropertiesSet() is called:
>
> http://goo.gl/2CMW7t
>
> and afterPropertiesSet() will be called, since it's an InitializingBean
> and DLM is being instantiated by Spring:
>
> http://goo.gl/UPdqTD
>
>
> There goes that hypothesis.  Thanks.
>
> Eric, you still figure saveLayout() should be invalidating the cache, even
> though that's not my particular ghost in the machine?
>
> Andrew
>
>
>
>
> On 3/4/14, 8:57 AM, Eric Dalquist wrote:
>
> That should be invalidating the cache but the layout should also be
> removed from the cache at both login and logout as well.
>
>
> On Tue, Mar 4, 2014 at 5:17 AM, Andrew Petro  wrote:
>
>> uPortal developers,
>>
>> Do you suppose that DLM saveUserLayout()
>>
>> http://goo.gl/kRxyqz
>>
>> ought to be invalidating the layout cache so that the saved layout is
>> read back from the layout store on next access?
>>
>> I suspect yes.
>>
>> I think I'm seeing goofiness where user changes to received DLM fragments
>> (as in, deleting them from the personal layout) take immediate effect and
>> persist to the database, but *don't* reflect on logout and log-back-in
>> without Tomcat restart.  I suspect this is because the in-user-session
>> cached copy is being properly updated and the changes are being persisted
>> to the database, but they're not being pushed into that cache.  I hope
>> simply invalidating the cache on save is going to be a reasonable solution
>> (rather than heroically injecting just the right new data into the cache
>> without round-tripping from the layout store).
>>
>> I hope to have a cogent explanation and a pull request today. But hey, if
>> you already know I'm going in the wrong direction on this, do a fellow a
>> solid and let me know? :)
>>
>> Credit due to Tim Levett for the insight that the ghost in the machine
>> I'm seeing might be due to this particular cache.
>>
>> Andrew
>>
>>
>>
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> eric.ape...@dalquist.org
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>
>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> ape...@wisc.edu
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] DLM saveUserLayout() cache invalidation?

[Eric Dalquist]

That should be invalidating the cache but the layout should also be removed
from the cache at both login and logout as well.


On Tue, Mar 4, 2014 at 5:17 AM, Andrew Petro  wrote:

> uPortal developers,
>
> Do you suppose that DLM saveUserLayout()
>
> http://goo.gl/kRxyqz
>
> ought to be invalidating the layout cache so that the saved layout is read
> back from the layout store on next access?
>
> I suspect yes.
>
> I think I'm seeing goofiness where user changes to received DLM fragments
> (as in, deleting them from the personal layout) take immediate effect and
> persist to the database, but *don't* reflect on logout and log-back-in
> without Tomcat restart.  I suspect this is because the in-user-session
> cached copy is being properly updated and the changes are being persisted
> to the database, but they're not being pushed into that cache.  I hope
> simply invalidating the cache on save is going to be a reasonable solution
> (rather than heroically injecting just the right new data into the cache
> without round-tripping from the layout store).
>
> I hope to have a cogent explanation and a pull request today. But hey, if
> you already know I'm going in the wrong direction on this, do a fellow a
> solid and let me know? :)
>
> Credit due to Tim Levett for the insight that the ghost in the machine I'm
> seeing might be due to this particular cache.
>
> Andrew
>
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] EhCache and jgroups question

[Eric Dalquist]

Seems reasonable to me. I don't think there is anything inherently bad with
synchronous replication, you just need to have a good reason like you have
here to add in the extra cost of sending the replication data on cache put.


On Fri, Feb 7, 2014 at 12:24 PM, James Wennmacher wrote:

>  As an update to the group, one minor difference with what Eric suggested
> I thought I'd mention to get group feedback on (and to share general
> knowledge) is that for the CAS Clearpass Proxy-Granting Tickets (PGTs)
> replication, I'm setting replicateAsynchronously=false to force synchronous
> replication which is really just an immediate channel.send() and doesn't
> wait for the peer acknowledgement, see
> http://jira.terracotta.org/jira/browse/EHC-874).  I don't think this is a
> significant performance impact and no chance of deadlock, and is to reduce
> the chance that the uPortal server the user is on attempts to obtain the
> PGT before it has been replicated to it.
>
> I'm adding commented-out configuration and wiki documentation about
> clustered CAS Clearpass so this should be much easier for anyone who wants
> to do it in the future.
>
> As a background for those interested (and I'll add this to the wiki
> documentation), the way the CAS Clearpass works with uPortal is:
>
> 1. When uPortal receives the service ticket in the URL from the CAS
> redirect after the user enters their credentials in CAS, uPortal does the
> service ticket validation with CAS to get the userId and verify
> authentication is good.  uPortal always requests the clearpass PGT in the
> service ticket validation.
>
> 2. If enabled on CAS, CAS will not respond to uPortal until CAS initiates
> sending a PGT to uPortal and getting a response (unsure what happens if
> there is a failure).  At that point, one of the uPortal servers has the PGT
> so CAS will reply to the service ticket validation.
>
> 3. uPortal at that point needs access to the PGT if it needs to provide
> the user's password to a portlet.
>
> I set replicateAsynchronously=false so the uPortal server that CAS has
> invoked with the PGT will at least fire off the replication request.  The
> expectation and hope is that by the time CAS receives the PGT POST response
> and responds back to the original uPortal server for the service ticket
> validation, the PGT replication packet will be received and processed by
> peer uPortal nodes (or at least the one the user has logged into) and the
> PGT will be available in ehcache when the uPortal server the user has
> logged into receives the service ticket response from CAS.
>
> I hope all this makes sense.  If anyone sees a problem with setting
> replicateAsynchronously=false let me know.
>
> Thanks!
>
> James Wennmacher - Unicon480.558.2420
>
> On 02/07/2014 11:00 AM, Eric Dalquist wrote:
>
> That is correct. You can set those ports if you need to, I believe we do
> at UW to deal with TCP firewalls but they are not required in most cases.
>
>  One thing to note is the important data in that table is stored in the
> BLOBs. jGroups only supports using Java serialization to store their
> PhysicalAddress class. I added the human-readable toString output columns
> so it would be easier to debug.
>
>  For debugging/monitoring all of this take a look at JMX (jConsole) data.
> The jGroups instance registers itself and exposes a ton of useful data via
> JMX. You can see who all the members of a current view are, who is the
> coordinator, traffic stats, etc.
>
>
>  There is also some vestigial code in
> https://github.com/Jasig/uPortal/tree/8de4d5030be8dbd219b73a28037185e1d2df661d/uportal-war/src/main/java/org/jasig/portal/jgroups/authwhich
>  I was trying to use to get group auth and encryption "just working"
> as well but I never had much luck with it. If that could be reliably
> enabled then the coordinator node would write out a random auth/crypto
> token to the database which the other nodes would then use to auth into the
> group.
>
>
> On Fri, Feb 7, 2014 at 9:47 AM, James Wennmacher 
> wrote:
>
>>  To verify, we typically don't need to set any of the jgroups property
>> values in portlet.properties for a clustered environment... in particular
>> #uPortal.cacheManager.jgroups.fd_sock.start_port=
>> #uPortal.cacheManager.jgroups.tcp.bind_port=
>>
>> jGroups will by default pick a random port and communicate the port that
>> node chose to the other nodes in the cluster so the nodes can communicate
>> (replicate cache invalidations or cache data, in addition to discovery of
>> new/removed nodes)?  I assume that's what is stored in the database
>> (UP_JGROUPS_PING table, PHYSICAL_ADDRESS column - holds

Re: [uportal-dev] EhCache and jgroups question

[Eric Dalquist]

That is correct. You can set those ports if you need to, I believe we do at
UW to deal with TCP firewalls but they are not required in most cases.

One thing to note is the important data in that table is stored in the
BLOBs. jGroups only supports using Java serialization to store their
PhysicalAddress class. I added the human-readable toString output columns
so it would be easier to debug.

For debugging/monitoring all of this take a look at JMX (jConsole) data.
The jGroups instance registers itself and exposes a ton of useful data via
JMX. You can see who all the members of a current view are, who is the
coordinator, traffic stats, etc.


There is also some vestigial code in
https://github.com/Jasig/uPortal/tree/8de4d5030be8dbd219b73a28037185e1d2df661d/uportal-war/src/main/java/org/jasig/portal/jgroups/authwhich
I was trying to use to get group auth and encryption "just working"
as well but I never had much luck with it. If that could be reliably
enabled then the coordinator node would write out a random auth/crypto
token to the database which the other nodes would then use to auth into the
group.


On Fri, Feb 7, 2014 at 9:47 AM, James Wennmacher wrote:

>  To verify, we typically don't need to set any of the jgroups property
> values in portlet.properties for a clustered environment... in particular
> #uPortal.cacheManager.jgroups.fd_sock.start_port=
> #uPortal.cacheManager.jgroups.tcp.bind_port=
>
> jGroups will by default pick a random port and communicate the port that
> node chose to the other nodes in the cluster so the nodes can communicate
> (replicate cache invalidations or cache data, in addition to discovery of
> new/removed nodes)?  I assume that's what is stored in the database
> (UP_JGROUPS_PING table, PHYSICAL_ADDRESS column - holds a value like
> fe80:0:0:0:a288:b4ff:febe:ed0%3:43362).
>
> Thanks,
>
> James Wennmacher - Unicon480.558.2420
>
> On 02/05/2014 06:30 PM, Eric Dalquist wrote:
>
> +uportal-dev so everyone sees the background on this.
>
>
>  UDP multicast is great ... in theory. In practice across the complex
> networks in most data centers it is a nightmare. At UW and other places I
> tested we had constant problems with peer discovery, message routing and
> other issues.
>
>  As you said TCP is a pain because you have the discovery issue but
> uPortal doesn't have this discovery issue. One of the neat things with
> jGroups is the ability to write your own "protocol" handlers. uPortal
> provides a custom implementation of 
> PING<https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/properties/jgroups.xml?source=c#L64>,
> the jGroups discovery protocol via 
> DAO_PING<https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/jgroups/protocols/DAO_PING.java>.
> This handler uses the already shared uPortal database to coordinate node
> discovery.
>
>  When a uPortal instance starts up (which starts ehcache, which starts
> jgroups) and instance of DAO_PING is created and start() is called. This
> schedules a Timer that runs every 60 seconds (configurable in jgroups.xml)
> that writes out the JVM's current physical address (as determined by
> jGroups, again configurable if it auto-discovers the wrong one) to the
> database via the 
> JdbcPingDao<https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/jgroups/protocols/JdbcPingDao.java>
> .
>
>  The next thing jGroups needs to do after start is discover peers, to do
> this it calls fetchClusterMembers on DAO_PING which uses the JdbcPingDao to
> get a list of all of the physical address that have been written to that
> table. jGroups then uses that list to join the cluster.
>
>  The last part of the process is what the coordinator node (there is
> always a coordinator that is elected in a jGroups cluster) does. Every time
> the view (what jgroups calls the list of currently active cluster members)
> changes the coordinator purges the database by removing all rows that do
> not match known members. This handles pruning addresses of old/dead
> instances.
>
>  This system has worked very well and effectively anyone running uPortal
> 4.0.8 or later very likely has a coherent jGroups cluster doing ehcache
> invalidation with zero extra work: https://issues.jasig.org/browse/UP-3607
>
>  You can take a look at which caches uPortal uses jGroups for and how
> they are configured:
> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/properties/ehcache.xml
>
>  Note that uPortal does not do true replication anywhere. All of the data
> cached in uPortal can be retrieved from the database or recalculated very
> quickly so the caches are configured to do invalidation based re

Re: [uportal-dev] proposed: Tim Vertein for uPortal committership

[Eric Dalquist]

+1


On Fri, Feb 7, 2014 at 9:21 AM, Timothy Vertein  wrote:

> Thanks Andrew,
>
> As mentioned, I joined the UW team a while ago.  I've been quite active in
> Madison's private uPortal fork, with the marketplace feature we talked
> about at camp, being my most recent project. I've recently added the
> marketplace epic under the jasig jira: https://issues.jasig.org/
> browse/UP-3955.
>
> As mentioned, by public github activity: https://github.com/vertein?
> tab=activity
>
> Thanks,
>
> Tim Vertein
> UW-Madison
> 608.890.1423
>
>
> On 02/07/2014 11:12 AM, Andrew Petro wrote:
>
>> Proposed:
>>   Add Tim Vertein as uPortal committer.
>>
>>   Tim has joined the UW-Madison My UW Madison (uPortal) infrastructure
>> team and was at the Apereo Camp 2014 meeting other uPortal project
>> participants and sharing some of his work. Recently Tim has been working
>> particularly on the new Marketplace portlet and more generally on the
>> UW-Madison portal redesign.
>>
>> https://wiki.jasig.org/display/UPC/Marketplace
>>
>> Proposing that he be granted uPortal project committership so as to be
>> more able to directly participate in uPortal development.
>>
>> GitHub profile:
>> https://github.com/vertein
>>
>> Tim, care to reply further introducing yourself?
>>
>> Andrew
>>
>>
>>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re:[uportal-dev] EhCache and jgroups question

[Eric Dalquist]

+uportal-dev so everyone sees the background on this.


UDP multicast is great ... in theory. In practice across the complex
networks in most data centers it is a nightmare. At UW and other places I
tested we had constant problems with peer discovery, message routing and
other issues.

As you said TCP is a pain because you have the discovery issue but uPortal
doesn't have this discovery issue. One of the neat things with jGroups is
the ability to write your own "protocol" handlers. uPortal provides a
custom implementation of
PING,
the jGroups discovery protocol via
DAO_PING.
This handler uses the already shared uPortal database to coordinate node
discovery.

When a uPortal instance starts up (which starts ehcache, which starts
jgroups) and instance of DAO_PING is created and start() is called. This
schedules a Timer that runs every 60 seconds (configurable in jgroups.xml)
that writes out the JVM's current physical address (as determined by
jGroups, again configurable if it auto-discovers the wrong one) to the
database via the
JdbcPingDao
.

The next thing jGroups needs to do after start is discover peers, to do
this it calls fetchClusterMembers on DAO_PING which uses the JdbcPingDao to
get a list of all of the physical address that have been written to that
table. jGroups then uses that list to join the cluster.

The last part of the process is what the coordinator node (there is always
a coordinator that is elected in a jGroups cluster) does. Every time the
view (what jgroups calls the list of currently active cluster members)
changes the coordinator purges the database by removing all rows that do
not match known members. This handles pruning addresses of old/dead
instances.

This system has worked very well and effectively anyone running uPortal
4.0.8 or later very likely has a coherent jGroups cluster doing ehcache
invalidation with zero extra work: https://issues.jasig.org/browse/UP-3607

You can take a look at which caches uPortal uses jGroups for and how they
are configured:
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/properties/ehcache.xml

Note that uPortal does not do true replication anywhere. All of the data
cached in uPortal can be retrieved from the database or recalculated very
quickly so the caches are configured to do invalidation based replication
where when a key in a cache is replaced with a new value or deleted a
message is sent to the cluster that results in the other caches removing
the key so that the value is reloaded the next time it is needed.

As for overhead, the recommended approach is to have the
replicateAsynchronously flag set to true in which case ehcache batches up
replication messages and sends them in the background (very quickly but
still in batches).



For what you need in CAS tickets which I believe are ephemeral you would
need to set replicatePuts=true and replicateUpdatesViaCopy=true to copy the
actual data between nodes.


As for performance, you configure replication behavior on a cache by cache
basis. There are a bunch of caches in uPortal that are not replicated at
all either because the data doesn't change or is local to the instance.



Something that might be worth investigating is a way to share the jGroups
Channel that gets created for ehcache in uPortal across all of the portlets
in Tomcat. I had wanted to look into that but never had time to. I doubt it
is a simple change but could be VERY valuable in providing cache
consistency for portlets as well as uPortal. The general concept I was
thinking of was to do the following (large chunk of work)

   - Have uPortal initialize jGroups at start time (see the ehcache
   
JGroupsCacheManagerPeerProvider
   )
   - Have uPortal expose the JChannel as an attribute in the PortletContext
   each portlet gets access to at init time
  - You probably need a tomcat context scoped wrapper around it that
  hides each context's messages from each other context
   - Write a custom Ehcache replication service (that likely extends the
   existing jgroups replication service) which has:
  - A spring listener that gets the PortletContext injected in, gets
  the jGroups channel and stores it in some context-global location
  - A version of jGroupsCacheManagerPeerProvider that uses the jGroups
  channel from the global location
  - This should fail-nice so that if uPortal doesn't provide a jChannel
  things just don't get replicated


Hope that i

Re: [uportal-dev] Travis-CI noise?

[Eric Dalquist]

+1 thanks for doing this Andrew


On Mon, Feb 3, 2014 at 1:05 PM, Andrew Petro  wrote:

> uPortal developers,
>
> I'm experimenting with implementing Travis-CI continuous integration of
> the uPortal build.
>
> It's got some default notification email triggers.
>
> http://docs.travis-ci.com/user/notifications/#Notifications
>
> The defaults look awfully reasonable (notifies only the committer (and
> author) of a commit, and then only for commits that fails to build or is
> the commit that un-failed the build.).
>
> So, that feels right, but if these notification emails turn out to be
> annoying, please holler and they are supposed to be tweakable.
>
> In the meantime, patience while this build configuration shakes out is
> appreciated. :)
>
> Thanks,
>
> Andrew
>
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Eric Dalquist]

That was the goal when I did it :)

Also there is fun stuff to get into config from portlet manager, some need
FWK apis that provide a JSP taglib that lets one portlet render another
portlet.
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/webapp/WEB-INF/flows/edit-portlet/configMode.jsp?source=cc#L53


On Fri, Jan 24, 2014 at 9:09 AM, Drew Wills  wrote:

> That's a great answer!
>
> It sounds like it was done originally in a sound, future-proof way.
>
> drew
>
>
> On 01/24/2014 10:06 AM, Eric Dalquist wrote:
>
>> So CONFIG is baked into various framework bits so that the portal knows
>> how to make the portlet APIs behave when in this mode. As a protection I
>> believe there is a permission check associated with the ability to
>> render a portlet in CONFIG.
>>
>> Give it a try, make CMS render a CONFIG portlet url, click on it and see
>> what happens :)
>>
>>
>> On Fri, Jan 24, 2014 at 9:00 AM, James Wennmacher
>> mailto:jwennmac...@unicon.net>> wrote:
>>
>> More broadly, is this a case of delegated admin (e.g. for
>> tenant-based delegated admin use case) that should be accessible for
>> these tenant-contained sets of portlets?
>>
>> Do the delegated admins need to do only the rich config, full
>> portlet configuration (add/remove porlets), or limited portlet admin
>> (some but not all the properties configured by the Portlet Manager)?
>>
>> James Wennmacher - Unicon
>> 480.558.2420 
>>
>>
>>
>> On 01/24/2014 09:50 AM, Drew Wills wrote:
>>
>> Thanks for chiming in.
>>
>> On 01/24/2014 09:44 AM, Eric Dalquist wrote:
>>
>> Normal users can never use CONFIG. It is only usable by
>> portal admins
>> and requires specific permissions to even work for a user.
>> Beyond that,
>> a portlet might be able to just set CONFIG as the mode on a
>> URL. I never
>> actually tried that.
>>
>>
>> Within the Portlet Manager, I know that the things that get
>> entered/created in CONFIG mode can become a part of the
>> portlet-definition record -- e.g. text entered in the WYSIWYG
>> editor for SimpleCMS.
>>
>> That integration would still need to work.  This example is
>> actually one of the more compelling imho -- allow privilaged
>> users to edit the content of a SimpleCMS portlet "in situ"
>> (without going through the Portlet Manager).
>>
>> drew
>>
>>
>>
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org
>> <mailto:uportal-dev@lists.ja-sig.org> as: eric.ape...@dalquist.org
>> <mailto:eric.ape...@dalquist.org>
>>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
>> <http://www.ja-sig.org/wiki/display/JSG/uportal-dev>
>>
>>
>> --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> awi...@unicon.net
>>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Eric Dalquist]

So CONFIG is baked into various framework bits so that the portal knows how
to make the portlet APIs behave when in this mode. As a protection I
believe there is a permission check associated with the ability to render a
portlet in CONFIG.

Give it a try, make CMS render a CONFIG portlet url, click on it and see
what happens :)


On Fri, Jan 24, 2014 at 9:00 AM, James Wennmacher wrote:

> More broadly, is this a case of delegated admin (e.g. for tenant-based
> delegated admin use case) that should be accessible for these
> tenant-contained sets of portlets?
>
> Do the delegated admins need to do only the rich config, full portlet
> configuration (add/remove porlets), or limited portlet admin (some but not
> all the properties configured by the Portlet Manager)?
>
> James Wennmacher - Unicon
> 480.558.2420
>
>
> On 01/24/2014 09:50 AM, Drew Wills wrote:
>
>> Thanks for chiming in.
>>
>> On 01/24/2014 09:44 AM, Eric Dalquist wrote:
>>
>>> Normal users can never use CONFIG. It is only usable by portal admins
>>> and requires specific permissions to even work for a user. Beyond that,
>>> a portlet might be able to just set CONFIG as the mode on a URL. I never
>>> actually tried that.
>>>
>>
>> Within the Portlet Manager, I know that the things that get
>> entered/created in CONFIG mode can become a part of the portlet-definition
>> record -- e.g. text entered in the WYSIWYG editor for SimpleCMS.
>>
>> That integration would still need to work.  This example is actually one
>> of the more compelling imho -- allow privilaged users to edit the content
>> of a SimpleCMS portlet "in situ" (without going through the Portlet
>> Manager).
>>
>> drew
>>
>>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Eric Dalquist]

Normal users can never use CONFIG. It is only usable by portal admins and
requires specific permissions to even work for a user. Beyond that, a
portlet might be able to just set CONFIG as the mode on a URL. I never
actually tried that.


On Fri, Jan 24, 2014 at 8:34 AM, Drew Wills  wrote:

> Hey folks,
>
> Is there anyone on the list who has a good sense of how hard it would be
> to enter CONFIG mode directly from the portlet itself?  (Not via the
> Portlet Manager)
>
> drew
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Potential JDK Upgrade Breakage

[Eric Dalquist]

Cool, I didn't remember uPortal using that specific part of Guava but I
figured it would be good to warn people when I saw the notification go by


On Tue, Jan 21, 2014 at 6:07 AM, Aaron Grant  wrote:

> Hi Eric,
>
> We are running the OpenJDK 1.7 (1.7.0_51) release and aren't seeing any
> apparent issues yet, we upgraded last Wednesday.
>
> java-1.7.0-openjdk.x86_64 1:1.7.0.51-2.4.4.1.el6_5
> @rhel-x86_64-server-6
> java-1.7.0-openjdk-devel.x86_64   1:1.7.0.51-2.4.4.1.el6_5
> @rhel-x86_64-server-6
>
> Aaron
>
>
> On Mon, Jan 20, 2014 at 10:57 PM, Eric Dalquist 
> wrote:
>
>> Someone might want to try uPortal out on the latest JDK and make sure the
>> use of Guava doesn't trigger this bug:
>> https://code.google.com/p/guava-libraries/issues/detail?id=1635
>>
>> --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> asgr...@oakland.edu
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>
>
>
> --
> Aaron Grant
> Senior Applications Architect
> Oakland University - UTS <http://oakland.edu/uts>
>
>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Potential JDK Upgrade Breakage

[Eric Dalquist]

Someone might want to try uPortal out on the latest JDK and make sure the
use of Guava doesn't trigger this bug:
https://code.google.com/p/guava-libraries/issues/detail?id=1635

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Fwd: [jira] [Created] (PLUTO-624) Pluto does not support Runtime option javax.portlet.actionScopedRequestAttributes

[Eric Dalquist]

So there are all of these request & response context objects that the Pluto
SPI uses as a way for the portal to have hooks into how the various types
of request and response objects in the portlet spec behave. They all live
here:
https://github.com/Jasig/uPortal/tree/master/uportal-war/src/main/java/org/jasig/portal/portlet/container

One of the things these deal with is request attributes. To support this
feature you'd need to add some sort of service in uPortal for storing
action->render request attributes across request boundaries and deal with
invalidating them eventually and such. Then you'd wire that service into
one or more of those context objects, intercepting the appropriate logic
that deals with request and response attributes.

Once all that is done you then can declare support for that feature via:
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/properties/contexts/portletContainerContext.xml#L96


On Tue, Nov 26, 2013 at 1:49 PM, James Wennmacher wrote:

>  Oh.  I didn't realize that.  Sure a few pointers would be great.  Thanks!
>
> James Wennmacher - Unicon480.558.2420
>
> On 11/26/2013 12:37 PM, Eric Dalquist wrote:
>
> FYI this would be in the realm of uPortal's responsibility to support. If
> you want some pointers as to where in uPortal that support should go let me
> know.
>
>
>  On Tue, Nov 26, 2013 at 11:28 AM, James Wennmacher (JIRA) <
> j...@apache.org> wrote:
>
>> James Wennmacher created PLUTO-624:
>> --
>>
>>  Summary: Pluto does not support Runtime option
>> javax.portlet.actionScopedRequestAttributes
>>  Key: PLUTO-624
>>  URL: https://issues.apache.org/jira/browse/PLUTO-624
>>  Project: Pluto
>>   Issue Type: Bug
>> Reporter: James Wennmacher
>>
>>
>> Per Portlet 2.0 spec, section 'PLT.10.4.4 Runtime Option
>> javax.portlet.actionScopedRequestAttributes', the portlet container
>> should should support the runtime option
>> 'javax.portlet.actionScopedRequestAttributes. to store request options from
>> the action to the render phase.  Pluto does not appear to support this
>> option.
>>
>> Can refer to
>> http://www.theserverside.com/news/1363818/JSR-286-Portlets-Action-scoped-Request-Attributesfor
>>  an example setup.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1#6144)
>>
>
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] JSR 362: Portlet Specification 3.0

[Eric Dalquist]

>From past JSR EG experience, 2-4 phone or video conference calls a month,
email list participation, keeping up with design documentation and API
design changes, providing feedback on those designs and potentially
ownership over some part of the API/Design. None of it is terribly hard but
there is also no one that is going to make sure you're staying on top of
it, you need to keep up and keep active or you'll likely just be assumed
inactive by the rest of the EG and ignored.

If you find people that are interested I can make introductions via the
pluto-dev email list.


On Wed, Oct 30, 2013 at 3:44 PM, Steve Swinsburg
wrote:

> Eric do you know what's involved/expected? I can put this to the Apereo
> Board.
>
> Cheers
> Steve
>
> sent from mobile device
> On 31/10/2013 9:43 AM, "Eric Dalquist"  wrote:
>
>> Note that list isn't final and people can still get onto the EG if they
>> really want to. Self motivation to be involved with a JSR EG is a MUST.
>>
>>
>> On Wed, Oct 30, 2013 at 3:17 PM, Steve Swinsburg <
>> steve.swinsb...@gmail.com> wrote:
>>
>>> From the names on the list it doesn't look like it.
>>>
>>> Cheers
>>> Steve
>>>
>>> sent from mobile device
>>> On 31/10/2013 4:54 AM, "James Wennmacher" 
>>> wrote:
>>>
>>>>  I just happened to run across this again.  Did Apereo get someone
>>>> involved?
>>>> https://java.net/projects/portletspec3/members
>>>>
>>>> James Wennmacher - Unicon480.558.2420
>>>>
>>>> On 08/23/2013 10:02 AM, Eric Dalquist wrote:
>>>>
>>>> If someone wants to be involved I can nominate them for pluto committer
>>>> access. The JSR EG is getting created right now and Apereo could still get
>>>> someone involved.
>>>>
>>>>  -Eric
>>>>
>>>>
>>>> On Fri, Aug 23, 2013 at 9:08 AM, Anthony Colebourne <
>>>> anthony.colebou...@manchester.ac.uk> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does anybody know whether Apereo are planing to get representation in
>>>>> this group?
>>>>>
>>>>> -- Anthony.
>>>>>
>>>>> --
>>>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>>>>> eric.ape...@dalquist.org
>>>>> To unsubscribe, change settings or access archives, see
>>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>>>
>>>>
>>>>  --
>>>>
>>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>>>> jwennmac...@unicon.net
>>>> To unsubscribe, change settings or access archives, see 
>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>>
>>>>
>>>> --
>>>>
>>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>>>> steve.swinsb...@gmail.com
>>>>
>>>>
>>>>
>>>> To unsubscribe, change settings or access archives, see 
>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>>
>>>>  --
>>>
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>>> eric.ape...@dalquist.org
>>>
>>>
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>
>>>
>> --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> steve.swinsb...@gmail.com
>>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] JSR 362: Portlet Specification 3.0

[Eric Dalquist]

Note that list isn't final and people can still get onto the EG if they
really want to. Self motivation to be involved with a JSR EG is a MUST.


On Wed, Oct 30, 2013 at 3:17 PM, Steve Swinsburg
wrote:

> From the names on the list it doesn't look like it.
>
> Cheers
> Steve
>
> sent from mobile device
> On 31/10/2013 4:54 AM, "James Wennmacher"  wrote:
>
>>  I just happened to run across this again.  Did Apereo get someone
>> involved?
>> https://java.net/projects/portletspec3/members
>>
>> James Wennmacher - Unicon480.558.2420
>>
>> On 08/23/2013 10:02 AM, Eric Dalquist wrote:
>>
>> If someone wants to be involved I can nominate them for pluto committer
>> access. The JSR EG is getting created right now and Apereo could still get
>> someone involved.
>>
>>  -Eric
>>
>>
>> On Fri, Aug 23, 2013 at 9:08 AM, Anthony Colebourne <
>> anthony.colebou...@manchester.ac.uk> wrote:
>>
>>> Hi,
>>>
>>> Does anybody know whether Apereo are planing to get representation in
>>> this group?
>>>
>>> -- Anthony.
>>>
>>> --
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>>> eric.ape...@dalquist.org
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>
>>
>>  --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> jwennmac...@unicon.net
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>
>> --
>>
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> steve.swinsb...@gmail.com
>>
>>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] JSR 362: Portlet Specification 3.0

[Eric Dalquist]

I think Andrew Petro is working on getting involved. I'd be happy to get
other's going on it as well.


On Wed, Oct 30, 2013 at 10:54 AM, James Wennmacher
wrote:

>  I just happened to run across this again.  Did Apereo get someone
> involved?
> https://java.net/projects/portletspec3/members
>
> James Wennmacher - Unicon480.558.2420
>
> On 08/23/2013 10:02 AM, Eric Dalquist wrote:
>
> If someone wants to be involved I can nominate them for pluto committer
> access. The JSR EG is getting created right now and Apereo could still get
> someone involved.
>
>  -Eric
>
>
> On Fri, Aug 23, 2013 at 9:08 AM, Anthony Colebourne <
> anthony.colebou...@manchester.ac.uk> wrote:
>
>> Hi,
>>
>> Does anybody know whether Apereo are planing to get representation in
>> this group?
>>
>> -- Anthony.
>>
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> eric.ape...@dalquist.org
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>
>  --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> jwennmac...@unicon.net
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Vote: uPortal Steering Committee Representative

[Eric Dalquist]

+1


On Wed, Sep 18, 2013 at 7:19 AM, Andrew Petro  wrote:

> +1
>
> I agree emphatically that Anthony will make an excellent uPortal Steering
> Committee member.  He's already a leader and I look forward to his further
> leadership in this additional role.
>
>
> On Wed, Sep 18, 2013 at 8:31 AM, Jim Helwig wrote:
>
>> We have one nominee for the vacant developer representative on the
>> uPortal Steering Committee: Anthony Colebourne. To make it official, would
>> committers please respond with a "+1" if you agree that Anthony should join
>> the uPSC? Voting will close at 5pm PT Friday, September 20, 2013.
>>
>> Thank you,
>> Jim Helwig
>> uPSC Chair
>>
>>
>>
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> ape...@unicon.net
>>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/**display/JSG/uportal-dev
>>
>
> --
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] JSR 362: Portlet Specification 3.0

[Eric Dalquist]

If someone wants to be involved I can nominate them for pluto committer
access. The JSR EG is getting created right now and Apereo could still get
someone involved.

-Eric


On Fri, Aug 23, 2013 at 9:08 AM, Anthony Colebourne <
anthony.colebou...@manchester.ac.uk> wrote:

> Hi,
>
> Does anybody know whether Apereo are planing to get representation in
> this group?
>
> -- Anthony.
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/**display/JSG/uportal-dev
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Respondr -- Further progress on the Responsive Design theme for uPortal 4.1

[Eric Dalquist]

Awesome work Drew, it looks great!


On Wed, Aug 7, 2013 at 7:56 PM, Drew Wills  wrote:

> Hey folks,
>
> I had a chance today to go a bit further with the work on the new
> Respondr theme based on Twitter Bootstrap and Responsive Design principals.
>
>- https://issues.jasig.org/browse/UP-3776
>
> Previously all content on the page was static HTML.
>
> Now the tabs at the top are rendered appropriately based on the logged
> in user's layout (and they correctly navigate the user when clicked),
> and the portlets that appear on the page are actual portlets rendered by
> uPortal and the correct ones for the selected tab.
>
> I'm attaching an updated screen capture.  Work is still needed on
> portlet chrome.
>
> NOTE #1:  In the last email I indicated that you have to change a
> profile XML data file to point to the Respondr theme (and import) to
> enable it.  That's accurate, but I suggested using the mobile
> profile(s).  If you do it that way, you'll also need to change the
> structure transform to the normal desktop one ("DLMTabsColumns").
>
> Here's a "$git diff" representation of the necessary changes...
>
> ---
>
> a/uportal-war/src/main/data/default_entities/profile/defaultTemplateUser_mobileDefault.profile.xml
> +++
>
> b/uportal-war/src/main/data/default_entities/profile/defaultTemplateUser_mobileDefault.profile.xml
> @@ -23,6 +23,6 @@
> HTML mobile browser profile
> mobileDefault
> A sample mobile profile for common web
> browsers
> -  
> -  
> +  
> +  
>   
>
> NOTE #2:  The Universality tab rendering strategy is column-based, but
> (apparently) Bootstrap conceptualizes page content in rows.
> Consequently, I've "flipped" the column-based layout XML into rows.
>
> So if in Universality you would see...
>
>(A) (B)
>(C) (D)
>(E)
>
> Now in Respondr you'll see...
>
>(A) (C) (E)
>(B) (D)
>
> Cheers,
>
> drew wills
>
>
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> eric.ape...@dalquist.org
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] UP-3408 Work around spring exception handling bug

[Eric Dalquist]

So now that a Spring fix is out that code should probably be tweaked so
that a portlet parameter can be set to toggle behavior. It is the
version of Spring that the portlet is using that dictates the spring
controller's exception handling behavior.

-Eric

On 07/16/2013 10:24 AM, Anthony Colebourne wrote:
> Hi,
>
> The problem is we're forced into manually trapping all exceptions that
> occur during an action request or face the user with a not so helpful
> generic error.
>
> I see that this was fixed in spring, so is the intention that this
> will be removed from uPortal at some point?
>
> I cannot get my head around whether the workaround is needed to
> accommodate the version of spring in uPortal or the version of spring
> in portlets?
>
> -- Anthony.
>
>
>
>
> On 16/07/13 16:05, Eric Dalquist wrote:
>> Take a look at: https://issues.jasig.org/browse/UP-3408
>>
>> Perhaps this needs to be a toggle for exceptions during actions but we
>> were seeing issues where portlets were failing but the portal didn't
>> correctly respond to the failure due to spring swallowing the exception.
>> This was particularly bad for Events where a portlet may never even
>> render after an event exception effectively hiding the exception
>> completely.
>>
>> -Eric
>>
>> On 7/16/13 9:29 AM, Anthony Colebourne wrote:
>>> Hi,
>>>
>>> We've been working on an issue where we are throwing an exception
>>> within the Action phase of a portlet. This portlet is using Spring
>>> 3.2.0.
>>>
>>> The problem we're seeing is that the ExceptionResolver is not picking
>>> up the exception.
>>>
>>> It seems that in our version of Spring, this should work. However it
>>> seems that this commit on uPortal prevents it from working.
>>>
>>> https://github.com/Jasig/uPortal/commit/f55dc7d488e96d9cc7e2081167c0e7cfea404ca1
>>>
>>>
>>>
>>> Can anybody shed some light on the situation?
>>>
>>> Thanks,
>>> Anthony.
>>>
>>
>>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] UP-3408 Work around spring exception handling bug

[Eric Dalquist]

Take a look at: https://issues.jasig.org/browse/UP-3408

Perhaps this needs to be a toggle for exceptions during actions but we 
were seeing issues where portlets were failing but the portal didn't 
correctly respond to the failure due to spring swallowing the exception. 
This was particularly bad for Events where a portlet may never even 
render after an event exception effectively hiding the exception completely.


-Eric

On 7/16/13 9:29 AM, Anthony Colebourne wrote:

Hi,

We've been working on an issue where we are throwing an exception 
within the Action phase of a portlet. This portlet is using Spring 3.2.0.


The problem we're seeing is that the ExceptionResolver is not picking 
up the exception.


It seems that in our version of Spring, this should work. However it 
seems that this commit on uPortal prevents it from working.


https://github.com/Jasig/uPortal/commit/f55dc7d488e96d9cc7e2081167c0e7cfea404ca1 



Can anybody shed some light on the situation?

Thanks,
Anthony.






smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Off to the Next Adventure

[Eric Dalquist]

I wanted to let everyone in the uPortal and Apereo community know that
I'm going to be changing jobs in a few weeks to start a new career at
Google. This message is bittersweet as I have loved being involved with
uPortal for the last nine years, it has been a wonderful community to
work, learn, and grown in.

I do plan to continue my involvement with Apereo and uPortal in
particular though I obviously will not be able to maintain the same
level of activity that I have had. I'll still lurk on the email lists
and I'd like to think that I will even continue with some development or
at the very least code review. That said my family and I will be moving
from Madison, WI to Seattle, WA in August and I'll be starting at my new
position at the end of August. With all of that I will probably
disappear completely until we are settled and I'm comfortable in my new
role.

Thank you all for being a part of this wonderful community. I'm looking
forward to see what cool new things uPortal and the rest of the Apereo
projects will be getting up to.

-Eric Dalquist




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [VOTE] Tim Levett for uPortal Committer

[Eric Dalquist]

The vote result is:
4 - +1
0 - 0
0 - -1

So welcome Tim, I'll be working with you to setup commit access and make
sure all the ICLA paperwork is in order.

-Eric

On 06/06/2013 10:08 AM, Eric Dalquist wrote:
> I'd like propose Tim Levett for a uPortal committer, he has been
> working on uPortal and portlets at UW for 6 months now and will just
> continue to get more involved in the project.
>
> This vote needs 3 +1 votes and no -1 votes in the next 72 hours to
> pass. All existing uPortal committers can cast binding votes, all
> other votes are advisory but still good to get.
>
> -Eric
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Backbone version in uPortal 4.0

[Eric Dalquist]

Thanks,

So I got that little bit of backbone code working if I make the portlet
pull in jQuery 1.9.1, Underscore 1.4.4 and Backbone 0.9.2

The problem I ran into working off of the backbone examples is they are
written for version 1.0 and that requires jQuery 1.7 but uPortal 4.0 is
only using jQuery 1.6 and I'm guessing that upgrading all of uPortal 4.0
to jQuery 1.7.4+ might not be a great thing to do.

Would you have a little time either here via email or in the irc chat
room to help me with a few backbone questions? The issue I have is the
"this.listenTo" call doesn't appear to work using Backbone 0.9.2:
https://gist.github.com/edalquist/5751645#file-config-js-L39

-Eric

On 06/10/2013 11:26 AM, Matt Polizzotti wrote:
> Eric,
>
> Sorry it took me a while to get back to you. I don't believe the core 
> framework is using backbone, but some portlets are using it. For instance, 
> the News Reader Portlet is using Backbone to render its views. Off the top of 
> my head, I am not sure which version the portlet is using but it may be 
> looking toward the portal first to see if the backbone library exists. This 
> would be the only concern that I can think of in terms of upgrading.
>
> Thanks,
> Matt
>
>
>
> - Original Message -
> From: "Eric Dalquist" 
> To: "Matt Polizzotti" , "uportal-dev" 
> 
> Sent: Friday, June 7, 2013 9:17:45 AM
> Subject: Backbone version in uPortal 4.0
>
> I see that uPortal 4.0 is pulling in backbone 0.9.2 but I don't see any 
> where that we are actually using it in the core framework. Do you see 
> any problems with my upgrading to the latest version of backbone?
>
> -Eric
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Backbone version in uPortal 4.0

[Eric Dalquist]

I completely agree with you Drew, I was asking for a framework portlet
where it would be silly to not just use the uPotal loaded JS libraries.
I'm not going to worry about breaking external portlets that get pulled
in. External portlets should be loading their own JS dependencies to
avoid portal-specific version dependencies.

-Eric


On 06/10/2013 11:59 AM, Drew Wills wrote:
> Eric, Matt, et al.,
>
> I just want to throw in $.02 on this topic...
>
> I think the practice of worrying about what portlets might or might
> not do with JS provided by the portal is unsustainable.  I think it
> will tie us in knots and prevent us from doing what we need to and
> from moving forward.  I think, if we start to worry about it, it will
> become the same issue we used to have with IChannels:  we don't know
> what APIs are in use "in the wild," so we become fearful to touch
> anything.
>
> IMHO portlets are 100% responsible for their own JS.  Every portlet
> should be developed such that it is prepared to load every line of JS
> it may need on it's own.  As a means of improving performance,
> however, portlets _may_ provide a _configurable option_ to piggyback
> on one or more portal JS libs... but anyone wishing to use this
> strategy is obligated to test it thoroughly (1) as they develop the
> portlet, and (2) _any time they upgrade the portal sources_.
>
> If the portal changes what it's using, and that's no longer compatible
> with what a portlet is using, it's the responsibility of the _portlet_
> to disable the piggyback feature until the portlet can be enhanced to
> work with the new version.
>
> I think this is a sensible approach for these issues.
>
> drew
>
>
> On 06/10/2013 09:26 AM, Matt Polizzotti wrote:
>> Eric,
>>
>> Sorry it took me a while to get back to you. I don't believe the core
>> framework is using backbone, but some portlets are using it. For
>> instance, the News Reader Portlet is using Backbone to render its
>> views. Off the top of my head, I am not sure which version the
>> portlet is using but it may be looking toward the portal first to see
>> if the backbone library exists. This would be the only concern that I
>> can think of in terms of upgrading.
>>
>> Thanks,
>> Matt
>>
>>
>>
>> - Original Message -
>> From: "Eric Dalquist" 
>> To: "Matt Polizzotti" , "uportal-dev"
>> 
>> Sent: Friday, June 7, 2013 9:17:45 AM
>> Subject: Backbone version in uPortal 4.0
>>
>> I see that uPortal 4.0 is pulling in backbone 0.9.2 but I don't see any
>> where that we are actually using it in the core framework. Do you see
>> any problems with my upgrading to the latest version of backbone?
>>
>> -Eric
>>
>>
>




smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Backbone version in uPortal 4.0

[Eric Dalquist]

I see that uPortal 4.0 is pulling in backbone 0.9.2 but I don't see any 
where that we are actually using it in the core framework. Do you see 
any problems with my upgrading to the latest version of backbone?


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Jasig Services Outages

[Eric Dalquist]

Jira, Confluence and Crowd will be down for upgrade at various times 
between 7pm and 12am CDT on Friday June 7th.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [VOTE] Tim Levett for uPortal Committer

[Eric Dalquist]

+1

On 6/6/13 8:08 AM, Eric Dalquist wrote:
I'd like propose Tim Levett for a uPortal committer, he has been 
working on uPortal and portlets at UW for 6 months now and will just 
continue to get more involved in the project.


This vote needs 3 +1 votes and no -1 votes in the next 72 hours to 
pass. All existing uPortal committers can cast binding votes, all 
other votes are advisory but still good to get.


-Eric






smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] [VOTE] Tim Levett for uPortal Committer

[Eric Dalquist]

I'd like propose Tim Levett for a uPortal committer, he has been working 
on uPortal and portlets at UW for 6 months now and will just continue to 
get more involved in the project.


This vote needs 3 +1 votes and no -1 votes in the next 72 hours to pass. 
All existing uPortal committers can cast binding votes, all other votes 
are advisory but still good to get.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal 4.0.12 release

[Eric Dalquist]

 I'm going to try an get a 4.0.12 release cut early next week, probably
Tuesday. Keep that in mind if you have pending changes/fixes you'd like
to see make it into the release.

-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] James Wennmacher for uPortal committer

[Eric Dalquist]

+1
On 05/06/2013 12:39 PM, Drew Wills wrote:
> Hey folks,
>
> We have a very seasoned and capable Java developer here at Unicon who
> has recently become quite involved with uPortal -- and whom we expect
> to be even more involved going forward -- named James Wennmacher. 
> He's also been very active and helpful on the uportal-user,
> uportal-dev, and portlet-dev lists... I hope several of you will
> recognize the name.
>
> I'd like to nominate James for uPortal committer.  You can look at
> some of the work he's contributed here...
>
>   - https://issues.jasig.org/secure/ViewProfile.jspa?name=jameswennmacher
>
> and here...
>
>   - https://github.com/jameswennmacher?tab=activity
>
> James has submitted numerous pull requests to uPortal and Apereo
> portlets.  In particular, he played a big role in increasing the
> number of reports in the Statistics Portlet, and in improving the
> statistics subsystem generally.
>
> +1
>
> drew
>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re:[uportal-dev] Question on folder names

[Eric Dalquist]

It could be amended. That entire folderName section is delegated to the 
IUrlNodeSyntaxHelper that is configured for the current structure 
transform. The syntax of each path element (there can be 0..N) in the 
folder section is dictated by that class. In the case of the 
SingleTabUrlNodeSyntaxHelper it tries to use the externalId of a tab in 
preference to the layout node id and in the case of duplicate 
externalIds it uses the externalId and the layout node id.


So really that page needs some better clarification that the folderName 
can actually be any number of folders (path elements) and the formatting 
of each of those elements is up to the IUrlNodeSyntaxHelper. The rest of 
the URL string format is handled by the main url syntax provider class.


I hope that helps,
-Eric

On 4/24/13 4:53 PM, James Wennmacher wrote:
Does https://wiki.jasig.org/pages/viewpage.action?pageId=53610142 need 
to be amended to indicate folder names may have a layoutNodeId in them 
or is that an internal thing?


The above page suggests an url might be /f/folder0/folder1/folder2/p/

However the code at 
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/url/SingleTabUrlNodeSyntaxHelper.java#L227 
looks like a folder name (at least the first folder in the list) may 
also have a period plus a layoutNodeId; e.g.


/f/folder0.23/folder1/folder2/p/
(For this illustration I'm assuming a valid layout node id might be 23 
but I don't know).






smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Logging Documentation

[Eric Dalquist]

We've put together some project setup documentation to try and get
logging configurations consistent across uPortal and portlets:
https://wiki.jasig.org/display/PLT/Logging+Best+Practices

Let me know if you have any questions/comments/tweaks!

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal 4.0.11 Released

[Eric Dalquist]

  
  

uPortal 4.0.11 GA
  Announcement
Apereo is proud to announce uPortal 4.0.11, continuing
in our regular patch releases of uPortal 4.0.
Features and Changes of Note

  [UP-3654] - Bundled the calendar portlet
  [UP-3671]
- Added portal activity portlet to report on current
portal-wide activity


  Updating from
4.0.0-4.0.5
  

  

  
  
If you have data
  you care about in the UP_LOGIN_EVENT_AGGREGATE table
  please back it up externally or rename the table
  before executing the following steps. db-update will
  drop this table.
  

  

  
  After
configuring your uPortal 4.0.11 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-4011
Release Notes: https://wiki.jasig.org/display/UPC/4.0.11
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.11/

Full Release Notes
Bug

  [UP-3660] - Editing of "View user
attribute" permissions is broken
  [UP-3661] - Calls to
SessionRESTController "/api/session" RequestMapping throws error
  [UP-3664] - Bookmarks uwfn.tld
apparently doesn't load on Tomcat7
  [UP-3665] - Edit Rich
Configuration link on portlet admin fails on tomcat 7
  [UP-3672] - Build fails with
'Detected both jcl-over-slf4j.jar AND slf4j-jcl.jar on the class
path, preempting StackOverflowError'

Improvement

  [UP-3654] - Bundle the Calendar
portlet into the uPortal set of bundled portlets
  [UP-3658] - Enhance the Directory
portlet so that it goes into MAXIMIZED window state upon
submitting a search
  [UP-3659] - Add a helpful message
to the Directory (framework) portlet about the maximum results
  [UP-3663] - Add ability to import
archive of entity files
  [UP-3668] - Allow
IPortalEventAggregator to check support on PortalEvent object
  [UP-3669] - Reduce flushing
during event aggregation

New Feature

  [UP-3662] - Provide a PAGS regex
tester that does not require a match on the whole region
  [UP-3671] - Create a new Portal
Activity framework portlet that shows some basic info about
current users, logins, and searches

Task

  [UP-3673] - Add logging config
for bundled Calendar portlet

-Eric Dalquist
  



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] can missing elements be purged from the db?

[Eric Dalquist]

Can you share a full stack trace so we can see what the portal is trying
to do?

-Eric

On 03/21/2013 11:57 AM, Bill Brown wrote:
> hello uPortal devs. 
>
> We're using uportal 4.0.5 and see flurries of this error every couple
> of days or so.
>
> org.springframework.web.util.NestedServletException: Request
> processing failed; nested exception is
> org.jasig.portal.PortalException: Element with ID="u21301l1s7" doesn't
> exist for woodspt.
>
> looking back at the earlier traces,  all of them share the
> "ID="u21301|1s7".  Is there a way I can remove traces of that from the
> database to prevent users who have/had that element from generating an
> error?  I suspect that maybe this is not fatal because we're not
> getting reports from users telling us that cannot access a page/tab.
>
> Thanks for your help.
>
> Bill Brown
> Web Application Developer, Web Services
> IT Services, The University of Chicago
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 4.0.11 Release Planning

[Eric Dalquist]

 I'm going to plan on cutting 4.0.11 on Thursday. Just keep that in mind
as you're looking at issues/bugs/etc this week.

-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] USD Portal Statistics Portlet

[Eric Dalquist]

Looks awesome, +1 from me
On 03/05/2013 10:23 AM, Drew Wills wrote:
> Hey folks,
>
> University of South Dakota has this really cool "Portal Statistics" 
> portlet that they show on their guest page.  It shows how many users 
> logged in recently, as well as the most popular search terms recently.
>
> They like it because it helps emphasize and communicate the value of the 
> portal -- it illustrates just how much the portal is used.  (Heads up: 
> they're on spring break atm, so the screenshot has a very low number.)
>
> I think it's a great widget, and I'd like to fold something like this 
> into uP as a framework portlet and tie it to the uP4 stats infrastructure.
>
> drew
>
>
>  Original Message 
>
> Below is a screenshot of our portal statistics portlet.  Upon login to
> our portal, we log the user’s information (username, affiliations, ip,
> etc).  Every 15 minutes we update the statistics to show logins broken
> down by affiliation.  We also capture the search terms from our custom
> portal search and display the top 10 search terms from the last week.
>
>
>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] turning off uMobile

[Eric Dalquist]

-1 just make sure the manual has enough details to go and tweak the
browser mapping.

-Eric


On 02/18/2013 01:09 PM, Misagh Moayyed wrote:
>
> Team,
>
> How do we feel about adding a boolean setting to the build process so
> profile mappings for the mobile view can be toggled at build time? I
> figure that might be an easier route to configure, rather than
> tweaking the bean directly.
>
>  
>
> */-/*Misagh/
>
> /
>
>  
>
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal-4.0.10 with Oracle 11g Database Exadata

[Eric Dalquist]

Replied on uportal-user email list.

-Eric

On 2/14/13 4:42 PM, Laura McCord wrote:
We are running uP 4.0.6 with a database schema. Though, I am not sure 
what the sessions per user limit is set to.


Laura


On 2/14/13 11:20 AM, Xin Feng wrote:
Thanks a lot.  It did fix my problem.  I only need step 2.  step 1 is 
getting the dialect from filters/local.properties.


However I ran to other problem as,
Caused by: java.sql.SQLException: ORA-02391: exceeded simultaneous 
SESSIONS_PER_USER limit


In order to run uPortal-4.0.10,  we already increase the 
SESSIONS_PER_USER limit from 20 to 40.


What's the proper setting for SESSIONS_PER_USER limit in order to run 
uPortal-4.0.10 including cas and  delivered portlets?


Other question would be that do you use a single database for uPortal 
or a schema ( shared with other schemas) in the database .


Thanks,
Xin


On Thu, Feb 14, 2013 at 10:32 AM, Laura McCord > wrote:


Right, I had to use org.hibernate.dialect.Oracle10gDialect.

In fact, I used the attached email thread to fix the
WebProxyPortlet:

http://jasig.275507.n4.nabble.com/WebProxyPortlet-does-not-start-in-uP-4-0-8-td4657403.html

In summary, there were 2 places I had to fix in WebProxyPortlet:

1)

uportal-portlets-overlay/WebProxyPortlet/src/main/webapp/WEB-INF/datasource.properties
 I manually added the dialect here

2)

uportal-portlets-overlay/WebProxyPortlet/src/main/webapp/WEB-INF/applicationContextOverrides.xml

I commented out the jpaVendorAdaptor bean

Those steps seemed to get rid of the hibernate exception.

Laura




On 2/14/13 9:22 AM, Xin Feng wrote:

Hi Laura,

Thanks.  What did you use for
"environment.build.hibernate.dialect "  ?

I used

com.oracle
ojdbc6
11.2.0.3 

with

environment.build.hibernate.dialect=org.hibernate.dialect.Oracle10gDialect

uPortal seems working,  but WebProxyPortlet failed as following:

Caused by: org.hibernate.HibernateException: unknown Oracle
major version [11]

And we are heavily using WebProxyPortlet .

Thanks,
Xin

On Thu, Feb 14, 2013 at 10:01 AM, Laura McCord
mailto:lmcc...@ucmerced.edu>> wrote:

Hi Xin,

I used the following driver configuration for Oracle 11g and
it works.

com.oracle
ojdbc6_g
11.2.0.3

-Laura


On 2/14/13 8:56 AM, Xin Feng wrote:

Hi,

What version of Oracle JDBC driver should be used with
Oracle 11g Database?

Have anyone tried with Oracle on Exadata?

Thanks,
Xin
-- 


You are currently subscribed touportal-...@lists.ja-sig.org  
  as:lmcc...@ucmerced.edu  

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 


You are currently subscribed touportal-...@lists.ja-sig.org  
  as:xinf...@umich.edu  

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 


You are currently subscribed touportal-...@lists.ja-sig.org  
  as:lmcc...@ucmerced.edu  

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev





--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 302 moved temporarily

[Eric Dalquist]

This is also a better question for the uportal-user list. uportal-dev is
intended for people working on the internals of uPortal framework
development.

Thank you,
-Eric

On 02/13/2013 10:55 AM, Brad Morse wrote:
> I am receiving 302 Moved Temporarily on AJAX get requests, then I get the 200 
> OK, outside of uPortal (as a stand-a-lone app) it returns two 200 requests. 
> In uPortal, it returns two 302's then the 2 200 requests afterward. I may of 
> asked this question previously, but I was wondering if anyone else had a 
> similar issue.
>
> Is there something I forgot in the Filter URL config of the web proxy portlet 
> config settings? I assume it has something to do with the ajax requests are 
> on a different subdomain than uPortal is, is there some setting in uPortal 
> that allows for uPortal to say in theory "hey…any requests from this 
> domain/subdomain is fine, act as normal"?




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] IE8 Enable Protected Mode

[Eric Dalquist]

This would probably get more traction on the uportal-user email list.

Thanks,
-Eric

On 02/13/2013 09:02 AM, Brad Morse wrote:
> This is a shot in the dark, but we use BEIS to handle our Single Sign on from 
> uPortal 3.2 to Ellucian Banner (formerly Sungard). The SSO process does not 
> work in IE8, but if we check the box "Enable Protected Mode" in the Internet 
> Options - security tab, it works as expected. It works fine in chrome and 
> firefox too.
>
> I know this isn't a uPortal issue, but I was wondering if anyone else 
> experienced this issue.
>
> Thanks!




smime.p7s
Description: S/MIME Cryptographic Signature

Re:[uportal-dev] Fwd: Push Rights for Tony Arland

[Eric Dalquist]

Done.

On 02/11/2013 06:33 PM, Anthony Arland wrote:
> Hey Eric,
>
> I was wondering if you could grant me the push rights for the branches
> specified below.  I'm a unicon dev checking in code for SSP.  Thanks
> very much for your help.
>
> -Tony
>
> Begin forwarded message:
>
>> *From: *Daniel McCallum > >
>> *Subject: **Push Rights for Tony Arland*
>> *Date: *February 8, 2013 9:43:00 AM MST
>> *To: *"uportal-...@lists.jasig.org
>> " > >
>> *Cc: *Anthony Arland mailto:aarl...@unicon.net>>
>>
>> Hello,
>>
>> Tony Arland has been a full-time dev on the SSP project and is now
>> finding a need to push supporting code to the
>> Jasig/uPortal#ssp-master and Jasig/uPortal#ssp-rel-1-0-patches
>> branches. Can he please be granted push rights to that repo?
>>
>> Github ID: aarland
>>
>> Thanks.
>>
>> - Dan
>



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal 4.0.10 Released

[Eric Dalquist]

  
  

Apereo is proud to announce uPortal 4.0.10, continuing
in our regular patch releases of uPortal 4.0.
Features and Changes of Note

  [UP-3631] & [UP-3632] - Popular Portlets reporting
is working again
  [UP-3651] - Now if
the event aggregation configuration is missing nothing will be
aggregated instead of everything being aggregated
  [UP-3641] & [UP-3655] - Fix MySQL bugs related to
clustering and event processing
  [UP-3640] - Tomcat 7 Report 


  Updating from
4.0.0-4.0.5
  

  

  
  
If you have data
  you care about in the UP_LOGIN_EVENT_AGGREGATE table
  please back it up externally or rename the table
  before executing the following steps. db-update will
  drop this table.
  

  

  
  After
configuring your uPortal 4.0.10 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-4010
Release Notes: https://wiki.jasig.org/display/UPC/4.0.10
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.10/

Full Release Notes
Bug

  [UP-3532] - portlet
render cache output not purged on processAction in subsequent
logins
  [UP-3541] - Comments
in fragment-layout.xml cause parts of layouts not to import
  [UP-3632] - Fix the
"Popular Portlets" controller logic
  [UP-3641] -
UP_JGROUPS_PING index length bug with MySQL
  [UP-3642] - Unchecked
console.log usage in _javascript_
  [UP-3644] -
DailyRollingFileAppender date not separated by a period
  [UP-3649] - Bump the
bundled email-preview portlet to version 2.0.3
  [UP-3651] - Missing
aggregation config results in aggregating everything
  [UP-3655] - Event
Aggregation fails on MySQL due to -Infinity value

Improvement

  [UP-3629] - Refactor
statistics report column headings and column labels
implementation to make more generic
  [UP-3648] -
Enhancement to place (optionally) some config outside uPortal
build/deploy process

New Feature

  [UP-3624] - Redirect
log in attempts if cookies are disabled
  [UP-3631] - Add
report for portlets added to layout
  [UP-3640] - Add
support for Tomcat7 in uP40
  [UP-3645] - Filter
Portlet Registry by portlet status
  [UP-3652] - Person
Lookup max results configurable & Add scrollbar
    
-Eric Dalquist
  



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] query functions firing and not firing

[Eric Dalquist]

Ah sorry I missed that whole web proxy bit, the namespace part is
irrelevant then. You appear to be loading your AJAX URLs correctly for
them to work via the WPP but it is still a rather touchy proposition to
do AJAX via WPP. Maybe that is something we can provide better support
for in WPPv2 as we can use portlet resource URLs there to better handle
non-markup content.

My only suggestion at this point is to watch the ajax network activity
in the browser's dev tools to see if you can see any hints as to what is
going on.


-Eric






On 02/06/2013 09:38 AM, Domazlicky, Eric wrote:
>
> Eric,
>
>  
>
> If I'm understanding Brad's issue correctly he is trying to proxy a
> normal jQuery web app through the WebProxyPortlet. In this case, is
> there any way he could use the portlet namespace variable in his web app?
>
>  
>
> *From:*bounce-26932826-20145...@lists.wisc.edu
> [mailto:bounce-26932826-20145...@lists.wisc.edu] *On Behalf Of *Eric
> Dalquist
> *Sent:* Wednesday, February 06, 2013 7:33 AM
> *To:* uportal-dev@lists.ja-sig.org
> *Subject:* Re: [uportal-dev] query functions firing and not firing
>
>  
>
> So I just realized that best practices page isn't completely right.
> I've updated https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices
>
> Read through the "JavaScript Loading" and "jQuery Selectors" sections.
>
> -Eric
>
> On 02/06/2013 09:12 AM, Brad Morse wrote:
>
> I am using noconflict mode, but I am not sure about what you mean
> by the portlet namespace. Could you provide a short example? I am
> a novice with jQuery/js and I looked up stuff about namespacing
> but I am not 100% I did it correctly.
>
>  
>
> I have copied the js file here: http://pastie.org/6079763
>
>  
>
> On Feb 6, 2013, at 9:47 AM, Eric Dalquist wrote:
>
>
>
> Just to double check:
>
>  1. You're using jQuery in extreme noconflict mode
>  2. You're using the portlet namespace in your selectors to find
> elements within the dom
>
> -Eric
>
>  
>
> On 02/06/2013 07:37 AM, Brad Morse wrote:
>
> I think it might have to do something with my general config
> portlet settings, something with the portlet URL's with
> exclusive/normal.
>
>  
>
> When I get this resolved, I'll report back the fix - in the
> meantime I welcome anything you recommend me to look into why
> this is happening.
>
>  
>
> Thanks!
>
>  
>
> On Feb 5, 2013, at 12:36 PM, Eric Dalquist wrote:
>
>
>
> Take a look over
> https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices
> and see if that helps. If not let us know and we'll help get
> it figured out :)
>
> -Eric
>
> On 02/05/2013 10:02 AM, Brad Morse wrote:
>
> I created a calendar portlet, using the web proxy portlet. It 
> uses jQuery to fire off two ajax posts at page load. One function is to 
> display the calendar, the other is a function that displays a listing of 
> today's events.
>
>  
>
> I use jQuery v 1.9.0 and the script loads just above the closing 
> of the body tag.
>
>  
>
> When I view it outside of the portal, it works as expected, 
> everything is normal in firebug. Then when I run it in the portal, firebug 
> doesn't return any errors, besides all the other things it loads from the 
> other portlets, and it shows those two (calendar and today's events) 
> functions firing the ajax posts, as expected.
>
>  
>
> But...sometimes it'll display the list of today's events twice, 
> and no calendar. Or...it'll display the calendar twice and no list of today's 
> events. This happens about half the time. The other half it works as 
> expected, showing the calendar, and a list of today's events underneath it.
>
>  
>
> There are other portlets that utilize other versions of jQuery, 
> as I found out in firebug. I imagine that has something to do with it.
>
>  
>
> What I want to know is, has anyone else experienced something 
> similar to this and what are some things I should look into, to begin 
> resolving my issue?
>
>  
>
>  
>
> -- 
>
>  
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org 
> <mailto:uportal-dev@lists.ja-sig.org> as: eric.dalqu...@doit.wisc.edu 
> <mailto:eric.dalqu...

Re: [uportal-dev] query functions firing and not firing

[Eric Dalquist]

So I just realized that best practices page isn't completely right. I've
updated https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices

Read through the "JavaScript Loading" and "jQuery Selectors" sections.

-Eric


On 02/06/2013 09:12 AM, Brad Morse wrote:
> I am using noconflict mode, but I am not sure about what you mean by
> the portlet namespace. Could you provide a short example? I am a
> novice with jQuery/js and I looked up stuff about namespacing but I am
> not 100% I did it correctly.
>
> I have copied the js file here: http://pastie.org/6079763
>
> On Feb 6, 2013, at 9:47 AM, Eric Dalquist wrote:
>
>> Just to double check:
>>
>>  1. You're using jQuery in extreme noconflict mode
>>  2. You're using the portlet namespace in your selectors to find
>> elements within the dom
>>
>> -Eric
>>
>>
>>
>> On 02/06/2013 07:37 AM, Brad Morse wrote:
>>> I think it might have to do something with my general config portlet
>>> settings, something with the portlet URL's with exclusive/normal.
>>>
>>> When I get this resolved, I'll report back the fix - in the meantime
>>> I welcome anything you recommend me to look into why this is happening.
>>>
>>> Thanks!
>>>
>>> On Feb 5, 2013, at 12:36 PM, Eric Dalquist wrote:
>>>
>>>> Take a look over
>>>> https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices and
>>>> see if that helps. If not let us know and we'll help get it figured
>>>> out :)
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On 02/05/2013 10:02 AM, Brad Morse wrote:
>>>>> I created a calendar portlet, using the web proxy portlet. It uses jQuery 
>>>>> to fire off two ajax posts at page load. One function is to display the 
>>>>> calendar, the other is a function that displays a listing of today's 
>>>>> events.
>>>>>
>>>>> I use jQuery v 1.9.0 and the script loads just above the closing of the 
>>>>> body tag.
>>>>>
>>>>> When I view it outside of the portal, it works as expected, everything is 
>>>>> normal in firebug. Then when I run it in the portal, firebug doesn't 
>>>>> return any errors, besides all the other things it loads from the other 
>>>>> portlets, and it shows those two (calendar and today's events) functions 
>>>>> firing the ajax posts, as expected.
>>>>>
>>>>> But…sometimes it'll display the list of today's events twice, and no 
>>>>> calendar. Or…it'll display the calendar twice and no list of today's 
>>>>> events. This happens about half the time. The other half it works as 
>>>>> expected, showing the calendar, and a list of today's events underneath 
>>>>> it.
>>>>>
>>>>> There are other portlets that utilize other versions of jQuery, as I 
>>>>> found out in firebug. I imagine that has something to do with it.
>>>>>
>>>>> What I want to know is, has anyone else experienced something similar to 
>>>>> this and what are some things I should look into, to begin resolving my 
>>>>> issue?
>>>>
>>>
>>> -- 
>>>
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>>> eric.dalqu...@doit.wisc.edu
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] query functions firing and not firing

[Eric Dalquist]

Just to double check:

 1. You're using jQuery in extreme noconflict mode
 2. You're using the portlet namespace in your selectors to find
elements within the dom

-Eric



On 02/06/2013 07:37 AM, Brad Morse wrote:
> I think it might have to do something with my general config portlet
> settings, something with the portlet URL's with exclusive/normal.
>
> When I get this resolved, I'll report back the fix - in the meantime I
> welcome anything you recommend me to look into why this is happening.
>
> Thanks!
>
> On Feb 5, 2013, at 12:36 PM, Eric Dalquist wrote:
>
>> Take a look over
>> https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices and see
>> if that helps. If not let us know and we'll help get it figured out :)
>>
>> -Eric
>>
>>
>> On 02/05/2013 10:02 AM, Brad Morse wrote:
>>> I created a calendar portlet, using the web proxy portlet. It uses jQuery 
>>> to fire off two ajax posts at page load. One function is to display the 
>>> calendar, the other is a function that displays a listing of today's events.
>>>
>>> I use jQuery v 1.9.0 and the script loads just above the closing of the 
>>> body tag.
>>>
>>> When I view it outside of the portal, it works as expected, everything is 
>>> normal in firebug. Then when I run it in the portal, firebug doesn't return 
>>> any errors, besides all the other things it loads from the other portlets, 
>>> and it shows those two (calendar and today's events) functions firing the 
>>> ajax posts, as expected.
>>>
>>> But…sometimes it'll display the list of today's events twice, and no 
>>> calendar. Or…it'll display the calendar twice and no list of today's 
>>> events. This happens about half the time. The other half it works as 
>>> expected, showing the calendar, and a list of today's events underneath it.
>>>
>>> There are other portlets that utilize other versions of jQuery, as I found 
>>> out in firebug. I imagine that has something to do with it.
>>>
>>> What I want to know is, has anyone else experienced something similar to 
>>> this and what are some things I should look into, to begin resolving my 
>>> issue?
>>
>
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Error while initializing database - event-aggregation.xml

[Eric Dalquist]

I'm not seeing that, you have no local mods and "git diff
upstream/master" doesn't show any changes?


On 02/01/2013 06:17 AM, Misagh Moayyed wrote:
>
> Team,
>
> Running the latest uPortal source from master, I keep getting the
> following exception stack when I run the command 'ant initdb':
>
>  
>
> FAIL: event-aggregation - default.event-aggregation.xml
>
> 
>
> java.lang.NoSuchMethodError:
> org.jasig.portal.utils.cache.SimpleCacheEntryTag.(Ljava/lang/String;Ljava/lang/String;)V
>
>   at
> org.jasig.portal.jpa.cache.EntityManagerCacheImpl.get(EntityManagerCacheImpl.java:124)
>
>   at
> org.jasig.portal.events.aggr.groups.JpaAggregatedGroupLookupDao.getGroupMapping(JpaAggregatedGroupLookupDao.java:86)
>
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>   at java.lang.reflect.Method.invoke(Method.java:601)
>
> ...
>
>  
>
> Is anyone else experiencing the same issue?
>
>  
>
> */-/*Misagh/
>
> /
>
>  
>
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] query functions firing and not firing

[Eric Dalquist]

Take a look over
https://wiki.jasig.org/display/PLT/JavaScript+Best+Practices and see if
that helps. If not let us know and we'll help get it figured out :)

-Eric


On 02/05/2013 10:02 AM, Brad Morse wrote:
> I created a calendar portlet, using the web proxy portlet. It uses jQuery to 
> fire off two ajax posts at page load. One function is to display the 
> calendar, the other is a function that displays a listing of today's events.
>
> I use jQuery v 1.9.0 and the script loads just above the closing of the body 
> tag.
>
> When I view it outside of the portal, it works as expected, everything is 
> normal in firebug. Then when I run it in the portal, firebug doesn't return 
> any errors, besides all the other things it loads from the other portlets, 
> and it shows those two (calendar and today's events) functions firing the 
> ajax posts, as expected.
>
> But…sometimes it'll display the list of today's events twice, and no 
> calendar. Or…it'll display the calendar twice and no list of today's events. 
> This happens about half the time. The other half it works as expected, 
> showing the calendar, and a list of today's events underneath it.
>
> There are other portlets that utilize other versions of jQuery, as I found 
> out in firebug. I imagine that has something to do with it.
>
> What I want to know is, has anyone else experienced something similar to this 
> and what are some things I should look into, to begin resolving my issue?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] ajax calls in web proxy firing twice

[Eric Dalquist]

Thanks for posting actual the cause as well.

-Eric

On 1/30/13 10:39 AM, Brad Morse wrote:

Eric, thanks for getting back to me. I had the portlet on the page twice, then 
I later discovered other portlet's javascript interfering with other portlets.

Thanks again - all fixed.

On Jan 30, 2013, at 10:46 AM, Eric Dalquist wrote:


Is the first request a HTTP HEAD? The proxy portlet needs to determine the 
content type to figure out how to handle the content and so if it can't 
determine the content type by how the url is used in the proxied page it does a 
HTTP HEAD first looks at the content type and then does the HTTP GET.

Also this should probably be on the uportal-user list.

-Eric


On 1/30/13 9:15 AM, Brad Morse wrote:

I created a web proxy porlet that fires two ajax calls when the portlet loads, 
when i view the app outside of the portal, it fires each one once, as seen in 
firefox firebug, but when I use it as a web proxy portlet in the portal, it 
fires both ajax calls twice.

I edited the web proxy portlet settings and I only put in the URL in the Base 
URL under general configuration settings for the Portlet Administration Portlet 
page.

uPortal v 3.2.4

Is there anything you could recommend me looking into?









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] ajax calls in web proxy firing twice

[Eric Dalquist]

Is the first request a HTTP HEAD? The proxy portlet needs to determine 
the content type to figure out how to handle the content and so if it 
can't determine the content type by how the url is used in the proxied 
page it does a HTTP HEAD first looks at the content type and then does 
the HTTP GET.


Also this should probably be on the uportal-user list.

-Eric


On 1/30/13 9:15 AM, Brad Morse wrote:

I created a web proxy porlet that fires two ajax calls when the portlet loads, 
when i view the app outside of the portal, it fires each one once, as seen in 
firefox firebug, but when I use it as a web proxy portlet in the portal, it 
fires both ajax calls twice.

I edited the web proxy portlet settings and I only put in the URL in the Base 
URL under general configuration settings for the Portlet Administration Portlet 
page.

uPortal v 3.2.4

Is there anything you could recommend me looking into?





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Stats reports issue reporting

[Eric Dalquist]

Use the UP project, don't worry about components.

On 1/22/13 12:55 PM, Jim Helwig wrote:

Hi folks,
What Jira project and component should I use for reporting enhancement 
requests regarding the new statistical reports?


Thanks,
JimH






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issue with user layout not loading

[Eric Dalquist]

Another thought I had, do you actually need all of these groups in the 
portal? If not could you add an option to filter out groups from the 
grouper service you don't care about in the group group service impl?


-Eric


On 1/17/13 11:39 AM, Bill Brown wrote:

OK.

I'm waiting for a test user from our admin group (hope to have it later today) 
with a large number of groups so we can verify that the issue still exists with 
the truncated group fixed.

We're suspecting to still see the issue because the truncated groups have been 
in our system since we've started using grouper without causeing a crash.  The 
nodes breaking has only been happening for the last several months.  The timing 
coincides with the user (who's new) starting to use the portal and also helps 
explain the uneven time sequence for when the nodes go down.  he's also showing 
up in each of the log files were the breakage occurs.  We haven't stress tested 
our portal in this way previously and it may be that this is the first time 
we've seen a user with this large number of groups.

I'll follow up here either way to verify if the fix works for our user or if 
there is still an error.

Thanks again.
Bill Brown
Web Application Developer, Web Services
IT Services, The University of Chicago

From: bounce-26677930-50353...@lists.wisc.edu 
[bounce-26677930-50353...@lists.wisc.edu] on behalf of Eric Dalquist 
[eric.dalqu...@doit.wisc.edu]
Sent: Thursday, January 17, 2013 12:10 PM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Issue with user layout not loading

We only use PAGs for groups so I personally haven't seen this problem.
What is the problematic behavior you're seeing for users in large
numbers of groups? Are you still seeing the NPE now that the separator
issue has been fixed?

-Eric

On 1/17/13 10:55 AM, Bill Brown wrote:

Hi Eric.

Thanks for the tip.  swapping in "::" for "." and swapping it out did resolve 
the truncated group issue for us.

That helped us rule it out and got us to the real issue.  We have at least one 
user, and maybe up to 100 users, in our system who are members of an abnormally 
large number of groups.  The user we found is a member in 1100+ groups.

Are there users in your system with memberships on this scale? I would think 
that users of the ldap or smart ldap group stores may run into something 
similar.

Maybe there is something in the core groups service that has an issue dealing 
with large numbers of groups.  We would like to further debug this but are 
looking for yet more clues about the groups service system in general.

We see in our example we can retrieve the initial list of groups from the group 
service (grouper in our case) for the user above.  There about 1100+ results.  
After that, the portal again queries the group service for each of these 1100+ 
groups.  Its during this second query that the portal receives a null pointer 
exception.   Then the portal breaks and everyone who tries to access the node 
after that fails with the same NPE trace as our 1100+ user.

Apologies for the brain dump here but were not exactly sure what to try next 
and want to here if anyone else has run into an issue like this?  Should I post 
this to the user list as well?

Thanks again for your help.
Bill Brown
Web Application Developer, Web Services
IT Services, The University of Chicago

From: bounce-26662712-50353...@lists.wisc.edu 
[bounce-26662712-50353...@lists.wisc.edu] on behalf of Eric Dalquist 
[eric.dalqu...@doit.wisc.edu]
Sent: Wednesday, January 16, 2013 10:09 AM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Issue with user layout not loading

So changing the key seperator in theory is possible but you'd probably
have to do it on a clean database pre-import for it to work.

What would be better would be to modify the grouper group service to
replace '.' with another character immediately after it comes back from
the grouper API, maybe a ' '? That should fix the parsing error in GAP.

-Eric

On 1/12/13 10:27 PM, Bill Brown wrote:

Thanks for the tip Eric.

Looks like the keys for some of our grouper groups are being truncated when 
being created as a CompositeEntityIdentifier.  We were using these keys to 
cache results from the grouper service to reduce the number of repeated calls 
to grouper.  For example a grouper group key that looks like

uc:Reference:studentinfo:citizenshipstatus:U.S. Citizen

becomes this composite group

"grouper. Citizen"

instead of

"grouper.uc:Reference:studentinfo:citizenshipstatus:U.S. Citizen"

The null pointers were popping in because the shortened keys don't exist when 
querying the cache.

So I tried changing the nodeSeparator character from "." to "::" in 
compositeGroupService.xml but got a bunch of these err

Re: [uportal-dev] Issue with user layout not loading

[Eric Dalquist]

We only use PAGs for groups so I personally haven't seen this problem. 
What is the problematic behavior you're seeing for users in large 
numbers of groups? Are you still seeing the NPE now that the separator 
issue has been fixed?


-Eric

On 1/17/13 10:55 AM, Bill Brown wrote:

Hi Eric.

Thanks for the tip.  swapping in "::" for "." and swapping it out did resolve 
the truncated group issue for us.

That helped us rule it out and got us to the real issue.  We have at least one 
user, and maybe up to 100 users, in our system who are members of an abnormally 
large number of groups.  The user we found is a member in 1100+ groups.

Are there users in your system with memberships on this scale? I would think 
that users of the ldap or smart ldap group stores may run into something 
similar.

Maybe there is something in the core groups service that has an issue dealing 
with large numbers of groups.  We would like to further debug this but are 
looking for yet more clues about the groups service system in general.

We see in our example we can retrieve the initial list of groups from the group 
service (grouper in our case) for the user above.  There about 1100+ results.  
After that, the portal again queries the group service for each of these 1100+ 
groups.  Its during this second query that the portal receives a null pointer 
exception.   Then the portal breaks and everyone who tries to access the node 
after that fails with the same NPE trace as our 1100+ user.

Apologies for the brain dump here but were not exactly sure what to try next 
and want to here if anyone else has run into an issue like this?  Should I post 
this to the user list as well?

Thanks again for your help.
Bill Brown
Web Application Developer, Web Services
IT Services, The University of Chicago

From: bounce-26662712-50353...@lists.wisc.edu 
[bounce-26662712-50353...@lists.wisc.edu] on behalf of Eric Dalquist 
[eric.dalqu...@doit.wisc.edu]
Sent: Wednesday, January 16, 2013 10:09 AM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Issue with user layout not loading

So changing the key seperator in theory is possible but you'd probably
have to do it on a clean database pre-import for it to work.

What would be better would be to modify the grouper group service to
replace '.' with another character immediately after it comes back from
the grouper API, maybe a ' '? That should fix the parsing error in GAP.

-Eric

On 1/12/13 10:27 PM, Bill Brown wrote:

Thanks for the tip Eric.

Looks like the keys for some of our grouper groups are being truncated when 
being created as a CompositeEntityIdentifier.  We were using these keys to 
cache results from the grouper service to reduce the number of repeated calls 
to grouper.  For example a grouper group key that looks like

uc:Reference:studentinfo:citizenshipstatus:U.S. Citizen

becomes this composite group

"grouper. Citizen"

instead of

"grouper.uc:Reference:studentinfo:citizenshipstatus:U.S. Citizen"

The null pointers were popping in because the shortened keys don't exist when 
querying the cache.

So I tried changing the nodeSeparator character from "." to "::" in 
compositeGroupService.xml but got a bunch of these errors below and am not sure how to proceed.  Is 
it possible to change the composite key seperator character without getting the errors or maybe it 
should stay as the default and work around something in the CompositieEntityIdentifier?

WARN  2013-01-12 22:57:49,519  [JCLLoggerAdapter.warn(ln:359)] - No portlet 
window found for: channel

ERROR 2013-01-12 22:57:49,522  [JCLLoggerAdapter.error(ln:534)] - Faild to 
create IPortalUrlBuilder for fname='feedback-portlet', layoutId='', type=''. # 
will be returned instead.

java.lang.IllegalArgumentException: Could not find PortletWindow for 
fname=feedback-portlet to create IPortalUrlBuilder
   at 
org.jasig.portal.url.PortalUrlProviderImpl.getPortalUrlBuilderByPortletFName(PortalUrlProviderImpl.java:159)
   at 
org.jasig.portal.url.xml.XsltPortalUrlProvider.getPortalUrlBuilder(XsltPortalUrlProvider.java:95)
   at universality.portalUrl()
   at universality.header$dot$block()
   at universality.template$dot$4()
   at universality.applyTemplates()
   at universality.template$dot$3()
   at universality.applyTemplates()
   at universality.applyTemplates()
   at universality.transform()
   at 
com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:602)
   at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709)
   at 
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
   at 
org.jasig.portal.rendering.xslt.XSLTComponent.getEventReader(XSLTCom

Re: [uportal-dev] CMS SearchResult titles in search

[Eric Dalquist]

I'd love to see the changes.

-Eric

On 1/17/13 6:16 AM, Viktors Jengovatovs wrote:

Hi!

Now I making better search for our portal, and have question about CMS.
When user calls search in portal and have some results in CMS, these
results have title "cms".
SearchContentController.java in CMS 1.0.2 code have line:
searchResult.setTitle(this.portletConfig.getPortletName());

It is problem or not?

And I one proposal, to add some default type to all CMS portlets by
default (like this: result.getType().add("CMS"); ).

PS. after my modifications, I have some simple changes in uPortal's
search.jsp file, which looking like dasboard (some records from every
tab are located in default tab).
I can share it if need.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Vote: uPortal Steering Committee Representative

[Eric Dalquist]

+1
On 1/17/13 8:37 AM, Tuyhang Ly wrote:

+1

On 1/17/13 10:27 AM, Jim Helwig wrote:
Gary's email reminded me that I need to officially wrap up the 
election process (which I neglected to do over the holidays).


We have only one nominee for the vacant developer representative on 
the uPortal Steering Committee: the esteemed Drew Wills. Just to make 
it official, would committers please respond with a "+1" if you agree 
that Drew should join the uPSC (along with the other current 
developer representative, Eric Dalquist)? We'll give it an extra day 
and close the voting at 11 AM ET Monday, 1/21.


JimH
uPSC Chair










smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

[Eric Dalquist]

Ah! So in this external jar you need to declare uportal-war-classes as a 
*provided* dependency. That way it will be available to the jar at 
compile time but not pulled into the actual uportal-war classpath.


-Eric


On 1/16/13 4:51 PM, Paul Gazda wrote:


The jar is a dependency in the uportal-war pom.xml. In uP3 it is a 
dependency in uportal-impl pom.xml and ends up in the 
uPortal/WEB-INF/lib directory.


Paul

*From:*bounce-2283-5712...@lists.wisc.edu 
[mailto:bounce-2283-5712...@lists.wisc.edu] *On Behalf Of *Eric 
Dalquist

*Sent:* Wednesday, January 16, 2013 4:29 PM
*To:* uportal-dev@lists.ja-sig.org
*Subject:* Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

Where does this code end up living/running? Is it a jar that gets put 
into the uPortal webapp?


-Eric

On 1/16/13 1:53 PM, Paul Gazda wrote:

I didn't write the code, so I'm not completely familiar with the
details, but basically our custom student center is a collection
of servlets accessed by ajax calls. The custom module references
uportal-war to gain access to the personManager spring bean so
that it can get the ID of the authenticated student using the
portal and then retrieve the class and other information for the
student from our student database. This works without problems in uP3.

Paul

*From:*bounce-26662737-5712...@lists.wisc.edu
<mailto:bounce-26662737-5712...@lists.wisc.edu>
[mailto:bounce-26662737-5712...@lists.wisc.edu] *On Behalf Of
    *Eric Dalquist
*Sent:* Wednesday, January 16, 2013 9:12 AM
*To:* uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org>
*Subject:* Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

Honestly uportal-war isn't meant to be used as a dependency by
other code. I'd be interested in what exactly you're using out of
uportal-war and see if we can get a better solution on our roadmap
for you.

Lots of things beyond just this are likely going to break or act
in undefined ways when you have the entire uPortal project on the
classpath twice (what having -classes.jar and the /target/classes
dir results in).

-Eric

On 1/15/13 11:12 AM, Paul Gazda wrote:

In uP 4.0.8, I have a dependency jar defined in the
uportal-war pom.xml that uses hibernate. It is part of an
important custom student center portlet that we use. When I
include it and run deploy-war, I get many test failures with
this error:

Caused by: java.lang.IllegalStateException: Conflicting
persistence unit definitions for name 'PortalDb':

file:/C:/Users/pag/.m2/repository/org/jasig/portal/uportal-war/4.0.8/uportal-war-4.0.8-classes.jar

,
file:/C:/JavaClasses/uportal.git/uportal-war/target/classes



This seems to be related to a bug in Spring reported here:
http://www.mulesoft.org/jira/browse/MULE-6241

When I change the spring version to 3.2.0, the test errors go
away, but uportal does not start because of spring related errors.

There seems to be a way of overriding a spring 3.1.3 method to
work around the problem, but not being very familiar with
spring, I find it very confusing as to how an internal spring
method is overridden.

Unless there is something fairly straightforward that will fix
this problem, I'm wondering if it would be possible to upgrade
to spring 3.2.0 in the next release of uP4.

Thanks.

Paul Gazda

-- 

  


You are currently subscribed touportal-...@lists.ja-sig.org  
<mailto:uportal-dev@lists.ja-sig.org>  as:eric.dalqu...@doit.wisc.edu  
<mailto:eric.dalqu...@doit.wisc.edu>

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev

-- 

  


You are currently subscribed touportal-...@lists.ja-sig.org  
<mailto:uportal-dev@lists.ja-sig.org>  as:eric.dalqu...@doit.wisc.edu  
<mailto:eric.dalqu...@doit.wisc.edu>

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

[Eric Dalquist]

Where does this code end up living/running? Is it a jar that gets put 
into the uPortal webapp?


-Eric

On 1/16/13 1:53 PM, Paul Gazda wrote:


I didn't write the code, so I'm not completely familiar with the 
details, but basically our custom student center is a collection of 
servlets accessed by ajax calls. The custom module references 
uportal-war to gain access to the personManager spring bean so that it 
can get the ID of the authenticated student using the portal and then 
retrieve the class and other information for the student from our 
student database. This works without problems in uP3.


Paul

*From:*bounce-26662737-5712...@lists.wisc.edu 
[mailto:bounce-26662737-5712...@lists.wisc.edu] *On Behalf Of *Eric 
Dalquist

*Sent:* Wednesday, January 16, 2013 9:12 AM
*To:* uportal-dev@lists.ja-sig.org
*Subject:* Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

Honestly uportal-war isn't meant to be used as a dependency by other 
code. I'd be interested in what exactly you're using out of 
uportal-war and see if we can get a better solution on our roadmap for 
you.


Lots of things beyond just this are likely going to break or act in 
undefined ways when you have the entire uPortal project on the 
classpath twice (what having -classes.jar and the /target/classes dir 
results in).


-Eric

On 1/15/13 11:12 AM, Paul Gazda wrote:

In uP 4.0.8, I have a dependency jar defined in the uportal-war
pom.xml that uses hibernate. It is part of an important custom
student center portlet that we use. When I include it and run
deploy-war, I get many test failures with this error:

Caused by: java.lang.IllegalStateException: Conflicting
persistence unit definitions for name 'PortalDb':

file:/C:/Users/pag/.m2/repository/org/jasig/portal/uportal-war/4.0.8/uportal-war-4.0.8-classes.jar

,
file:/C:/JavaClasses/uportal.git/uportal-war/target/classes


This seems to be related to a bug in Spring reported here:
http://www.mulesoft.org/jira/browse/MULE-6241

When I change the spring version to 3.2.0, the test errors go
away, but uportal does not start because of spring related errors.

There seems to be a way of overriding a spring 3.1.3 method to
work around the problem, but not being very familiar with spring,
I find it very confusing as to how an internal spring method is
overridden.

Unless there is something fairly straightforward that will fix
this problem, I'm wondering if it would be possible to upgrade to
spring 3.2.0 in the next release of uP4.

Thanks.

Paul Gazda

-- 

  


You are currently subscribed touportal-...@lists.ja-sig.org  
<mailto:uportal-dev@lists.ja-sig.org>  as:eric.dalqu...@doit.wisc.edu  
<mailto:eric.dalqu...@doit.wisc.edu>

To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issues due to possible spring 3.1.3 bug

[Eric Dalquist]

Honestly uportal-war isn't meant to be used as a dependency by other 
code. I'd be interested in what exactly you're using out of uportal-war 
and see if we can get a better solution on our roadmap for you.


Lots of things beyond just this are likely going to break or act in 
undefined ways when you have the entire uPortal project on the classpath 
twice (what having -classes.jar and the /target/classes dir results in).


-Eric


On 1/15/13 11:12 AM, Paul Gazda wrote:


In uP 4.0.8, I have a dependency jar defined in the uportal-war 
pom.xml that uses hibernate. It is part of an important custom student 
center portlet that we use. When I include it and run deploy-war, I 
get many test failures with this error:


Caused by: java.lang.IllegalStateException: Conflicting persistence 
unit definitions for name 'PortalDb': 
file:/C:/Users/pag/.m2/repository/org/jasig/portal/uportal-war/4.0.8/uportal-war-4.0.8-classes.jar, 
file:/C:/JavaClasses/uportal.git/uportal-war/target/classes


This seems to be related to a bug in Spring reported here: 
http://www.mulesoft.org/jira/browse/MULE-6241 



When I change the spring version to 3.2.0, the test errors go away, 
but uportal does not start because of spring related errors.


There seems to be a way of overriding a spring 3.1.3 method to work 
around the problem, but not being very familiar with spring, I find it 
very confusing as to how an internal spring method is overridden.


Unless there is something fairly straightforward that will fix this 
problem, I'm wondering if it would be possible to upgrade to spring 
3.2.0 in the next release of uP4.


Thanks.

Paul Gazda

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issue with user layout not loading

[Eric Dalquist]

pringframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter.doFilter(AbstractPreAuthenticatedProcessingFilter.java:88)
at 
org.jasig.portal.spring.security.preauth.PortalPreAuthenticatedProcessingFilter.doFilter(PortalPreAuthenticatedProcessingFilter.java:161)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
at 
org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
at 
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
at 
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:173)
at 
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at 
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:147)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.jasig.portal.utils.web.ExceptionLoggingFilter.doFilter(ExceptionLoggingFilter.java:40)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
com.googlecode.psiprobe.Tomcat60AgentValve.invoke(Tomcat60AgentValve.java:30)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at 
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:662)

Thanks again for your help

Bill Brown

From: bounce-26628435-50353...@lists.wisc.edu 
[bounce-26628435-50353...@lists.wisc.edu] on behalf of Eric Dalquist 
[eric.dalqu...@doit.wisc.edu]
Sent: Saturday, January 12, 2013 1:43 PM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Issue with user layout not loading

Looks like IGroupMember.getContainingGroups() returned an Iterator that
contains 1 or more null elements. This is not OK in the groups API.
Considering the log message about Grouper I'd take a look at that group
store impl to see if it can exhibit this behavior.

-Eric


On 1/12/13 11:12 AM, Bill Brown wrote:

Hello uPortal Devs.

We've been having an increasing issue with our portal instances (4.0.5 6 node 
cluster) failing to load the layout for the guest user and also for current 
users if they are logged in.  At request from Eric,  I added some debug 
statements to DistributedLayoutManager try to uncover what might be happening. 
Here is an additional trace that was being covered up previously.  Can you make 
out what might be null here or what we could try on our end to stop this from 
happening?

INFO  2013-01-12 12:30:41,732  [GrouperEntityGroupStore.find(ln:141)] - 
Searching Grouper for a direct match for key:  Citizen

ERROR 2013-01-12 12:30:41,802  
[DistributedLayoutManager.getDistributedUserLayout(ln:282)] - error getting 
distributed user layout for guest:

java.lang.NullPointerException
   

Re: [uportal-dev] Issue with user layout not loading

[Eric Dalquist]

Looks like IGroupMember.getContainingGroups() returned an Iterator that 
contains 1 or more null elements. This is not OK in the groups API. 
Considering the log message about Grouper I'd take a look at that group 
store impl to see if it can exhibit this behavior.


-Eric


On 1/12/13 11:12 AM, Bill Brown wrote:

Hello uPortal Devs.

We've been having an increasing issue with our portal instances (4.0.5 6 node 
cluster) failing to load the layout for the guest user and also for current 
users if they are logged in.  At request from Eric,  I added some debug 
statements to DistributedLayoutManager try to uncover what might be happening. 
Here is an additional trace that was being covered up previously.  Can you make 
out what might be null here or what we could try on our end to stop this from 
happening?

INFO  2013-01-12 12:30:41,732  [GrouperEntityGroupStore.find(ln:141)] - 
Searching Grouper for a direct match for key:  Citizen

ERROR 2013-01-12 12:30:41,802  
[DistributedLayoutManager.getDistributedUserLayout(ln:282)] - error getting 
distributed user layout for guest:

java.lang.NullPointerException
at 
org.jasig.portal.groups.GroupMemberImpl.primGetAllContainingGroups(GroupMemberImpl.java:344)
at 
org.jasig.portal.groups.GroupMemberImpl.primGetAllContainingGroups(GroupMemberImpl.java:351)
at 
org.jasig.portal.groups.GroupMemberImpl.getAllContainingGroups(GroupMemberImpl.java:139)
at 
org.jasig.portal.security.provider.AuthorizationImpl.primGetPermissionsForPrincipal(AuthorizationImpl.java:914)
at 
org.jasig.portal.security.provider.AuthorizationImpl.getPermissionsForPrincipal(AuthorizationImpl.java:655)
at 
org.jasig.portal.security.provider.AnyUnblockedGrantPermissionPolicy.doesPrincipalHavePermission(AnyUnblockedGrantPermissionPolicy.java:100)
at 
org.jasig.portal.security.provider.AnyUnblockedGrantPermissionPolicy.doesPrincipalHavePermission(AnyUnblockedGrantPermissionPolicy.java:91)
at 
org.jasig.portal.security.provider.AuthorizationImpl.doesPrincipalHavePermission(AuthorizationImpl.java:455)
at 
org.jasig.portal.security.provider.AuthorizationImpl.doesPrincipalHavePermission(AuthorizationImpl.java:427)
at 
org.jasig.portal.security.provider.AuthorizationImpl.canPrincipalSubscribe(AuthorizationImpl.java:401)
at 
org.jasig.portal.security.provider.AuthorizationImpl.canPrincipalRender(AuthorizationImpl.java:357)
at 
org.jasig.portal.security.provider.AuthorizationPrincipalImpl.canRender(AuthorizationPrincipalImpl.java:84)
at 
org.jasig.portal.layout.dlm.ILFBuilder.mergeAllowed(ILFBuilder.java:188)
at 
org.jasig.portal.layout.dlm.ILFBuilder.mergeChildren(ILFBuilder.java:152)
at 
org.jasig.portal.layout.dlm.ILFBuilder.mergeChildren(ILFBuilder.java:159)
at 
org.jasig.portal.layout.dlm.ILFBuilder.mergeChildren(ILFBuilder.java:159)
at 
org.jasig.portal.layout.dlm.ILFBuilder.mergeFragment(ILFBuilder.java:114)
at 
org.jasig.portal.layout.dlm.ILFBuilder.constructILF(ILFBuilder.java:94)
at 
org.jasig.portal.layout.dlm.RDBMDistributedLayoutStore.getCompositeLayout(RDBMDistributedLayoutStore.java:1376)
at 
org.jasig.portal.layout.dlm.RDBMDistributedLayoutStore._getUserLayout(RDBMDistributedLayoutStore.java:1204)
at 
org.jasig.portal.layout.dlm.RDBMDistributedLayoutStore.getUserLayout(RDBMDistributedLayoutStore.java:379)
at sun.reflect.GeneratedMethodAccessor436.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:196)
at $Proxy171.getUserLayout(Unknown Source)
at 
org.jasig.portal.layout.dlm.DistributedLayoutManager.getDistributedUserLayout(DistributedLayoutManager.java:235)
at 
org.jasig.portal.layout.dlm.DistributedLayoutManager.getUserLayoutDOM(DistributedLayoutManager.java:221)
at 
org.jasig.portal.layout.dlm.DistributedLayoutManager.loadUserLayout(DistributedLayoutManager.java:338)
at 
org.jasig.portal.layout.dlm.DistributedLayoutManager.loadUserLayout(DistributedLayoutManager.java:327)
at 
org.jasig.portal.layout.dlm.DistributedLayoutManager.afterPropertiesSet(DistributedLayoutManager.java:178)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at 
org.springfra

Re: [uportal-dev] Hibernate 4.1.9 & the jTDS (SQL Server) driver

[Eric Dalquist]

Yeah, we've seen that same error reported on the lists with some older 
Oracle drivers as well though the 11.x series work correctly.


I'll see if I can get a JDK7 nightly build of 4.0 setup early next week 
so we can verify that it works there as well.


-Eric


On 1/11/13 3:51 PM, Makarov, Konstantin V. wrote:


Erik,

I was not aware of the importance of the NaturalID feature.

Before Drew suggested rolling back to 4.1.6 I was about to look at the 
MS JDBC 4.0 driver. I think I'll give it a try with hibernate 4.1.9.


Is anybody running 4.0.9 on JDK7 already? I may give it a try as well.

BTW, below is the exception I was getting when trying to import some 
portlet-definition files.


java.lang.AbstractMethodError: 
net.sourceforge.jtds.jdbc.JtdsPreparedStatement.setCharacterStream


Thank you,

Kostya

*From:*bounce-26616313-58214...@lists.wisc.edu 
[mailto:bounce-26616313-58214...@lists.wisc.edu] *On Behalf Of *Eric 
Dalquist

*Sent:* Friday, January 11, 2013 5:01 PM
*To:* uportal-dev@lists.ja-sig.org
*Subject:* Re: [uportal-dev] Hibernate 4.1.9 & the jTDS (SQL Server) 
driver


uPortal 4.0.9 should run on JDK7, I'm not sure about build time issues 
but they should be easy to resolved and it would be nice if 4.0.10 
could build and run on both 6 and 7. I already did work so that 4.0.10 
will run on Tomcat 6 and 7.


While I realize we need to get a real solution out it seems rather 
poor of jTDS to not support the JDBC4 spec with a JDK6 driver since 
the JDBC4 spec was _part of_ the JDK6 release.


Hibernate 4.1.7, 4.1.8, and 4.1.9 all contain patches for the 
NaturalID feature that uPortal 4.0 is using heavily and can be 
affected by in some cases. I'd be strongly opposed to rolling back the 
hibernate dependency and potentially introducing bugs that would 
affect everyone due to jTDS's poor API tracking.


Honestly I'd get start a thread with jTDS and then cross-post it to 
the uportal-user email list encouraging everyone that uses MSSQL to 
chime in. Its rather poor form that they don't support a JDBC API that 
has existed since day one in Java 6 (as far as I can tell anyways)


-Eric

On 1/11/13 2:37 PM, Drew Wills wrote:

Hey folks,

Kostya at SCSU brought an issue to my attention that I think is
worth noting...

It seems that -- starting with v4.1.7 -- Hibernate requires JDBC4
support:

  - https://hibernate.onjira.com/browse/HHH-7778

But the jTDS driver is targeting JDBC4 for their 1.3 line:

  -

http://sourceforge.net/p/jtds/news/2012/10/jtds-jdbc-driver-127-and-130-released/

JTDS is a popular 3rd-party driver for MS SQL Server.

The issue is that 1.3 also (apparently) _requires_ Java 7. I know
there has been much recent work to support Java 7... where are we
on that?  Is that (as I seem to remember) a uP 4.1 only thing?

The uP4 manual still says Java 7 not supported:

  - https://wiki.jasig.org/display/UPM40/Requirements

I have suggested that _perhaps_ rolling the version of hibernate
back (from 4.1.9 currently) to 4.1.6 would allow the most recent
jTDS 1.2 driver to work.

drew

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Hibernate 4.1.9 & the jTDS (SQL Server) driver

[Eric Dalquist]

uPortal 4.0.9 should run on JDK7, I'm not sure about build time issues 
but they should be easy to resolved and it would be nice if 4.0.10 could 
build and run on both 6 and 7. I already did work so that 4.0.10 will 
run on Tomcat 6 and 7.


While I realize we need to get a real solution out it seems rather poor 
of jTDS to not support the JDBC4 spec with a JDK6 driver since the JDBC4 
spec was _part of_ the JDK6 release.


Hibernate 4.1.7, 4.1.8, and 4.1.9 all contain patches for the NaturalID 
feature that uPortal 4.0 is using heavily and can be affected by in some 
cases. I'd be strongly opposed to rolling back the hibernate dependency 
and potentially introducing bugs that would affect everyone due to 
jTDS's poor API tracking.


Honestly I'd get start a thread with jTDS and then cross-post it to the 
uportal-user email list encouraging everyone that uses MSSQL to chime 
in. Its rather poor form that they don't support a JDBC API that has 
existed since day one in Java 6 (as far as I can tell anyways)


-Eric


On 1/11/13 2:37 PM, Drew Wills wrote:

Hey folks,

Kostya at SCSU brought an issue to my attention that I think is worth 
noting...


It seems that -- starting with v4.1.7 -- Hibernate requires JDBC4 
support:


  - https://hibernate.onjira.com/browse/HHH-7778

But the jTDS driver is targeting JDBC4 for their 1.3 line:

  - 
http://sourceforge.net/p/jtds/news/2012/10/jtds-jdbc-driver-127-and-130-released/


JTDS is a popular 3rd-party driver for MS SQL Server.

The issue is that 1.3 also (apparently) _requires_ Java 7.  I know 
there has been much recent work to support Java 7... where are we on 
that?  Is that (as I seem to remember) a uP 4.1 only thing?


The uP4 manual still says Java 7 not supported:

  - https://wiki.jasig.org/display/UPM40/Requirements

I have suggested that _perhaps_ rolling the version of hibernate back 
(from 4.1.9 currently) to 4.1.6 would allow the most recent jTDS 1.2 
driver to work.


drew





smime.p7s
Description: S/MIME Cryptographic Signature

Re:[uportal-dev] uPortal 4.0.9 Released

[Eric Dalquist]

  
  
The 4.0.9.1 release has been cut. I'm keeping the same 4.0.9 release
pages and just updated the download links. The 4.0.9.1 Maven
artifacts should be available in the next few hours. Sorry for the
mixup, I'll blame the new year :)

-Eric

On 1/3/13 4:15 PM, Eric Dalquist wrote:


  
  I just realized there is a minor bug in the 4.0.9 release. The
  three 4.0.8 values here

in applicationContext.xml should actually be 4.0.9. I'll cut
  a 4.0.9.1 release tomorrow morning to fix this.
  
  This will only affect people upgrading from 4.0.8, if you are
  upgrading from an earlier version it will have no effect.
  
  -Eric
  
  On 01/03/2013 03:47 PM, Eric Dalquist
wrote:
  
  


Apereo is
proud to announce uPortal 4.0.9, continuing in our regular
patch releases of uPortal 4.0. This release addresses a
number of minor bugs and one moderate security bug. For the
security bug any user with access to user-administration
would also be able to craft a URL to use the impersonation
feature even if the user lacked the impersonation
permission. This has been addressed via commits 3636ac and 8679f6 for those interested
in applying just the fix without upgrading to 4.0.9. This
release also includes two new statistics reports that show
Tab and Portlet execution counts broken down by group and
tab/portlet, thanks to Unicon's cooperative development
program for these reporting tools. Finally

a bug related to cached group and permission data has been
resolved such that at login existing attribute, group, and
permission information about the user is completely purged
to ensure a fresh session.
Features and
  Changes of Note

  [UP-3626]
- Users with access to User Administration can impersonate
any user regardless of "IMPERSONATE" permission settings
  [UP-3625]
- Add report for Tab Render count
  [UP-3628]
- Add report for portlet execution count


  Updating from
4.0.0-4.0.5
  

  

  
  
If you have
  data you care about in the
  UP_LOGIN_EVENT_AGGREGATE table please back it up
  externally or rename the table before executing
  the following steps. db-update will drop this
  table.
  

  

  
  After


configuring your uPortal 4.0.8 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-409
Release Notes: https://wiki.jasig.org/display/UPC/4.0.9
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.9/

Full Release Notes
Bug

  [UP-3083]
- Button styling in IE9 is not correct
  [UP-3254]
- uportal 4.0.2 + mysql specified key was too long issue
  [UP-3286]
- Tomcat examples available in uPortal demo
  [UP-3416]
- Portlet 286 Ajax requests: only the first ajax call is
processed
  [UP-3492]
- Content-Disposition cannot be set in ResourceResponse
  [UP-3550]
- portlet preferences (provided via config mode) are lost
when editing existing portlets
  [UP-3590]
- Portlet configuration does not display portlet.xml
parameters
  [UP-3598]
- Portlet Manager no longer displays preferences defined in
portlet.xml when you register a new portlet
  [UP-3613]
- Shibboleth and attributes user caching
  [UP-3616]
- Resource parameters not included in cache key generation
  [UP-3618]
- portlet admin : bug when setting up of preference readOnly
  [UP-3619]
- Fragment Administration portlet : Edit Page/Colum
Permissions
  [UP-3627]
- Pluto doesn't handle setting of Content-Type via headers
correctly
  [UP-3630]
- DAO_PING fails on MySQL
  [UP-3633]
- PortalDb DataSource not in JMX

Improvement

  [UP-3456]
- Streamline SASS implementation
  [UP-3478]
- Disable scheduled background tasks during uPShell
execution
  [UP-3535]
- Enhance UserAccountHel

Re:[uportal-dev] uPortal 4.0.9 Released

[Eric Dalquist]

  
  
I just realized there is a minor bug in the 4.0.9 release. The three
4.0.8 values here
  in applicationContext.xml should actually be 4.0.9. I'll cut a
4.0.9.1 release tomorrow morning to fix this.

This will only affect people upgrading from 4.0.8, if you are
upgrading from an earlier version it will have no effect.

-Eric

On 01/03/2013 03:47 PM, Eric Dalquist
  wrote:


  
  
  Apereo is proud to
  announce uPortal 4.0.9, continuing in our regular patch
  releases of uPortal 4.0. This release addresses a number of
  minor bugs and one moderate security bug. For the security bug
  any user with access to user-administration would also be able
  to craft a URL to use the impersonation feature even if the
  user lacked the impersonation permission. This has been
  addressed via commits 3636ac and 8679f6 for those interested
  in applying just the fix without upgrading to 4.0.9. This
  release also includes two new statistics reports that show Tab
  and Portlet execution counts broken down by group and
  tab/portlet, thanks to Unicon's cooperative development
  program for these reporting tools. Finally
  a bug related to cached group and permission data has been
  resolved such that at login existing attribute, group, and
  permission information about the user is completely purged to
  ensure a fresh session.
  Features and Changes of
Note
  
[UP-3626] - Users
  with access to User Administration can impersonate any user
  regardless of "IMPERSONATE" permission settings
[UP-3625] - Add
  report for Tab Render count
[UP-3628] - Add
  report for portlet execution count
  
  
Updating from
  4.0.0-4.0.5

  

  


  If you have
data you care about in the UP_LOGIN_EVENT_AGGREGATE
table please back it up externally or rename the
table before executing the following steps.
db-update will drop this table.

  

  

After

  configuring your uPortal 4.0.8 source run:

  
ant db-update
  

Downloads: http://www.jasig.org/uportal/download/uportal-409
  Release Notes: https://wiki.jasig.org/display/UPC/4.0.9
  Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.9/
  
  Full Release Notes
  Bug
  
[UP-3083] - Button
  styling in IE9 is not correct
[UP-3254] - uportal
  4.0.2 + mysql specified key was too long issue
[UP-3286] - Tomcat
  examples available in uPortal demo
[UP-3416] - Portlet
  286 Ajax requests: only the first ajax call is processed
[UP-3492] -
  Content-Disposition cannot be set in ResourceResponse
[UP-3550] - portlet
  preferences (provided via config mode) are lost when editing
  existing portlets
[UP-3590] - Portlet
  configuration does not display portlet.xml parameters
[UP-3598] - Portlet
  Manager no longer displays preferences defined in portlet.xml
  when you register a new portlet
[UP-3613] -
  Shibboleth and attributes user caching
[UP-3616] -
  Resource parameters not included in cache key generation
[UP-3618] - portlet
  admin : bug when setting up of preference readOnly
[UP-3619] -
  Fragment Administration portlet : Edit Page/Colum Permissions
[UP-3627] - Pluto
  doesn't handle setting of Content-Type via headers correctly
[UP-3630] -
  DAO_PING fails on MySQL
[UP-3633] -
  PortalDb DataSource not in JMX
  
  Improvement
  
[UP-3456] -
  Streamline SASS implementation
[UP-3478] - Disable
  scheduled background tasks during uPShell execution
[UP-3535] - Enhance
  UserAccountHelper to invalidate cached objects it updates
[UP-3623] - Add
  LDAP Connection settings to Maven filters files
[UP-3634] - Add
  exception logging filter for all requests
[UP-3635] - Add
  Permanent Link feature to stats portlet
[UP-3636] - Include
  current username in thread naming
  
  New Feature
  
[UP-3625] - Add
  report for Tab Render count
[UP-3628] - Add
  report for portlet execution count
  
  Security Bug
  
[UP-3626] - Users
  with access to User Administration can impersonate any user
  regardless of

[uportal-dev] uPortal 4.0.9 Released

[Eric Dalquist]

  
  

Apereo is proud to announce uPortal 4.0.9, continuing
in our regular patch releases of uPortal 4.0. This release
addresses a number of minor bugs and one moderate security bug.
For the security bug any user with access to user-administration
would also be able to craft a URL to use the impersonation
feature even if the user lacked the impersonation permission.
This has been addressed via commits 3636ac and 8679f6 for those interested in
applying just the fix without upgrading to 4.0.9. This release
also includes two new statistics reports that show Tab and
Portlet execution counts broken down by group and tab/portlet,
thanks to Unicon's cooperative development program for these
reporting tools. Finally a bug related to
cached group and permission data has been resolved such that at
login existing attribute, group, and permission information
about the user is completely purged to ensure a fresh session.
Features and Changes of Note

  [UP-3626] - Users
with access to User Administration can impersonate any user
regardless of "IMPERSONATE" permission settings
  [UP-3625] - Add
report for Tab Render count
  [UP-3628] - Add
report for portlet execution count


  Updating from
4.0.0-4.0.5
  

  

  
  
If you have data
  you care about in the UP_LOGIN_EVENT_AGGREGATE table
  please back it up externally or rename the table
  before executing the following steps. db-update will
  drop this table.
  

  

  
  After
configuring your uPortal 4.0.8 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-409
Release Notes: https://wiki.jasig.org/display/UPC/4.0.9
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.9/

Full Release Notes
Bug

  [UP-3083] - Button
styling in IE9 is not correct
  [UP-3254] - uportal
4.0.2 + mysql specified key was too long issue
  [UP-3286] - Tomcat
examples available in uPortal demo
  [UP-3416] - Portlet
286 Ajax requests: only the first ajax call is processed
  [UP-3492] -
Content-Disposition cannot be set in ResourceResponse
  [UP-3550] - portlet
preferences (provided via config mode) are lost when editing
existing portlets
  [UP-3590] - Portlet
configuration does not display portlet.xml parameters
  [UP-3598] - Portlet
Manager no longer displays preferences defined in portlet.xml
when you register a new portlet
  [UP-3613] -
Shibboleth and attributes user caching
  [UP-3616] - Resource
parameters not included in cache key generation
  [UP-3618] - portlet
admin : bug when setting up of preference readOnly
  [UP-3619] - Fragment
Administration portlet : Edit Page/Colum Permissions
  [UP-3627] - Pluto
doesn't handle setting of Content-Type via headers correctly
  [UP-3630] - DAO_PING
fails on MySQL
  [UP-3633] - PortalDb
DataSource not in JMX

Improvement

  [UP-3456] -
Streamline SASS implementation
  [UP-3478] - Disable
scheduled background tasks during uPShell execution
  [UP-3535] - Enhance
UserAccountHelper to invalidate cached objects it updates
  [UP-3623] - Add LDAP
Connection settings to Maven filters files
  [UP-3634] - Add
exception logging filter for all requests
  [UP-3635] - Add
Permanent Link feature to stats portlet
  [UP-3636] - Include
current username in thread naming

New Feature

  [UP-3625] - Add
report for Tab Render count
  [UP-3628] - Add
report for portlet execution count

Security Bug

  [UP-3626] - Users
with access to User Administration can impersonate any user
regardless of "IMPERSONATE" permission settings

-Eric Dalquist
  



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.9 Release Plans

[Eric Dalquist]

Interesting. Can you describe the actual request/prefs interaction flow 
in more detail? A cursory test using the Jasig Test Portlet seems to 
show the correct behavior. Perhaps you could add a test case to that 
portlet to try and reproduce the problem then we'll have a continuing 
way to verify the functionality.


-Eric


On 12/31/12 11:58 AM, Misagh Moayyed wrote:

Eric,
I haven't actually been able to track this issue down at the portal level
to open a JIRA, but I have stumbled upon a rather strange an issue with
portlet preferences. Cross posted to @portlet-dev, the problem I have run
into is that portlet preferences do not seem to return the stored values
on subsequent calls on the portlet request object. Specifically, the email
preview portlet is one that I have been able to duplicate this issue
running against the latest master. When the portlet saves the
configuration, I see that all proper calls are made and values stored and
yet, on subsequent calls when the portlet actually goes to retrieve the
values, they are returned as null. I think the problem is at the portal
level somewhere as the portlet doesn't really do anything weird enough to
make me suspect something, but nevertheless, I haven't been able to step
through the code just yet.

To provide a little bit of context, the one preference value I have been
having trouble is the authenticationServiceKey, which gets properly set to
portletPreferences and yet comes back as null when the portlet goes to
retrieve the account configuration set. Drew had suggested that this may
be to a previous bug recently fixed that mixed up the handling of readonly
preference values, but I have pull that change and am running the latest
portal master. Something else must be interfering with the preferences
object.

I think I'll try and see if I can duplicate the issue with a simple
HelloWorld portlet first before stepping through the portal. My plan is to
save a couple of values into the preferences in the EDIT mode and retrieve
them in the VIEW mode. I'll post back shortly, but in the meanwhile, if
the dev team do get a chance to review this, it'd great help.

Regards,

-Misagh



-Original Message-
From: bounce-26511269-57692...@lists.wisc.edu [mailto:bounce-26511269-
57692...@lists.wisc.edu] On Behalf Of Eric Dalquist
Sent: Sunday, December 30, 2012 3:54 PM
To: uportal-dev@lists.ja-sig.org
Subject: [uportal-dev] 4.0.9 Release Plans

I'm planning on cutting 4.0.9 on the 3rd. Get your changes in or let me
know if there is a sore issue you'd like looked at before then!

-Eric







smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 4.0.9 Release Plans

[Eric Dalquist]

I'm planning on cutting 4.0.9 on the 3rd. Get your changes in or let me 
know if there is a sore issue you'd like looked at before then!


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] spring-portlet-contrib release

[Eric Dalquist]

Version 1.0.0 of the https://github.com/Jasig/spring-portlet-contrib
library has been released. This library is a collection of additions to
the Spring and Spring Security frameworks for portlet support. We are
planning on eventually getting all of the features provided here moved
into Spring proper but in the interim they will exist in this library.

Features of note in spring-webmvc-portlet-contrib:

  * 
http://developer.jasig.org/projects/spring-portlet-contrib/1.0.0/spring-webmvc-portlet-contrib/apidocs/index.html
  * Support for a portlet application level spring ApplicationContext,
this allows for portlet specific beans (they have access to the
PortletContext) that are shared among all portlets in the
application. Diagram of the context hierarchy.


  * GenericPortletFilterBean and DelegatingPortletFilterProxy, which are
direct clones of the classes that exist for the Servlet API but
provide support for the JSR286 portlet filter API
  * Portlet file-upload support for resource requests.

Features of note in spring-security-portlet-contrib:

  * 
http://developer.jasig.org/projects/spring-portlet-contrib/1.0.0/spring-security-portlet-contrib/apidocs/index.html
  * This provides complete spring-security support within a portlet. The
default configuration uses PortletRequest.getRemoteUser() to
determine the authenticated user and looks up the users roles via
the security-role-ref data in the portlet.xml. The source of user
roles can be easily customized to work with external role sources.
The authentication information is correctly stored and managed such
that all of the other spring-security features such as annotation
and jsp tag library permission checks work without any modification.

I'll be working on full documentation for both of these contrib
libraries as part of getting them included into Spring proper and will
post here when it is ready.

Here is the maven site for the project:
http://developer.jasig.org/projects/spring-portlet-contrib/1.0.0/

The artifacts should be in maven central in the next 12 hours.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Tomcat 7 for master

[Eric Dalquist]

I just pulled in a merge that switches master to use tomcat 7. I did a
very simple little test and the portal mostly works on tomcat 6.5 but
JSPs seem to fail based on the complexity of the JSTL and if it
references servlet 3.0 classes that are not in servlet 2.5

-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] GitHub Contributing Doc

[Eric Dalquist]

I added: https://github.com/Jasig/uPortal/blob/master/CONTRIBUTING.md

I believe people should see a link to to this when making pull requests. 
It is generic enough that it should be easy to copy and tweak very 
slightly for other projects.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal 4.0.8 GA Release Announcement

[Eric Dalquist]

  
  

Jasig is proud to announce
  the general audience release of uPortal 4.0.8. This release
  includes 20 bug fixes and improvements on top of the 4.0.6. The
  largest change in 4.0.7 is the inclusion of a statistics reporting
  portlet that integrates with the event aggregation added in 4.0.6.
Features and Changes of Note

  UP-3571 - JDK 7 is
now supported for both build and runtime environments
  UP-3602/UP-3597 - A Stats related timezone
bug has been resolved, this may result in a short gap in the
aggregated statistics data.


  Updating from
4.0.0-4.0.5
  

  

  
  
If you have data
  you care about in the UP_LOGIN_EVENT_AGGREGATE table
  please back it up externally or rename the table
  before executing the following steps. db-update will
  drop this table.
  

  

  
  After
configuring your uPortal 4.0.8 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-408
Release Notes: https://wiki.jasig.org/display/UPC/4.0.8
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.8/

Full Release Notes
Bug

  [UP-3569] - Add
overlay files for portlet log configuration
  [UP-3584] - Class
Cast Exception in GrouperEntityGroupStore
  [UP-3586] - New York
Times RSS Feed broken
  [UP-3594] - Sort
groups & intervals in stats portlet
  [UP-3595] - export
flag for db-update/init ant tasks is not honored
  [UP-3597] - Stats
portlet fails to work on certain intervals
  [UP-3602] - Unique
Constraint Violation
  [UP-3603] -
Statistics Portlet and spring mvc portlet annotation bug on
3.1.2 spring version
  [UP-3605] - Move
version update calls into PortalShellBuildHelper
  [UP-3608] -
OpenEntityManagerAspect does not correctly participate in
existing transactions
  [UP-3611] - Event
processing catch-up logic is wrong
  [UP-3612] - Closed
aggregations should not cause event processing failures
  [UP-3615] -
default.png URL in JSON feed broken

Improvement

  [UP-3571] - Add
support for Java 7
  [UP-3596] -
Consistent entity export list ordering
  [UP-3600] - Settings
in WebProxyPortlet's datasource.properties file should come from
the normal place (filters/ dir), not from the built version of
rdbm.properties
  [UP-3601] - Quote
username in SingleTabUrlNodeSyntaxHelper log message
  [UP-3606] - Add
version check to event processing
  [UP-3607] - Improve
jGroups peer discovery

New Feature

  [UP-3609] -
Automatically run db-update tasks on startup for patch and local
changes
    
    -Eric Dalquist
  



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Jasig Services Outage

[Eric Dalquist]

Confluence, Jira and Crowd will be down for patching between 3PM to 6PM
CDT on Nov 3. Bamboo will be down from 4PM to 5PM CST. In all likelihood
each service will only be down for 15-20 minutes during the outage
windows but there is always the possibility that the outages will go longer.

-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Since Shibboleth, admin etc doesn't work

[Eric Dalquist]

Can you please send this to the uportal-user list?

Thanks,
-Eric

On 10/23/12 11:05 AM, Sylvia White wrote:

Hi All:

Early last summer we moved from LDAP to Shibboleth.  What I didn't 
notice right away was that ...


1)  I can no longer login as any default user: admin, developer, etc.
2)  When I, an administrator, try to setup a new CMS portlet, no 
categories or user groups show up to choose from,

 and I get kicked out of the portlet creation flow

We have moved into a new stage of the portal rollout and I am 
desperate to do more setup.


Any ideas what might be going on?

Thanks!
--
=
Sylvia White
=
Smith College
Business Intelligence Developer
Information Technology Services
swh...@smith.edu 
Phone: 413-585-2614
=
--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Attribute Collection from College Database intermittently fails

[Eric Dalquist]

I replied on the uportal-user email list.

Thanks,
-Eric

On 10/22/2012 01:09 PM, Sylvia White wrote:
> Hi Everyone:
>
> We are having a problem currently with the attributes we pull in from
> our college database, Banner.  It is from these user attributes that
> we determine what tabs a user gets assigned.  It could work for days,
> then I will come in one morning and the attributes have not been
> collected and the affected tabs are not showing.  If I restart tomcat,
> the attributes and tabs return.
>
> Does anyone have an idea why this is happening?
>
> Thanks
>
> -- 
> =
> Sylvia
> White 
>
>
> =
> Smith College
> Business Intelligence Developer
> Information Technology Services  
> swh...@smith.edu
>    
> Phone: 413-585-2614   
> =
> -- 
>
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> eric.dalqu...@doit.wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev



smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal 4.0.7 Released

[Eric Dalquist]

  
  

Jasig is proud to announce
  the general audience release of uPortal 4.0.7. This release
  includes 34 bug fixes and improvements on top of the 4.0.6. The
  largest change in 4.0.7 is the inclusion of a statistics reporting
  portlet that integrates with the event aggregation added in 4.0.6.
Features and Changes of Note

  UP-3448 - A reporting portlet
has been added to work with the database persistent events and
event aggregation. The included reports are for Total Logins,
Unique Logins, and Concurrent Users.
  UP-3038 - The externalId layout
structure parameter is now used as part of the URL if specified.
The default layouts have been modified to specify an externalId
as an example.
  UP-3560 - Improved default
person-directory configuration to enable caching. Existing
deployers should review the new file for an example on how to
enable attribute retrieval caching.


  Updating from 4.0.0-4.0.5
  

  

  
  
If you have
  data you care about in the UP_LOGIN_EVENT_AGGREGATE
  table please back it up externally or rename the table
  before executing the following steps. db-update will
  drop this table.
  

  

  
  After
configuring your uPortal 4.0.7 source run:
  

  ant db-update

  
  Downloads: http://www.jasig.org/uportal/download/uportal-407
Release Notes: https://wiki.jasig.org/display/UPC/4.0.7
Maven Project Site: http://developer.jasig.org/projects/uportal/4.0.7/

Full Release Notes
Sub-task

  [UP-2869] - Improve usability of
person lookup flow
  [UP-3190] - Update the skin name
and thumb image in the gallery
  [UP-3448] - Create example login
stats portlet

Bug

  [UP-3040] - Portal page footer
in Japanese is wrapped
  [UP-3284] - 'Authenticated
Users' PAGS group bug -- PersonImpl.isGuest() reports false for
user 'guest' when called from within
...pags.testers.GuestUserTester
  [UP-3370] - No Portlets Listed
When Adding A New Portlet Category
  [UP-3469] - Group administration
not showing members until edit
  [UP-3500] - md5passwd Ant task
fails with ClassNotFoundException:
com.sun.xml.internal.bind.v2.ContextFactory
  [UP-3530] - Portlets without a
category are not handled well
  [UP-3544] - Switching to 1
column layout disables all of the other layouts
  [UP-3547] - Use portlet title
rather than name in mobile view
  [UP-3555] - Enable caching in
default person directory configuration
  [UP-3557] -
javax.portlet.escapeXml container option not working
  [UP-3558] - ant md5passwd broken
  [UP-3559] - Person Directory
sees queries for ALL, ALL_GROUPS, ALL_* pseudo targets
  [UP-3563] - Hung worker tracking
not working
  [UP-3565] - Portlet Manager
'User Editable' toggle for portlet preferences is broken
  [UP-3574] - Update web proxy
portlet to 1.1.7
  [UP-3575] -
UP_PORTLET_ENT.USER_ID is missing an index
  [UP-3582] - Current
implementation of UrlStringBuilder doesn't work with compound
context names
  [UP-3583] - dbtest never
completes
  [UP-3587] - When you click on a
specific person in the Search portlet results, the entire list
of results is re-displayed in the Directory portlet
  [UP-3588] - Pluto mis-parses
escapeXml portlet.xml setting
  [UP-3589] - Improve default
database pooling config
  [UP-3591] - NULL portlet
preference value returend even if default vaue is provided

Improvement

  [UP-2593] - Create User
Management Portlet
  [UP-3038] - Use tab externalId
in URL if present
  [UP-3556] - Update
JasigWidgetPortlets to 1.0.3
  [UP-3560] - Enable caching for
default person directory configuration
  [UP-3561] - Improve default ldap
pooling configuration
  [UP-3593] - Make quickstart
scripts wait for tomcat/hsql

Task

  [UP-3548] - Update bundled
email-preview portlet to version 2.0.1
  [UP-3579] - Update the bundled
NewsReaderPortlet to version 3.0.3
  [UP-3592] - Remove old/broken
ant targets

-Eric Dalquist
  



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

No problem and sorry for the delay, its been a rough few weeks for me 
with house problems.


I probably wont get 4.0.7 cut until this evening so if you get a chance 
to test out the change I just pushed that would be great.


-Eric

On 10/8/12 9:50 AM, Arvīds Grabovskis wrote:
Yes, that's exactly why I wanted someone to confirm the patch. Both 
portlet spec and API docs are a bit vague regarding this point, but 
your explanation seems reasonable.


Thank you for your time, this was very important to us.

-- Arvīds


2012/10/8 Eric Dalquist <mailto:eric.dalqu...@doit.wisc.edu>>


Sorry, I meant to reply to this.

The problem is the spec PDF and the JavaDocs aren't perfectly
clear. In PLT.17.1 the spec says "Preference attributes are String
array objects. Preferences attributes can be set to null"

I agree with the change on line 154
<https://github.com/Jasig/uPortal/pull/78/files#L0L154>If there is
no values array set the default value should be returned. This
should fix the problem you had of defining a preference with not
values in the portlet.xml.

However the change on line 157
<https://github.com/Jasig/uPortal/pull/78/files#L0L157> would
break the preferences object according to the spec as it would
prevent a portlet from correctly storing null in the first element
of the preference values array.

I will apply the first change before 4.0.7 is cut.

-Eric



On 10/8/12 4:43 AM, Arvīds Grabovskis wrote:

Jumping in the last moment, but I hope that you could review this
<https://github.com/Jasig/uPortal/pull/78> pull request and apply
it to trunk and 4.1.patches.

-- Arvīds


2012/10/6 Eric Dalquist mailto:eric.dalqu...@doit.wisc.edu>>

I'm back getting actual work done and will plan on cutting
4.0.7 monday. I reviewed all changes on master and merged
what I thought applied back to 4.0-patches. I'll be going
through Jira tonight to see if there is any low-hanging fruit
and then plan on cutting the release Monday. I'll also be
cutting a new resource server release on Sunday so if anyone
has any changes be sure to get them in.

-Eric


-- 


You are currently subscribed touportal-...@lists.ja-sig.org  
<mailto:uportal-dev@lists.ja-sig.org>  as:eric.dalqu...@doit.wisc.edu  
<mailto:eric.dalqu...@doit.wisc.edu>
To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev



--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

Sorry, I meant to reply to this.

The problem is the spec PDF and the JavaDocs aren't perfectly clear. In 
PLT.17.1 the spec says "Preference attributes are String array objects. 
Preferences attributes can be set to null"


I agree with the change on line 154 
<https://github.com/Jasig/uPortal/pull/78/files#L0L154>If there is no 
values array set the default value should be returned. This should fix 
the problem you had of defining a preference with not values in the 
portlet.xml.


However the change on line 157 
<https://github.com/Jasig/uPortal/pull/78/files#L0L157> would break the 
preferences object according to the spec as it would prevent a portlet 
from correctly storing null in the first element of the preference 
values array.


I will apply the first change before 4.0.7 is cut.

-Eric


On 10/8/12 4:43 AM, Arvīds Grabovskis wrote:
Jumping in the last moment, but I hope that you could review this 
<https://github.com/Jasig/uPortal/pull/78> pull request and apply it 
to trunk and 4.1.patches.


-- Arvīds


2012/10/6 Eric Dalquist <mailto:eric.dalqu...@doit.wisc.edu>>


I'm back getting actual work done and will plan on cutting 4.0.7
monday. I reviewed all changes on master and merged what I thought
applied back to 4.0-patches. I'll be going through Jira tonight to
see if there is any low-hanging fruit and then plan on cutting the
release Monday. I'll also be cutting a new resource server release
on Sunday so if anyone has any changes be sure to get them in.

-Eric


--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

I'm back getting actual work done and will plan on cutting 4.0.7 monday. 
I reviewed all changes on master and merged what I thought applied back 
to 4.0-patches. I'll be going through Jira tonight to see if there is 
any low-hanging fruit and then plan on cutting the release Monday. I'll 
also be cutting a new resource server release on Sunday so if anyone has 
any changes be sure to get them in.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] delighted to see new reporting portlet

[Eric Dalquist]

It will get merged for 4.0.7

Please test it out though if you have time!

-Eric

On 10/4/12 7:02 PM, Drew Wills wrote:
https://github.com/Jasig/uPortal/commit/1cb41e946b062be799eff8b3a27f992175df79b7 



Is it something we can merge into rel-4-0-patches?

I'm getting asked about this feature pretty frequently.

drew






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Issue searching on the 'username' attribute

[Eric Dalquist]

I'll see if I can get a chance to review this in the next few days. 
We're on day 4 of just cleaning up the basement so it might not be until 
Monday.


-Eric

On 10/4/12 4:33 PM, Drew Wills wrote:

Hey folks,

I developed a patch for the JIRA:

  - https://github.com/Jasig/person-directory/pull/2

I didn't commit it immediately because persondir code can be hard to 
follow, and it's not always clear what all the outcomes of a change 
will be.  I can tell you this change eliminates the issue I was seeing.


I'll give it some space for public comment, then pull it later if 
nothing unexpected surfaces.


drew

On 10/3/2012 5:53 PM, Drew Wills wrote:

I dug a bit deeper and created a JIRA:

   - https://issues.jasig.org/browse/PERSONDIR-66

drew

On 10/3/2012 4:10 PM, Drew Wills wrote:

Here's another piece of config that contributes to this puzzle...

 
 username
 givenName
 sn
 

That's what I had at first.  The behavior with that config was to set
each matches's 'username' attribute equal to the query string I 
entered.


Instances if IPersonAttributes appear to implement equals() by 
comparing

the usernames of the 2 objects, and therefore the Set that was returned
from AbstractQueryPersonAttributeDao.getPeopleWithMultivaluedAttributes
contained only 1 entry.  (Every result was technically equal to every
other result.)

Although I *do* want to search on username, I temporarily changed it
to...

 
 givenName
 sn
 

This config had the effect of making every result's username attribute
null.

I was still getting a Set with 1 element returned, but this time ZERO
matches were displayed in the portlet screen.  (I guess the portlet
somewhere discards results without usernames.)

To me, the crux of the issue seems to lie in this...

I'm doing a search for all objects (in LDAP) matching...

   username='william' || givenName='william' || sn='william'

In my case, _none_ of the 93 results out of LDAP is owing to a match on
the first condition (username='william').  The
AbstractQueryPersonAttributeDao, however, seems to conclude that, since
I was searching for username='william' it must be the case that
username='william' for any results returned from LDAP.

I suppose that would be a safe assumption for a single-condition query,
but in this case it's not working out.

It seems like it would be better/safer to read the username from the
collection off attributes LDAP sends back.

But there are 2 challenges:
   - How do we know which attribute is the username?  (e.g. uid,
sAMAccountName, etc.)
   - What if that attribute is somehow not among those fetched?

Thoughts anyone?

drew


On 10/3/2012 3:22 PM, Drew Wills wrote:

I'm seeing something weird with PersonDirectory.

I have this in the config for an LdapPersonAttributeDao...


   
 
 
 
   


Using a step-through debugger, I can see that 93 results come back 
from

LDAP.  But on the screen it only shows 1 result.

All but one match seem to be getting lost in the
AbstractQueryPersonAttributeDao.getPeopleWithMultivaluedAttributes
method.  It takes the raw results (93) from LDAP and converts them to
another format and places them in a Set of mappedPeople. For each item
it creates (and places in the Set) it seems to use the same value for
the 'username' attribute, which it's getting from the query 
parameters I

passed in, instead of from the results out of LDAP.

I'm not positive what path is best for getting the desired 
behavior. I'm
not sure I understand what all the parts of this setup are trying 
to do.


drew












smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Merging Pull Requests

[Eric Dalquist]

I've added some instructions around merging pull requests in the wiki:

https://wiki.jasig.org/display/UPC/Git+Workflow+for+Committers#GitWorkflowforCommitters-MergingPullRequests

-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

Another few days ... basement flooded with a sewer backup. Another delay 
in getting the release out.


Sorry folks,
-Eric

On 9/24/12 8:39 AM, Eric Dalquist wrote:
I'm going to have to push this back a few days, I got sick over the 
weekend and didn't get anything done on the last few changes.


-Eric


On 9/20/12 10:38 PM, Eric Dalquist wrote:
I'm planning on cutting and announcing 4.0.7 on Monday, please let me 
know if there are pending fixes or changes you'd like to get in 
before then.


-Eric









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

I'm going to have to push this back a few days, I got sick over the 
weekend and didn't get anything done on the last few changes.


-Eric


On 9/20/12 10:38 PM, Eric Dalquist wrote:
I'm planning on cutting and announcing 4.0.7 on Monday, please let me 
know if there are pending fixes or changes you'd like to get in before 
then.


-Eric






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

Right, thanks, I had forgotten about that one. I'll take a look and see 
what we can do to get it in.


-Eric

On 9/21/12 3:18 AM, Anthony Colebourne wrote:

Hi,

Subject to review I'd like to see this resolved.
UP-3038 externalId attribute as 'folder' name

A pull request is here
https://github.com/Jasig/uPortal/pull/65

-- Anthony.


On 21/09/12 04:38, Eric Dalquist wrote:

I'm planning on cutting and announcing 4.0.7 on Monday, please let me
know if there are pending fixes or changes you'd like to get in before
then.

-Eric








smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 4.0.7 Release Plans

[Eric Dalquist]

I'm planning on cutting and announcing 4.0.7 on Monday, please let me 
know if there are pending fixes or changes you'd like to get in before then.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature