[uportal-dev] Fwd: resource-server version 1.0.43

[Anthony Colebourne]

Hi,

Version 1.0.43 is in maven central, but the tag is missing from GitHub.
Does somebody have local commits ready to be pushed?

Thanks,
Anthony.

--
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] Idea for uportal-bundle

[Anthony Colebourne]

FYI this is exactly what I've done locally, I called mine 
manchetser-ear. It contains the same sub modules as yours!


I also use this project to store my quickstart_entities / 
manchester_entities.


... Once I've filtered my overlayed portlets and uPortal I either
1) don't want to leave then lying around in the .m2 directory
or
2) I do want them laying around in .m2 to save re-filtering next time 
when all I've done is update a single portlet version. In this case I 
need to ensure that artifacts filters for UAT do not accidentally get 
included in a bundle filtered for PROD.


... I'm not sure whether skip-deploy, skip-install on each portlet would 
break the overlay system?


... ultimately I want to move away from filtering completely and use 
paths to external properties files so I can truly have 1 build for all 
environments.


-- Anthony.

On 09/06/15 19:41, Tim Levett wrote:

Hi Devs,


One topic that came up during the uPortal BoF was moving bundled
portlets out of the portal project. We all recognized the benefit of the
bundle, but also realized this could be a separate project that pulled
in the needed dependencies.


I took a stab at pulling out the important bits of the bundling and
building of the EAR and put it up on github here:
https://github.com/timlevett/uportal-bundle .


What are your thoughts?  Should we move this project into Jasig and move
forward?


Thanks,


Tim Levett
tim.levettATwisc.edu
MyUW-Infrastructure

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Name for new window state that was like DETACHED

[Anthony Colebourne]

Hi,

The portlet spec has the concept of WindowStates and sometimes Portlets 
make use of them.


By using WindowStates as the mechanism to deliver content to external 
apps, it means that one cannot fully make use of all window states 
within that content.


You might argue that this is an entirely appropriate use of 
WindowStates. The point highlighted in the thread was that often 
Portelts are sloppily developed and make assumptions about WindowState.


A typical use case is for a portlet to change its window state at some 
point. Well written portlets would check their current window state 
before doing this (e.g. if SEPARATED then don't change or only change if 
current == NORMAL).


A completely alternative "external rendering" approach that didn't use 
WindowStates and therefore could be made to support all window states 
would not suffer from these "deficiencies".


-- Anthohny.


On 17/04/15 01:05, James Wennmacher wrote:

Hi Anthony.

Thanks for bringing my attention to this thread.  I'm not sure I fully
follow it.  Can you clarify for me what the deficiencies are?  Thanks.

James Wennmacher - Unicon
480.558.2420

On 04/14/2015 03:59 PM, Anthony Colebourne wrote:

Hi James,

Now seems like an appropriate time to draw your attention to this thread.
http://jasig.275507.n4.nabble.com/Detached-WindowState-td4657565.html

It highlights this deficiencies in the WindowState based approach to
getting content rendered for consumption in an external app.

Thanks,
Anthony.


On 14/04/15 21:58, James Wennmacher wrote:

A request to add a new window state came about due to Oakland which has
a native uMobile app found that DETACHED window state which the uMobile
app uses behaves differently with uPortal 4.1+.  Refer to
https://issues.jasig.org/browse/UP-4440.

I plan to add a new window state SEPARATED which is like the old
DETACHED window state.  I'm OK with the name, but not jumping up for
joy.  It's fairly clear and consistent (at least as much as DETACHED
was).  Anyone have a better name?

See issue for details and reasoning.








--
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] Name for new window state that was like DETACHED

[Anthony Colebourne]

Hi James,

Now seems like an appropriate time to draw your attention to this thread.
http://jasig.275507.n4.nabble.com/Detached-WindowState-td4657565.html

It highlights this deficiencies in the WindowState based approach to 
getting content rendered for consumption in an external app.


Thanks,
Anthony.


On 14/04/15 21:58, James Wennmacher wrote:

A request to add a new window state came about due to Oakland which has
a native uMobile app found that DETACHED window state which the uMobile
app uses behaves differently with uPortal 4.1+.  Refer to
https://issues.jasig.org/browse/UP-4440.

I plan to add a new window state SEPARATED which is like the old
DETACHED window state.  I'm OK with the name, but not jumping up for
joy.  It's fairly clear and consistent (at least as much as DETACHED
was).  Anyone have a better name?

See issue for details and reasoning.



--
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] More securely handling storage of sensitive information

[Anthony Colebourne]

Hi,

So in my uPortal source tree, I have an overlay project for each portlet 
that gets deployed into the EAR. Generally these overlay project do 2 
things. 1) Filtering and 2) Plutoifying


Number 1) is because when I push portlet WARs to my local Nexus I use a 
blank filter file. Therefore the portlet projects own build filtering 
does nothing, leaving the tokens intact which are later replaced by 
uPortals overlay project.


uPortals portlet overlay artifacts produced are environment specific and 
therefore "should" not be in the local (.m2) maven repo.


Your suggestion will remove the need for number 1) above meaning that 
overlays are reusable across environments, which is good!!


If the pluto stuff could be done at a different stage, then the portlet 
overlays might not be necessary at all :-)


FYI for my uP4.1 server set up, I've been experimenting not using 
uPortals EAR project. By using my own separate my-edu-ear project that 
just pulls everything together I can speed up environment re-build times 
assuming that everything is pre-built.


Often a rebuild is needed only because a portlet version number has 
increased, yet everything gets re-filtered for that environment.


To achieve my stand-alone ear project I've followed UW-Madison's 
approach and used an environment specific maven group name for the 
overlayed artefacts. So I can keep the filtered artifacts hanging 
around. However I've struggled about WHEN to do the filtering-overlay 
and have so far conceded to adding a my-edu-eay/overlays sub-project. (I 
believe UW hit a Jenkins many-project explosion at this stage!).


... still, I'm saving on the uPortal source build and also I don't have 
to cut a local release of my uPortal fork every time a new portlet war 
is added / removed.


I really hope this makes sense to you? If not, please understand that 
NOT having artifacts that are environment specific is a massive step 
forward.


-- Anthony.



On 16/01/15 20:26, James Wennmacher wrote:

Update:  In regards to portlets, especially those that do DB
connections, load override property values from a location outside the
war similar to the way uPortal does (see
https://wiki.jasig.org/display/UPM41/Properties+Files+and+Properties+Overrides),
I propose we change the Apereo portlets to load property values in the
Spring configuration from

  * local property files in war
  * |${CATALINA_HOME}/portal/overrides.properties|
  * |${CATALINA_HOME}/portal/{portletName}_overrides.properties|
  * |${PORTAL_HOME}/overrides.properties|
  * |${PORTAL_HOME}/{portletName}_overrides.properties|

The reason is that the main values that will be in the
overrides.properties file will be the following

hibernate.connection.driver_class=${environment.build.hibernate.connection.driver_class}
hibernate.connection.url=${environment.build.hibernate.connection.url}
hibernate.connection.username=${environment.build.hibernate.connection.username}
hibernate.connection.password=${environment.build.hibernate.connection.password}
hibernate.connection.validationQuery=${environment.build.hibernate.connection.validationQuery}
hibernate.dialect=${environment.build.hibernate.dialect}

(and some others for other uPortal Aggregation DB connections) and these
property names are the same property names that are used by uPortal and
portlets.  The property value will be whatever the override value is,
not the build environment string.

This allows the common use case of having one file that applies to
uPortal and all portlets and sets the DB connection url (optional in
case you want to make it more 'hidden'), username, and password for
maintenance (one file to change when DB passwords change) and improved
security (more restricted file access to sensitive info).  The
{portletName}_overrides.properties allows for the rare case of needing
something else.  One example that I can think of is an encryption key
value used by a portlet to encrypt sensitive user portlet preferences
before storing them into the DB, though I could also see having that be
global, or a conflicting property name between a couple of portlets.

Please let me know if you have any feedback on this idea.

Thanks,

James Wennmacher - Unicon
480.558.2420



*From: *"James Wennmacher" 
*To: *uportal-dev@lists.ja-sig.org, portlet-...@lists.ja-sig.org
*Sent: *Monday, December 15, 2014 11:37:14 AM
*Subject: *More securely handling storage of sensitive information

I'm going to be incorporating code to handle Exchange Impersonation in
Exchange Web Services in the Calendar portlet.  The current
implementation stores the the username and password in a properties
file.  Since this is such a powerful trusted account, I'd like to
improve the security a bit above that implementation.  What have others
done?  Has anyone implemented something that I can package into the
portlet utilities project to improve the security aspects of storing
credentials?

What 

Re: [uportal-dev] AJAX all the portlets

[Anthony Colebourne]

Hi,

So I think we really want these two worlds to collide in some way. I 
absolutely agree that uPortal should be a client side app that ajaxies 
back to the uPortal server.


Having special portlet modes/window states that allow portlets to 
contribute plugins to the portal's client side app seems like a possible 
route to investigate.


So portlets in regions must conform UI-wise to some portal vendor rules 
to be eligible for use in a region. Portlets wishing to contribute to 
the running client UI might not bootstrap their own client side context, 
but opt to conform to some rules to plug-in their capabilities to 
uPortal UI.


I see your problem; with all this client side stuff happening, how do 
non 'uPortal compatible' portlets get their markup or mini client side 
UI apps rendered?


With this kind of stuff I'm keen to understand whether Portlet spec 3 
will offer any guidance?


-- Anthony.

On 07/01/15 21:47, Andrew Petro wrote:

Anthony,

All that's fair.

I'm coming at it a bit sideways in that I'm thinking about how to add
server-generated dynamic content to
https://github.com/UW-Madison-DoIT/angularjs-portal , of course.

Currently when our Beta users dive into a portlet, they bop over to our
forked-from-Respondr theme to render that portlet.  And that's fine as
far as it goes, but it's a lot of XSLT machinery to do what has become a
very limited job (rendering one portlet with some chrome around it.)
  There's also some annoyance in leaving and returning to what amounts
to a Single Page Application that renders our Beta landing page and the
not-portlet Beta functionality.

So.  I'm thinking that if the framework knew how to render the markup of
one portlet without having to go through the whole rendering pipeline
XSLT stuff, as in, the kind of thing that would respond to an
asynchronous call for the portlet markup in a theme that rendered
portlets that way, well, hey, that's also exactly the kind of
asynchronous call that a Single Page Application front end could do to
simulate what we're currently getting out of forked-from-respondr
rendering maximized portlets. :)  And then users would never leave the
AngularJS front end (while within our portal, anyway) and we'd only have
to implement sidebar chrome and so forth once and life would just be
cleaner all around.

Andrew

On Wed Jan 07 2015 at 3:39:34 PM Anthony Colebourne
mailto:anthony.colebou...@manchester.ac.uk>> wrote:

Hi,

A few years ago this sounded like a possible good way forward. These
days I'm less convinced by this. These days I like to develop Portlet
UIs in much the same way I develop servlet app UIs; I deliver the client
side application which calls back to its portlet origin for data via
ajax. In this model a framework-ajax loaded portlet would only really
serve to increase the number of requests.

Unless we could make this work 'transparently' then its possible that a
portlet developer would need to be aware at development time and code
for this type of rendering, therefore forcing the developer to alter
their development style to suite running in the portal.

Obviously there are use cases where is would be an advantage (WebProxy
content for example), but it might be that just adding this feature to
the WebProxyPortlet would be simpler?

Thanks,
Anthony.

On 07/01/15 20:40, Andrew Petro wrote:
 > uPortal developers,
 >
 > Has anyone given thought to what it would look like to, at the
framework
 > layer, make all the portlet markup render down to the browser
 > asynchronously?
 >
 > Individual portlets have been developed to asynchronously render
their
 > content, first rendering a loading... experience and then
replacing that
 > with content once loaded.  I think the email preview portlet or
so does
 > this.
 >
 > But I'm wondering about implementing that generically at the
framework
 > level.  Instead of interpolating dynamic portlet content in the theme
 > transform and having that HTML all cooked server side and fed down to
 > the browser, instead generate the AJAXy placeholders that call
back to
 > the server to get their portlet's markup when it's ready.  (I
imagine if
 > I understood Web Sockets I'd want to use them for some aspect of this
 > and that would be better in some way.)
 >
 > Obviously, there are *better* experiences to be had by designing AJAX
 > usages within individual units of content.  Would need a way to opt
 > portlets into or out of this magic handling.
 >
 > But still.  Is there any potential in this idea?  Anyone tried this?
 >
 > Kind regards,
 >
 > Andrew
 >
 > --
 >

Re: [uportal-dev] AJAX all the portlets

[Anthony Colebourne]

Hi,

A few years ago this sounded like a possible good way forward. These 
days I'm less convinced by this. These days I like to develop Portlet 
UIs in much the same way I develop servlet app UIs; I deliver the client 
side application which calls back to its portlet origin for data via 
ajax. In this model a framework-ajax loaded portlet would only really 
serve to increase the number of requests.


Unless we could make this work 'transparently' then its possible that a 
portlet developer would need to be aware at development time and code 
for this type of rendering, therefore forcing the developer to alter 
their development style to suite running in the portal.


Obviously there are use cases where is would be an advantage (WebProxy 
content for example), but it might be that just adding this feature to 
the WebProxyPortlet would be simpler?


Thanks,
Anthony.

On 07/01/15 20:40, Andrew Petro wrote:

uPortal developers,

Has anyone given thought to what it would look like to, at the framework
layer, make all the portlet markup render down to the browser
asynchronously?

Individual portlets have been developed to asynchronously render their
content, first rendering a loading... experience and then replacing that
with content once loaded.  I think the email preview portlet or so does
this.

But I'm wondering about implementing that generically at the framework
level.  Instead of interpolating dynamic portlet content in the theme
transform and having that HTML all cooked server side and fed down to
the browser, instead generate the AJAXy placeholders that call back to
the server to get their portlet's markup when it's ready.  (I imagine if
I understood Web Sockets I'd want to use them for some aspect of this
and that would be better in some way.)

Obviously, there are *better* experiences to be had by designing AJAX
usages within individual units of content.  Would need a way to opt
portlets into or out of this magic handling.

But still.  Is there any potential in this idea?  Anyone tried this?

Kind regards,

Andrew

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] How do we feel about ending support for Universality/mUniversality?

[Anthony Colebourne]

Andrew,

It would be great to know more about Bucky :-)

What about Respondr? Do you think this will be around long enough to 
attract many adopters?


I think Universality is dead, but I agree that mUniversality might still 
have a future. WebViews in native mobile apps still need a theme to 
render in, especially if the default theme's detached mode renders a 
sticky header nav bar.


-- Anthony.


On 12/11/14 20:56, Andrew Petro wrote:

Drew,

I agree that I **feel** Universality and mUniversality should be
deprecated and then removed.

I’d feel more confident in that with more discussion in this thread:

http://thread.gmane.org/gmane.comp.java.jasig.uportal/17788

that is, I’d love to know adopters had successfully migrated forward to
achieve their theme desires via Bucky and that therefore the product was
dropping Universality and mUniversality because in practice adopters
were no longer using those.  As opposed to the product dropping them
without having demonstrated that adopters successfully migrate forward
to Bucky.  Less about developer feelings and more about the product
responding to adopter adoption.

So.  I think we need a few more rounds of making noise about, hey, what
needs to be better about Bucky and what needs to be better about this
upgrade path, o Universality and mUniversality adopters, such that your
migration forward to Bucky is obvious, before removing these.  Visibly
deprecating them might be a great step in that making-noise process.

Bear in mind that while I'm looking forward to an exciting responsive
MyUW feature, the current production default is Universality /
mUniversality, and will remain so for the near future.  That while James
and others have shared promising ideas about how to make Bucky a more
suitable upgrade path from mUniversality (render less on landing on
mobile), those ideas are not yet implemented.  Such that an adopter
today could reasonably say that mUniversality is still their best foot
forward for some mobile use cases.  Once that sounds less reasonable,
it's going to be more clearly sound to drop mUniversality.


Kind regards,

Andrew

On Wed, Nov 12, 2014 at 2:23 PM, Drew Wills mailto:awi...@unicon.net>> wrote:

Should these themes be removed in 4.2 (or 4.3, 5.0, etc.), or should
we retain support for them indefinitely?

I’m inclined to believe we should remove them at some point, I’m
just not sure of the right moment.  It’s a bandwidth drag to
maintain them, and they’re enough long-in-the-tooth that I don’t see
anyone innovating on them.

Thoughts?

drew
--
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: 
anthony.colebou...@manchester.ac.uk
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] sticky profile selection

[Anthony Colebourne]

Hi,

I was wondering whether stickiness in this regard should be a build time 
or runtime choice?


Might there be a use case where both might be required in a single 
uPortal instance? The only case I can think of is switching from a 
dedicated mobile theme to a desktop theme while using a mobile device. 
It's not the strongest case for needing runtime sickness choice, but if 
these one use-case then there might be others!


The thought that came to mind was
/Login?profile=bucky&setDefault=true
or
/Login?profile=bucky&oneTime=true

-- Anthony.


On 17/10/14 19:01, Andrew Petro wrote:

uPortal developers,

MyUW has a need to make ad-hoc profile selection (via profile=bucky on
/Login) less "hoc" and more sticky-across-sessions.

UP-4223 took a shot at this but didn't seem to work in MyUW.

https://issues.jasig.org/browse/UP-4223

https://github.com/Jasig/uPortal/pull/416

Having looked into this a bit, I'd like to propose this alternative
implementation of making profile selection sticky:

http://apetro.ghost.io/sticky-profiles/

I'm close to working code implementing this design and intend to offer
a Pull Request once it seems to be working locally.

Feedback and design input welcome.

Kind regards,

Andrew



--
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] MyUW Redesign notes

[Anthony Colebourne]

Andrew,

Thank you for being so open, the community is so much richer for it.

My opinions inline...

On 07/08/14 20:29, Andrew Petro wrote:

  * *Collections of Favorites are gone*, at least for now.  [1]


This is devastating news :-(


  * User-selected *Normal Window State portlets living on the landing
tab are back in*.  This means that Maximized isn't the only way to
get at user-selected stuff; portlets are sometimes in Normal Window
State rather than only Maximized.


Woo Hoo!


  * Favoriting a portlet and adding it to one’s Welcome page (the only
page of multiple portlets) is exactly the same thing. *So, you
favorite a portlet, and that adds it in Minimized window state right
on your home screen. * You might then expand it to Normal window
state, and that expansion will be remembered.


Love the use of minimized window state.


  * *Minimized window state will have a styled infocard-like
representation.*  Title, first bit of the description, icon.  Enough
to evoke what it is so you can decide to open it.


Will this be actually rendered portets or just skin trickery from 
marketplace registry? I hope its the former, portelts have a lot to 
offer. Perhaps it could source and aggregate some marketplace content 
too via an API.



  * User *re-ordering of the portlets in the home screen will be
disabled* to reduce technical risk and support burden.
  Drag-and-drop as trip hazard.  This feature probably comes back in
on some subsequent release.


Trip hazard?


  * *Search is de-scoped to only search MyUW content*, and we’re
dropping the whole search Portlet Event thing.  No search of dynamic
content, just search over descriptions and other static portlet
publication metadata. *This will make search radically faster.*  It
also probably makes search implementation radically different in
that, at least for the near term in redesigned MyUW, *Search is just
another view on Marketplace*.  It’s entirely feasible to load the
entire (filtered-for-the-user) portlet metadata registry down into
the browser and perform all the search operations client-side.  This
will make search radically faster.


Couldn't a hybrid solution be found? I believe autocomplete has already 
gone this way. Perhaps the initial render can be followed by ajax 
loading->loaded content search? (infinite scroller?)


I see personalized federated search as a big selling point of uPortal. 
There must be ways we can make this performant (or at least appear so).


We've spoken in the past about including a crawler, I feel there may be 
something in this.


Also we spoke about the difficulties of personalized search in the 
absence of a PortletRequest :-(  perhaps ajax is our friend? simple 
but effective.



-- Anthony.

--
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] Announcement Portlet - Proposed UI Changes

[Anthony Colebourne]

Hi,

I don't really have any UI comments about this project, but I though it 
worth mentioning some though/discussions I've had about this project.


1) The Assign Permissions feature is too basic. Also mapping the 
available groups in the portlet.xml is a pain. I think ultimately this 
need integrating with the Portal groups system. Either by adopting this 
as a framework portlet or by using uPortal provided APIs.


2) Assigning permissions at the topic level is not very useful in 
certain scenarios. E.g. If I have different "Academic notices" for 
faculty staff and students then I have to create 2 separate topics to 
achieve this. This gets worse if I want different academic notices for 
each school.


The portlet currently allows non-unique topic names, which helps in this 
scenario as at least each topic can have the same name so users don't 
know that its actually a different topic. However if you do this, it's 
impossible to tell in the admin UI which is which without clicking on 
each one, then clicking back and trying to remember which one you 
clicked last!


Thanks,
Anthony.


On 06/08/14 21:42, Jodie Muramoto wrote:

Hi everyone (again),

The next couple of days, I’ll be working on improving the UI for the
Announcements Portlet. I’ll be incorporating Bootstrap into the
various views, along with adding some PIZZAZZ. Attached are
wireframes of some of these ideas. Please note, the color of buttons
and the placement of buttons will be addressed, these are simply a
general view UI updates.

I anticipate having these changes in a pull request later this week.
Let me know if you have any feedback or suggestions.

Cheers, Jodie Muramoto User Experience | Unicon, Inc.
jmuram...@unicon.net




--
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] My Introduction / Calendar Portlet Changes Proposition

[Anthony Colebourne]

Hi Jodie,

Welcome to the community!

This improvement looks good. So you have a +1 from me.

A couple of points to consider:

1) bootstrap-calendar may not be suitable for use in normal window 
state. I would like to see improvements to normal window state a.k.a 
dashboard (and minimized mode too). I'm thinking it should just be a 
list without the widget, perhaps there could be buttons too.


I'm not sure how to build an intuitive way to switch window states 
though. ... with interactive portlets its common to switch to maximized 
almost as soon at clicking anything in the dashboard UI. However with 
informational portlets like this, I think one would like to be able to 
at least view the full details of th event without being forced to 
maximized. Perhaps in this case we just have an explicit "view 
maximized" button? or just rely on the chome controls.


Obviously this will not be an issue for folks using the new favorites 
portlet.


2) I would like to see support of placement in a region. Unfortunately 
there is no such "header-top-region" window state so this has to be 
implemented as a separate portlet or switchable using a portlet 
preference for example.


Thanks,
Anthony.



On 06/08/14 21:35, Jodie Muramoto wrote:

Hi everyone,

I’d like to introduce myself. I’m Jodie Muramoto, new UI/UX developer at
Unicon. I assist with front-end skinning and development for uPortal. In
the last few months, I’ve been ramping up on the solution architecture
of uPortal, and I’m very excited to be working with such a robust and
powerful open-source project, along with a community who is engaged and
passionate about moving uPortal forward.

I will be working on the UI design for a couple the calendar portlet,
and I would like to propose some changes and get feedback from you.
Perhaps some of you have already implemented some changes with your
solutions, or would like to help with the changes. Either way, I’m eager
to hear from you.

Below is the calendar portlet as it is today:


And this is an idea I have to improving the calendar portlet:


I found Calendar Bootstrap
 (open-source
Bootstrap/jQuery library, registered under the MIT license), which
simply takes JSON data and parses it into a calendar view. This would
require some minor JavaScript/JSON changes, along with integrating
Bootstrap and jQuery into the portlet. There is also a Bootstrap2
version that could fit into Universality and accommodate more of the
supported browsers (including IE7).

Have any of you implemented a different version of the calendar portlet?
If so, would you mind sharing how/what you did? Or do any of you have
any suggestions or feedback?

Thanks for your time! Cheers,

Jodie Muramoto (Github: doodelicious)
User Experience | Unicon, Inc.
jmuram...@unicon.net 

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Re: [uportal-dev] Re: [uportal-dev] sequential IDs in layout-fragment.xml files contributing to commit noise

[Anthony Colebourne]

So as Eric pointed out, the two issues are actually separate. The id's serve 
two purposes. While persisting layout as a single entity would remove the need 
for so many database id's, it would not satisfy the needs of Dlm's diff 
strategy.

There may be an opportunity to separate these out in the short term, but 
ultimately Dlm needs to identify the individual bits of a layout in order to do 
it's job. Perhaps maintaining layout node identifiers would be simpler if the 
db we're not involved, but perhaps not! 

Certainly in the short term, the suggested spaceing approach would elevate some 
of the pain. 

Anyway, food for thought :-)

Anthony.  



Sent from my HTC

- Reply message -
From: "James Wennmacher" 
To: 
Subject: [uportal-dev] Re: [uportal-dev] sequential IDs in layout-fragment.xml 
files contributing to commit noise
Date: Sat, Jul 26, 2014 00:50

Hmm... great.  Could you write up a
proposal in a Jira so it can be discussed and maybe (someday)
worked on?  :-)

James Wennmacher - Unicon
480.558.2420
On 07/25/2014 03:06 PM, Anthony Colebourne wrote:





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 - Unicon
480.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 
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: 
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: 
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: 
anthony.colebou...@manchester.ac.uk
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

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

[Anthony Colebourne]

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 - Unicon
480.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 
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: 
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: 
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: 
anthony.colebou...@manchester.ac.uk
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] Nice work on Portlet Marketplace

[Anthony Colebourne]

+1

-- Anthony.

On 17/04/14 23:50, Drew Wills wrote:

One item of feedback:  I think it really should honor the feature
whereby non-categorized portlets are hidden from browsing and direct
access.


--
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 Favorites portlet

[Anthony Colebourne]

Hi Andrew,

On 22/01/14 15:24, Andrew Petro wrote:

AC> Finally my thoughts in this area lead me to think about a custom
window state like the windows 8 tile.

All that said, I think maybe part of the message of Responsive is that
UIs that respond to their window (or portlet container!) sizes are the
evolution beyond the blunt instrument of telling a portlet how big it is
with its window state.  We may not need NORMAL, MAXIMIZED, and TILE
window states (or, at least, can use the very same view implementations
to handle all those) if the portlet UI automagically arranges and styles
itself for the container size it finds itself rendered in.


I agree that we need to get the responsive containers stuff working.

I think that the future of "window states" revolves around the "window 
type" that content is going into, not its size.


So a NORMAL window state will require a portlet to wrap all its output 
in container with a .portlet class.


A "REGION" window state will require a portlet to abide by rule 3 set 
out in https://wiki.jasig.org/display/UPC/Respondr+Regions+Feature


A "TILE" window state might limit a portlet to only outputting a 
 containing a single  tag and background colour/image.


My other point is that a "dumb" launcher favorite link does not leverage 
the unique capabilities of java portlet technology.


-- Anthony.

--
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 Favorites portlet

[Anthony Colebourne]

Hi,

This feature it exciting and timely for us. Great work.

I'm I right in thinking that there will be a concept of pushed 
favorites? i.e. the set one gets at first login, based on group?


It might be nice if you could also favorite any web content. We might 
push common external links such as our LMS and Email (OWA). Also we 
could migrate uses BookmarksPortlet content.


I like the idea of a hybrid UI where we keep our existing tabs but push 
the favorites portlets to the home tab. I think for this to work well 
the portlet lookup approaches (gallery vs edit favorites) would need to 
be merged.


Although I think the one-portlet-at-a-time-maximized-centric view is 
prevailing (due I think to the mobile first approach that really 
de-clutters the old dashboard world).


It pains me to move away from what was, the primary reason for adopting 
portlet technology in the first place. Having said this, the case for 
"uPlatform" is still very strong.


A home tab with favorites plus notifications/calendar/news in my mind 
would allow us to keep some "portal like" features. Also if the 
favorites portlet was "badge number" aware or broadcast some useful 
portlet event for future extension/innovation then we really begin to 
leverage the portlet paradigm.


Finally my thoughts in this area lead me to think about a custom window 
state like the windows 8 tile. So this would be like a favorites portlet 
on steroids can actually render favorite-ed portlets in a well-defined 
"small and simple" UI container.


-- Anthony.


On 16/01/14 03:13, Andrew Petro wrote:

Hi All,

Favorites development is coming along.

There's now a wiki page for documenting:

https://wiki.jasig.org/display/UPC/Favorites

There's a feature branch for the favorites portlet:

https://github.com/Jasig/uPortal/tree/UP-3896

and a feature branch off of that feature branch for the un-favoriting
capability:

https://github.com/Jasig/uPortal/tree/unfavorite_from_favorites_portlet

That un-favoriting bit is feeling ready for merge into the favorites
feature branch (with some technical debt noted), so it's now an
eminently reviewable and feed-back-able pull request:

https://github.com/Jasig/uPortal/pull/203

Kind regards,

Andrew



On 12/13/13, 2:50 PM, Tim Levett wrote:

Hi All,

At UW-Madison we have started creating a favourite framework portlet.
It is a different way to view tabs. I've attached some screen shots of
the initial landing page.  We do plan on putting this into the master
jasig branch soon.

Regards,

Tim Levett
UW-Madison
lev...@wisc.edu





--
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] Fwd: Monthly uMobile call next week

[Anthony Colebourne]

Hi,

Does anybody have the access details for this call?

-- Anthony.

On 31/10/13 17:43, Jim Helwig wrote:

Forwarding for those of you interested in uMobile.


 Original Message 
Subject:[umobile-user] Monthly uMobile call next week
Date:   Thu, 31 Oct 2013 17:00:46 +
From:   Robert Sherratt 
Reply-To:   umobile-u...@lists.jasig.org
To: umobile-working-gr...@lists.jasig.org
, umobile-u...@lists.wisc.edu




All

We have the next call on Thursday 7 November at 11 AM Eastern. More
details and a draft agenda can be found at:

https://wiki.jasig.org/display/umobile/uMobile+open+calls

Please feel free to add further items to the agenda and amend the
existing items if you think they need further explanation.

Thanks

Robert



--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Bamboo failures

[Anthony Colebourne]

Hi,

I'm happy to help out with this kind of work. Though I currently don't 
have any access rights.


-- Anthony.

On 25/10/13 15:45, Cris J Holdorph wrote:

I recommend adding James Wennmacher ( jwennmac...@unicon.net ).

 Cris J H

On 10/25/2013 07:13 AM, Jim Helwig wrote:

I think I have the power but lack the knowledge. (Always a dangerous
thing). Recommendations on who might best be in a position to be added
to the admin list?

Also, it seems there is a distinction between bamboo-admin and
bamboo-plan-admin. Not sure what the difference is.

JimH

on 10/24/2013 9:24 AM Tim Levett said the following:

I only have privs to run the builds.  I do not have privs to configure
them.

On 10/23/2013 12:25 PM, James Wennmacher wrote:

Tim L do you have the ability to modify Bamboo build settings?  The
issue on both the 4.0 and 4.1 builds is that maven is running out of
PermGen during the build.  Once we resolve this issue, we should
document it on uPortal wiki as well.
James Wennmacher - Unicon
480.558.2420
On 10/22/2013 11:32 PM, Jasig Bamboo wrote:

Failed uPortal  ›
Trunk - Site
 › #776
 failed

Changes by 5 people




No failed tests found, a possible compilation error.


  Responsible

No one is responsible for this build.


  Failing Jobs


Job Duration Tests
Failed Default Job

(Default Stage) 15 minutes No tests found Logs

|
Artifacts





  Code Changes


View all 23 code changes


James Wennmacher

Merge pull request #173 from shawnconnolly/UP-3792



UP-3792
:

Adding functional add tab button to Respondr[d31bfa5_BAM_file_list]
[d31bfa5_BAM_hash]5d593f3f288cbbb0926ed1966f867442afa859d9
[d31bfa5_BAM_commiter_name]Shawn Connolly
[d31bfa5_BAM_commiter_email]sconno...@unicon.net

[d31bfa5_BAM_timestamp]1382470611
[d31bfa5_BAM_commit_message]UP-3792
:

Adding functional add tab button
4262c3201642cb3191103ecdb892795b1314b474
James Wennmacher

UP-3817


(partial) Add Fluid to Respondr for admin portlets
8144f3a0f37455e164866f5e204451171ef874c5
Tim Levett 
NOJIRA : Fix issue with master branch on local. Merge
remote-tracking branch 'origin/master'
8216fa6b5f0020330f39951649c67c1c3e56de3d
20 more changes…


View Online
 | Add
Comments




This message was sent by Atlassian Bamboo
.

If you wish to stop receiving these emails edit your user profile

or
notify your administrator
.

--

You are currently subscribed touportal-...@lists.ja-sig.org
as:jwennmac...@unicon.net
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:lev...@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: 
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] Petro --> Wisconsin-Madison portal team

[Anthony Colebourne]

Great to have you back full-time on portal :-)

-- Anthony.

On 18/10/13 14:59, Andrew Petro wrote:

uPortal developers,


Today is my last day as a Unicon employee.


I start on November 4th as a direct employee of the University of
Wisconsin-Madison, working alongside Tim Levett, Jim Helwig, and others
in making the University's successful, awesome uPortal implementation
even more successful and awesome.


It has been a pleasure and a privilege to serve higher education through
my Unicon roles these past almost eight years.  There have been many
interesting projects, a few thorny support cases, and a lot of fruitful
collaboration with exceptional colleagues within Unicon and with clients
and the community throughout.


I remember getting into this whole open source for higher education path
a decade ago when I was a student employee at Yale working with Susan
Bramhall and Howard Gilbert on Yale's uPortal implementation, and the
particular joy of my first uPortal developers' meeting at MIT putting
faces to the names of the many talented collaborators I'd met through
the uPortal project's email lists and source control.  I even got to
serve as a release engineer for a uPortal 2.x release or two.


And so I am particularly elated that my career is circling back to work
with uPortal in the context of MyUW.  I look forward to continuing to
work with talented collaborators in the Apereo community, and to
continuing to put faces to names at the next Apereo conference.


Kind regards,


Andrew


Wisconsin context: ape...@wisc.edu 

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Portlet markup template

[Anthony Colebourne]

Hi,

I've mentioned this page in a few conversations I've had :-)

https://wiki.jasig.org/display/UPC/Portlet+Markup+Template

In light of the work on Redpondir I think having some guidance on best
practice around markup would be useful.

For starters; there has been a pull request on NewsReaderPortlet that
(amongst some really good changes) changes some h1's into h2's.

While this was best practice in html4, I wondered what people thought
about this in light of html5.

-- Anthony.



--
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

[Anthony Colebourne]

Hi,

Many thanks for all your votes of support. I will endeavour to add value 
to the group in whatever way I can.


Should I get the call though, I'm afraid I might be inclined to join our 
esteemed coleagues ;-)


-- Anthony.


On 24/09/13 19:10, Eric Goldman wrote:

Bite your tongue Jim! No more Google defectors

Congrats Anthony!

Thanks,
Eric Goldman
Unicon, Inc.
480.558.2325
egold...@unicon.net <mailto:egold...@unicon.net>

On Sep 24, 2013, at 6:24 A, Jim Helwig mailto:jim.hel...@doit.wisc.edu>> wrote:


A belated congratulations to Anthony as the newest developer
representative on the uPortal Steering Committee!

Note to Anthony and Drew: As the two elected representatives,
tradition has it that you are stuck in these appointments until you
leave to work for Google. ;-)

on 9/18/2013 7:31 AM Jim Helwig said the following:

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
<mailto:uportal-dev@lists.ja-sig.org> as: egold...@unicon.net
<mailto:egold...@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: 
anthony.colebou...@manchester.ac.uk
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] Just a thought

[Anthony Colebourne]

Hi,

I was also thinking we could have a 
respondir-portlets-lo.fragment-definition.xml


I think this would need a new DLM EvaluatorFactory that could activate a 
fragment based on skin. I guess the users layout would need evicting 
from the cache? Is this possible?


-- Anthony.


On 08/09/13 22:44, Anthony Colebourne wrote:

Hi,

With the current trend towards embedding portlets are part of the theme
for Respondir, I was thinking that the Portal Administration Tools
portlet could be moved to the top of the screen as a toolbar that is
always available. (aka integrated admin).

-- Anthony.





--
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] Just a thought

[Anthony Colebourne]

Hi,

With the current trend towards embedding portlets are part of the theme
for Respondir, I was thinking that the Portal Administration Tools
portlet could be moved to the top of the screen as a toolbar that is
always available. (aka integrated admin).

-- Anthony.



--
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] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Anthony Colebourne]

Hi,

There is an outstanding Jira (UP-3552) that relates to this.

Obviously for large files a longer timeout may be needed, however due to 
this issue we are forced to choose a very high timeout that will work 
for very slow connections.


-- Anthony.

On 29/08/13 09:51, Vincent Bonamy wrote:

Hi All,

Even if the latest release of esup-filemanager (2.2.2), we use here in
production the "future" version of esup-filemanager (3.0.0-SNAPSHOT -
master on github/EsupPortail) which is already stable actually.

This version corresponds to a portlet  2.0 (esup-filemanager 2.2.2 is
portlet 1.0) for which all requests go through uPortal: that is to say
the Ajax requests, but also the Download and Upload requests !

We did this because portlet 2.0 provides these features and with that,
the code is so much easier (no sharing sessions/objects between
portlet/servlet ).

On the other hand, the upload request (for example) is also constrained
by this portal render timeout ... and so, 5 seconds or 20 seconds are
too low values ​​for the user ... ->  I put 2 hours (720) for this
portlet.

For esup-filemanager (> v. 3.0.0) , the default value with 5000 or 2
does not matter really ... but sure, it is very important that the
administrator set up "well" this parameter.

Vincent.



On 28/08/2013 22:45, Jim Helwig wrote:

I think I lean towards Anthony's side. I'd have to check what we set
ours to, but we aim to have requests served under 5sec. Long running
requests are outside the norm. I would think the default could be low
and if a portlet is known to need more, it could be changed accordingly.

That said, an administrator should generally review them before moving
into production so maybe the default is not as important.

JimH



---- Original message 
From: Anthony Colebourne 
Date: 08/28/2013 15:26 (GMT-06:00)
To: uportal-dev@lists.ja-sig.org
Cc: James Wennmacher 
Subject: Re: [uportal-dev] Proposal to change portal's default render
timeout from 5000ms to 2ms


Hi James,

In my experience I would recommend extreme caution when raising portlet
timeouts.

Under heavy load, it is very easy to use up all the portlet rendering
threads.

Just this morning I accidentally mis-configured a portlet who's time out
is 1 and brought down our servers. We're pretty strict about timeout
values and almost all of our portlets use the 5s default.

We in many cases use ajax to load content from long-running processes.
I'm some of these cases I have reluctantly raised to timeout of the
resource requests only.

I would like to see documented the relationship between rendering
threads and timeout values, also how this relates to tomcat threads and
apache threads where applicable. (I guess db connection pools are also
impacted, both portal and portlet?).

Some guidance on how to choose sensible thread/timeout values based on
averages such as portlets per page / server resources would be useful.

I'm happy to provide information and statistics from our production
cluster if it helps?

-- Anthony.



On 28/08/13 20:08, James Wennmacher wrote:
> I propose we change the portal's default render timeout from 5000ms to
> 2ms.  There are portlets that tend to take long time (such as email
> preview) or custom portlets connecting to back end systems where 5000ms
> is sometimes too short a time.
>
> I think the user experience in general would be better to have a longer
> default so:
> - The portal doesn't display an unpleasant message to the user for
> longer-running scenarios
> - The portal is more tolerant of operational issues such as uPortal or
> dependent systems running a bit slow
> - Longer-running processes should typically use ajax requests to obtain
> the data for a better user experience, so the urgent user response is
> less important in these situations since the entire UI is not impacted
>
> This would affect new portlets that are created via the UI (or imported
> without a timeout value I believe) but not existing portlet instances.
>
> Thoughts?

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
jim.hel...@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:
vincent.bon...@univ-rouen.fr
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] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Anthony Colebourne]

On 28/08/13 21:54, James Wennmacher wrote:

Do you have any statistics on your portlets for average execution time?
How many portlets do you have on your pages (in particular, pages with
longer-running portlets)?  What's the average execution time of the
portlets on those pages?


Unfortunately I don't have execution time data.

Our home tab has 8 portlets on it. Timeouts: 1 x 10s, 1 x 7s, 1 x 6s and 
5 x 5s.


3 of these portlets use ajax to load their "remote" content.

... after this conversation I think its time for me to review our status.


Do you have a lot of custom portlets and is internal portlet caching not
an option to avoid requests to external systems?


Yes we have lots of custom portlets. We do not use portlets such as the 
simple content portlet where all of its data comes from the portal.


All of our portlets make connects elsewhere. In some cases this may be a 
DB connection to different schemas on the main portal database server 
but more often to different database servers. A larger proportion of our 
portlets make SOAP or REST calls to remote systems. We make heavy use of 
the Jasig WebProxyPortlet.


Many of our portlets have their own cache, but more recently we've been 
switching to just using portlet caching. (This is very robust now in 
uP4). Caching however is a luxury, the data still has to be fetched at 
some point. (We've talked around just-in-time strategies, perhaps 
triggered from login, but have not actually done anything like this).



Do you have a lot of portlet timeout indications and on what portlets?


I see no evidence in the logs or from support calls that timeouts are an 
issue for our users.



Are your uPortal server's nearing capacity (how is it doing on JVM heap
usage and garbage collection, CPU usage, etc.)


This is not an area I'm confident with, however I suspect that our heap 
could use being a bit bigger. We have -Xmx4608m and 
-XX:MaxNewSize=2304m. This is the most I can allocate without causing 
the system to swap. CPU load is generally low.



There are 150 worker threads which of course are shared for all page
render requests so this does provide some indication of worker thread
queue sizing.  (Separate thought - it would be cool if the worker thread
queue defaulted to a configured size but auto-adjusted up to a separate
max value and dropped back to a configured min value as needed).


Our thread pool size is the default 150.

One though I came across; on a page with several portlets of different 
timeouts, then all portlets might as well be allowed to run for as long 
as the longest timeout!



Regarding the specific situation you mentioned (and others you are aware
of):
- what do you mean by brought down the servers?  Were user requests for
pages immediately failing or queueing up for processing (I'm not sure
what the behavior is when you run out of worker threads)?


When the thread pool is exhausted you get the uPortal error.jsp. uPortal 
generally recovers from this.


Today we got this
WARN [uP-TaskExec-4-cleanupHungWorkers] 
rendering.PortletExecutionManager.[] 2013-08-28 07:51:01,098 - 
PortletExecutionWorker [portletFname=man-portlet-calendar, 
timeout=1, portletWindowId=53_u23l1n12_27890, started=1377672501857, 
submitted=1377672501857, complete=0, retrieved=true, canceled=true, 
cancelCount=150, wait=0, duration=-1377672501857] is still hung, cancel 
has been called 150 times


I think we need to explicitly set the timout on our remote web service 
connection :-)


User facing today we got error 500 form Apache, so I suspect that we 
exhausted tomcat or mod_jk threads. I didn't do a full investigation on 
this occasion :-(



- can you explain in more detail why adjusting one portlet's timeout
from 5s to 10s brought down the servers.  How many other portlets are on
those specific pages and what are their average and peak response
times?  Is it on the home page, guest pages or authenticated user
pages?  Etc.


Today was a exception in many ways and really we're talking only of 
exceptional situations where a remote system has hung. In the day-to-day 
working then I agree that if a portlet genuinely needs more time it 
should have it.


uPortal's self protection features and better programming on my part 
mean that I'm more confident these days to increase timeouts. But I 
still see the timeout as our last line of defense against thread 
exhaustion, 500 errors or even death.



Clearly we'll want to really understand the impacts and potential risk
scenarios based on your comments.


Hope this helps?

-- Anthony.

--
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] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Anthony Colebourne]

That would probably be a handy feature Drew.

I tell my developers to develop with initially with all requests set to 
5s, this enables them to catch issues at an early stage and work towards 
making them faster.


... certainly when debugging and stepping through it's necessary to have 
long timeouts.


-- Anthony.


On 28/08/13 21:34, Drew Wills wrote:

Perhaps one thing we need is a manageable way to configure different
timeout values for production and everything else.

drew

On 08/28/2013 01:26 PM, Anthony Colebourne wrote:

Hi James,

In my experience I would recommend extreme caution when raising portlet
timeouts.

Under heavy load, it is very easy to use up all the portlet rendering
threads.

Just this morning I accidentally mis-configured a portlet who's time out
is 1 and brought down our servers. We're pretty strict about timeout
values and almost all of our portlets use the 5s default.

We in many cases use ajax to load content from long-running processes.
I'm some of these cases I have reluctantly raised to timeout of the
resource requests only.

I would like to see documented the relationship between rendering
threads and timeout values, also how this relates to tomcat threads and
apache threads where applicable. (I guess db connection pools are also
impacted, both portal and portlet?).

Some guidance on how to choose sensible thread/timeout values based on
averages such as portlets per page / server resources would be useful.

I'm happy to provide information and statistics from our production
cluster if it helps?

-- Anthony.



On 28/08/13 20:08, James Wennmacher wrote:

I propose we change the portal's default render timeout from 5000ms to
2ms.  There are portlets that tend to take long time (such as email
preview) or custom portlets connecting to back end systems where 5000ms
is sometimes too short a time.

I think the user experience in general would be better to have a longer
default so:
- The portal doesn't display an unpleasant message to the user for
longer-running scenarios
- The portal is more tolerant of operational issues such as uPortal or
dependent systems running a bit slow
- Longer-running processes should typically use ajax requests to obtain
the data for a better user experience, so the urgent user response is
less important in these situations since the entire UI is not impacted

This would affect new portlets that are created via the UI (or imported
without a timeout value I believe) but not existing portlet instances.

Thoughts?






--
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] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Anthony Colebourne]

Hi James,

In my experience I would recommend extreme caution when raising portlet 
timeouts.


Under heavy load, it is very easy to use up all the portlet rendering 
threads.


Just this morning I accidentally mis-configured a portlet who's time out 
is 1 and brought down our servers. We're pretty strict about timeout 
values and almost all of our portlets use the 5s default.


We in many cases use ajax to load content from long-running processes. 
I'm some of these cases I have reluctantly raised to timeout of the 
resource requests only.


I would like to see documented the relationship between rendering 
threads and timeout values, also how this relates to tomcat threads and 
apache threads where applicable. (I guess db connection pools are also 
impacted, both portal and portlet?).


Some guidance on how to choose sensible thread/timeout values based on 
averages such as portlets per page / server resources would be useful.


I'm happy to provide information and statistics from our production 
cluster if it helps?


-- Anthony.



On 28/08/13 20:08, James Wennmacher wrote:

I propose we change the portal's default render timeout from 5000ms to
2ms.  There are portlets that tend to take long time (such as email
preview) or custom portlets connecting to back end systems where 5000ms
is sometimes too short a time.

I think the user experience in general would be better to have a longer
default so:
- The portal doesn't display an unpleasant message to the user for
longer-running scenarios
- The portal is more tolerant of operational issues such as uPortal or
dependent systems running a bit slow
- Longer-running processes should typically use ajax requests to obtain
the data for a better user experience, so the urgent user response is
less important in these situations since the entire UI is not impacted

This would affect new portlets that are created via the UI (or imported
without a timeout value I believe) but not existing portlet instances.

Thoughts?


--
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] JSR 362: Portlet Specification 3.0

[Anthony Colebourne]

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: 
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] Search UI

[Anthony Colebourne]

Hi,

Nice work !!

Each search result has a Type property that can be used to separate 
results. It would be nice if this Type was output as a css class on the 
result container so that even if we choose to lump results together, 
they can still be styled differently. (Problem is that some developers 
may choose to set the type to a string containing spaces!).


It would be nice to able to sort or filter search results.

-- Anthony.



On 08/08/13 14:40, Steven Wiggins wrote:

I've been doing some work on the search UIs, and I'd like to show the
list to see if anyone has any feedback/criticisms and to see if these
are welcomed changes.

Attached are screenshots of the desktop view and the mobile view.

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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

[Anthony Colebourne]

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.






--
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] UP-3408 Work around spring exception handling bug

[Anthony Colebourne]

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.

--
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] Re: [uportal-dev] Backbone version in uPortal 4.0

[Anthony Colebourne]

Hi,

For my £0.02p worth, I would like to see portlets with an auto-piggyback 
system. I was thinking of something in the resource server utils package, 
perhaps built into the skin.xml or perhaps a tag library.

Anthony.  

Sent from my HTC

- Reply message -
From: "Drew Wills" 
To: 
Subject: [uportal-dev] Backbone version in uPortal 4.0
Date: Mon, Jun 10, 2013 17:59


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
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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 - Misagh Moayyed for uPortal Committer

[Anthony Colebourne]

+1

-- Anthony.

On 23/01/13 00:44, Eric Dalquist wrote:

I'd like to propose Misagh Moayyed as a committer for the uPortal
project. Misagh has been doing portlet development and providing uPortal
patches for several months now. The voting will be open until the 26th
and 3 +1 votes with no -1 votes are needed from existing uPortal
committers.

-Eric



--
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 - Chris Waymire for uPortal Committer

[Anthony Colebourne]

+1

-- Anthony.

On 23/01/13 00:41, Eric Dalquist wrote:

I'd like to propose Chris Waymire as a committer for the uPortal
project. Chris is relatively new but has already provided some great new
features and refactoring in uPortal on the stats system. The voting will
be open until the 26th and 3 +1 votes with no -1 votes are needed from
existing uPortal committers.


-Eric



--
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

[Anthony Colebourne]

+1

-- Anthony.

On 17/01/13 15:27, 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




--
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] 4.0.7 Release Plans

[Anthony Colebourne]

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



--
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] A user's group in a portlet

[Anthony Colebourne]

Hi,

This is the wrong list for this type of question, please use 
uportal-u...@lists.ja-sig.org


Thanks,
Anthony.

On 17/05/12 12:21, J.N.Addison wrote:

Dear All

I just started working on our uPortal project at the University of Kent,
and have been looking around for how I could get the role a logged on
user belongs to from a portlet, without much success. Our version of
uPortal is 2.5.3.1.

I’d be grateful if someone could point me in the right direction
concerning this.

Many thanks

Justice Addison

Web Developer

Information Systems

University of Kent

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Reg: Help to fix mysql deadlock error.

[Anthony Colebourne]

Hi,

Please don't consider this an authoritative answer :-)

In portal.properties you can try setting:
org.jasig.portal.io.threadPool.maxThreads=1

I think this worked around the issue for me. I haven't yet had time to 
investigate further or report it.


-- Anthony.


On 24/04/12 15:13, prabhu wrote:

Hi,


Am getting the following error while building the package using *ant
initportal *.

Importing Data from:
/usr/src/uPortal-4.0.4/uportal-war/src/main/data/required_entities
[java] WARN SQL Error: 1064, SQLState: 42000
[java] ERROR You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near ') AND UP_USER.USER_ID=0' at line 1
[java] INFO Scanning for files to Import from:
/usr/src/uPortal-4.0.4/uportal-war/src/main/data/required_entities
[java] INFO Found 17 files to Import from:
/usr/src/uPortal-4.0.4/uportal-war/src/main/data/required_entities
[java] INFO Importing 7 files of type 
[java] INFO Looking up bean 'counterStore' in ApplicationContext due to
context not yet being initialized
[java] INFO Imported :
entity-type/org.jasig.portal.groups.IEntity.entity-type.xml
[java] INFO Imported : entity-type/java.lang.Object.entity-type.xml
[java] INFO Imported :
entity-type/org.jasig.portal.security.IPerson.entity-type.xml
[java] INFO Imported :
entity-type/org.jasig.portal.services.entityproperties.EntityProperties.entity-type.xml
[java] INFO Imported :
entity-type/org.jasig.portal.portlet.om.IPortletDefinition.entity-type.xml
[java] INFO Imported :
entity-type/org.jasig.portal.groups.IEntityGroup.entity-type.xml
[java] INFO Imported :
entity-type/org.jasig.portal.security.IPermissionSet.entity-type.xml
[java] INFO Importing 2 files of type
<{https://source.jasig.org/schemas/uportal/io/stylesheet-descriptor}stylesheet-descriptor
version="4.0">
[java] INFO Imported :
stylesheet-descriptor/DLMXHTML.stylesheet-descriptor.xml
[java] INFO Imported :
stylesheet-descriptor/DLMTabsColumns.stylesheet-descriptor.xml
[java] INFO Importing 1 files of type
<{https://source.jasig.org/schemas/uportal/io/user}template-user
version="4.0">
[java] INFO Imported : user/defaultTemplateUser.user.xml
[java] INFO Importing 2 files of type
<{https://source.jasig.org/schemas/uportal/io/user}user version="4.0">
[java] INFO Imported : user/system.user.xml
[java] INFO Imported : user/guest.user.xml
[java] INFO Importing 1 files of type
<{https://source.jasig.org/schemas/uportal/io/portlet-type}portlet-type
version="4.0">
[java] INFO Imported : portlet-type/Portlet.portlet-type.xml
[java] INFO Importing 2 files of type 
[java] WARN SQL Error: 1213, SQLState: 40001
[java] ERROR Deadlock found when trying to get lock; try restarting
transaction
[java] ERROR Failed: importing file
[/usr/src/uPortal-4.0.4/uportal-war/src/main/data/required_entities/profile/system_default.profile.xml]
[java] INFO Imported : profile/defaultTemplateUser_default.profile.xml
[java] Exception in thread "main" java.lang.RuntimeException:
data-import from
/usr/src/uPortal-4.0.4/uportal-war/src/main/data/required_entities
matching null failed
[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
[java] at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[java] at
org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
[java] at
org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
[java] at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:54)
[java] at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
[java] at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:194)
[java] at upshell_1795560153.run(upshell_1795560153.groovy:113)
[java] at
groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:266)
[java] at groovy.lang.GroovyShell.run(GroovyShell.java:229)
[java] at org.jasig.portal.shell.PortalShell.main(PortalShell.java:84)
[java] Caused by: java.lang.RuntimeException: 1 
entities failed to import.
[java]
[java] Per entity exception logs and a full report can be found in
/usr/src/uPortal-4.0.4/target/data-import-reports
[java]
[java] at
org.jasig.portal.io.xml.JaxbPortalDataHandlerService.importData(JaxbPortalDataHandlerService.java:422)
[java] at
org.jasig.portal.io.xml.IPortalDataHandlerService$importData.call(Unknown 
Source)
[java] at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
[java] at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
[java] at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCa

Re: [uportal-dev] 4.0.4 Release Planning

[Anthony Colebourne]

Hi,

Just read your email while trying to workaround
https://issues.jasig.org/browse/UP-3339

-- Anthony.


On 13/03/12 14:47, Eric Dalquist wrote:

I'm going to work on getting things in order for 4.0.4 today (3/13) and
will plan on cutting the tag tomorrow (3/14) morning. If you have
anything you'd like to see in 4.0.4 please reply here to let me know.

-Eric

On 3/6/12 4:15 PM, Eric Dalquist wrote:

I'm waiting for Hibernate 4.1.1 to be released and then will be
cutting the 4.0.4 release. Hibernate should be releasing Wednesday or
Thursday so the uPortal release will be either Friday or Monday. Just
an FYI if you have fixes/changes you'd like to get into 4.0.4

-Eric





--
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] Notifications/Alerts/Announcements

[Anthony Colebourne]

Hi Jen,

This proposal sounds really great, though having not yet got started 
with 286 Portlets I really cannot comment further.


An interesting use case we have though is that we want to display 
content specific notifications. E.g. scheduled downtime of our student 
system.


There are several integration points in our portal where we pull content 
from or provide links into our student system.


Each of these custom portlets has a portlet preference, that when set 
will display a message inline within the content or optionally will 
replace the actual content.


I was wondering whether I could include a portlet in the header for 
every user that would output notices. Then perhaps in the skin xslt 
these notices would be matched to portlets in the active tab and written 
before or in place of the portlet content. I guess some stuff might also 
be possible client side.


I imagined a publish time parameter which would allow portlets to be 
subscribed to certain notice tags thus facilitating the matching process 
above.


Thanks,
Anthony.


On 19/12/11 16:56, Jen Bourey wrote:

Hi all,

I wanted to open a discussion around some of the notifications-type
use cases we're starting to explore as part of the uMobile project.
The excellent new notifications (from University of Manchester) and
alerts (in the Jasig Widget Portlets) portlets have inspired a lot of
thought about how these new portlets fit together with each other,
with the announcements portlet, and with the portal as a whole.

The Notifications Portlet as it exists now aggregates person-specific
(rather than group) notifications from external services. It's
similar to the calendar or news portlets in that it merges together
data from disparate sources, and does not allow administrators to
create content directly in the portal.  I think this looks like a
great new portlet, and I've been wondering if we should think about
extending it and make it a core part of uMobile / uPortal.

In the case of something like courses, we have a courses portlet that
might display notifications inside of it (course-specific
announcements or forum updates, perhaps).  We then also have a
notifications portlet that might want to display course
announcements.  As things currently work, we might also write a
plugin the LMS to display course notifications in the notifications
portlet aggregated view.

In this use case, it seems like it might be interesting to use a
portlet event-based model like what we're using for the uPortal
search API.  Under this strategy, instead of having to develop an
additional courses plugin for the notifications portlet, the courses
portlet could publish notices to the notifications portlet via the
event API.  We could similarly publish to the notifications portlet
from the announcements portlet, the emergency alerts portlet, etc.

If we had this in place, I think the notifications portlet could take
a center-stage role in both uPortal and uMobile as a terrific
integration point and source of information for displaying good
dashboard information.  Does this sound like an attractive idea to
others?  Does the events model sound like a good fit?

The other notification-related thought I wanted to mention is that we
might want to explore having a way to create notifications from
within uPortal.  It would be neat to be able to use uPortal's
existing person selection interface to select a user, then send a
manual notification.  Of course, this integration might require
either making the portlet a framework portlet or connecting to a
uPortal person REST service.

- Jen




--
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] Microsoft EWS API

[Anthony Colebourne]

Hi,

Attached is a patch against CalendarPortlet rel-1-patches branch. The 
pom assumes that you have available

microsoft
EWSJavaAPI
1.1.5

Available from
http://archive.msdn.microsoft.__com/ewsjavaapi/Release/__ProjectReleases.aspx?__ReleaseId=5754
 


and

jcifs
jcifs
1.3.15

Available from http://maven.jahia.org/maven2/

Auto-discovery was my main sticking point. My pain was that I wanted the 
attributes used for authentication to be configurable. I.e. we use 
uid+password for Stuff (in house Exchange 2010 server) and 
email+password for Students (Hosted Live@EDU). Having auto-discovery an 
initialization service seemed sensible, but due to the different 
staff/student configurations I found myself needing to have 2 
initialization services. So I opted to do the auto-discovery within the 
adaptor on first use. (Also I would like the discovered url to be cached 
longer then the session, but couldn't be sure I could store a 
preference. As the adaptor API specifies PortletRequest).

Comments/feedback welcomed.

-- Anthony.




On 10/11/11 15:24, Anthony Colebourne wrote:
> Hi,
>
> When I tried the dropping 2010 into the JAX-B section of the pom, I did
> also droped in the xsd files. I cannot remember the exact issues but I
> didn't make any progress :-(
>
> 2 issues lead me to use a local copy of the wsdl and xsd files, 1) the
> missing endpoint and 2) access to the wsdl (at build time, although
> JAX-WS seems to also need access at runtime).
>
> I did have success with the JAX-WS maven plugin, but struggled when
> actually using it.
>
> On the negative side, I don't "think" that the EWSJavaAPI supports
> impersonation. This might be an issue for folks who do not have access
> to the users password.
>
> Cheers,
> Anthony.
>
>
> On 10/11/11 15:03, Jen Bourey wrote:
>> You actually don't really need a local WSDL; we added it to the project
>> because the one that's deployed in a lot of Microsoft implementations by
>> default is missing a key XML snippet and doesn't actually work. If your
>> WSDL works, you could just point it to the live one. My understanding is
>> that 2007 and 2010 are actually very close. If there are differences,
>> you might need to update the two XSD files with the ones on your server.
>> If you're interested in trying to get that working against your campus
>> server, let me know if there's anything we can do to help.
>>
>> Anyway, about the MS dependency: It's great to hear that that's easy to
>> use. I took a look at the license, and it looks like the Microsoft
>> license is on our A list, so including it in the project wouldn't be an
>> issue from a licensing perspective.
>>
>> - Jen
>>
>> On Thu, Nov 10, 2011 at 9:32 AM, Anthony Colebourne
>> > <mailto:anthony.colebou...@manchester.ac.uk>> wrote:
>>
>> Hi,
>>
>> I believe the current Jasig Exchange integrations are Exchange2008
>> not 2010? (I dropped my local version of the 2010 wsdl into the
>> calendar's maven config but things went badly wrong).
>>
>> I too have a JAX-WS generated implementation of the webservice, but
>> found it very complicated to use.
>>
>> In contrast the EWSJavaAPI is "ridiculously simple". Within
>> practically 10 mins on a test bed I was able to pull all the data I
>> needed from Email, Calendar, Tasks and Contacts with no local wsdl
>> or maven plugin to manage.
>>
>> -- Anthony.
>>
>>
>> On 10/11/11 14:22, Jen Bourey wrote:
>>
>> Hey Anthony,
>>
>> The calendar portlet actually already has an Exchange adapter
>> out of the
>> box. It uses spring-ws to connect to the services, which seems
>> not too
>> require too much custom code. I know Nick is also currently
>> doing some
>> EWS integration into the Scheduler too. Maybe there's an
>> opportunity to
>> create some documentation and best practices around Exchange
>> integration? How've you found the Java library your'e using to
>> be so far?
>>
>> - Jen
>>
>> On Thu, Nov 10, 2011 at 9:21 AM, Jen Bourey
>> mailto:jennifer.bou...@gmail.com>
>> <mailto:jennifer.bourey@gmail.__com
>> <mailto:jennifer.bou...@gmail.com>>> wrote:
>>
>> Hey Anthony,
>>
>> The calendar portlet actually already has an Exchange adapter out of
>> the box. It uses spring-ws to connect to the services, which seems
>> not too require too much custom code. I know Nick is also currently
>> doing some EWS integration into the Scheduler too. Maybe there's an
>> opportunity to create some docume

Re: [uportal-dev] Microsoft EWS API

[Anthony Colebourne]

Hi,

When I tried the dropping 2010 into the JAX-B section of the pom, I did 
also droped in the xsd files. I cannot remember the exact issues but I 
didn't make any progress :-(


2 issues lead me to use a local copy of the wsdl and xsd files, 1) the 
missing endpoint and 2) access to the wsdl (at build time, although 
JAX-WS seems to also need access at runtime).


I did have success with the JAX-WS maven plugin, but struggled when 
actually using it.


On the negative side, I don't "think" that the EWSJavaAPI supports 
impersonation. This might be an issue for folks who do not have access 
to the users password.


Cheers,
Anthony.


On 10/11/11 15:03, Jen Bourey wrote:

You actually don't really need a local WSDL; we added it to the project
because the one that's deployed in a lot of Microsoft implementations by
default is missing a key XML snippet and doesn't actually work. If your
WSDL works, you could just point it to the live one. My understanding is
that 2007 and 2010 are actually very close. If there are differences,
you might need to update the two XSD files with the ones on your server.
If you're interested in trying to get that working against your campus
server, let me know if there's anything we can do to help.

Anyway, about the MS dependency: It's great to hear that that's easy to
use. I took a look at the license, and it looks like the Microsoft
license is on our A list, so including it in the project wouldn't be an
issue from a licensing perspective.

- Jen

On Thu, Nov 10, 2011 at 9:32 AM, Anthony Colebourne
mailto:anthony.colebou...@manchester.ac.uk>> wrote:

Hi,

I believe the current Jasig Exchange integrations are Exchange2008
not 2010? (I dropped my local version of the 2010 wsdl into the
calendar's maven config but things went badly wrong).

I too have a JAX-WS generated implementation of the webservice, but
found it very complicated to use.

In contrast the EWSJavaAPI is "ridiculously simple". Within
practically 10 mins on a test bed I was able to pull all the data I
needed from Email, Calendar, Tasks and Contacts with no local wsdl
or maven plugin to manage.

-- Anthony.


On 10/11/11 14:22, Jen Bourey wrote:

Hey Anthony,

The calendar portlet actually already has an Exchange adapter
out of the
box. It uses spring-ws to connect to the services, which seems
not too
require too much custom code. I know Nick is also currently
doing some
EWS integration into the Scheduler too. Maybe there's an
opportunity to
create some documentation and best practices around Exchange
integration? How've you found the Java library your'e using to
be so far?

- Jen

On Thu, Nov 10, 2011 at 9:21 AM, Jen Bourey
mailto:jennifer.bou...@gmail.com>
<mailto:jennifer.bourey@gmail.__com
<mailto:jennifer.bou...@gmail.com>>> wrote:

Hey Anthony,

The calendar portlet actually already has an Exchange adapter out of
the box. It uses spring-ws to connect to the services, which seems
not too require too much custom code. I know Nick is also currently
doing some EWS integration into the Scheduler too. Maybe there's an
opportunity to create some documentation and best practices around
Exchange integration? How've you found the Java library your'e using
to be so far?

- Jen



On Nov 9, 2011, at 7:31 PM, Anthony Colebourne wrote:

cc: licens...@jasig.org <mailto:licens...@jasig.org>
<mailto:licens...@jasig.org <mailto:licens...@jasig.org>>


Hi,

I want to contribute some Exchange 2010 adapters (development in
progress).
* CalendarPortlet
* NotificationsPortlet
Also in future
* ContactsPortlet
* EmailPreviewPortlet
* ScheduleAssistant

The jar is available form

http://archive.msdn.microsoft.__com/ewsjavaapi/Release/__ProjectReleases.aspx?__ReleaseId=5754

<http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5754>

Would it be possible to get this into Jasig's Maven repo?

It has the following dependencies:
Apache Commons HttpClient 3.1
Apache Commons Codec 1.4
Apache Commons Logging 1.1.1
JCIFS 1.3.15

JCIFS is available from http://maven.jahia.org/maven2/
Others available in Maven central.

Could these dependencies also be made available?

Thanks,
Anthony.

--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto

Re: [uportal-dev] Microsoft EWS API

[Anthony Colebourne]

Hi,

I believe the current Jasig Exchange integrations are Exchange2008 not 
2010? (I dropped my local version of the 2010 wsdl into the calendar's 
maven config but things went badly wrong).


I too have a JAX-WS generated implementation of the webservice, but 
found it very complicated to use.


In contrast the EWSJavaAPI is "ridiculously simple". Within practically 
10 mins on a test bed I was able to pull all the data I needed from 
Email, Calendar, Tasks and Contacts with no local wsdl or maven plugin 
to manage.


-- Anthony.

On 10/11/11 14:22, Jen Bourey wrote:

Hey Anthony,

The calendar portlet actually already has an Exchange adapter out of the
box. It uses spring-ws to connect to the services, which seems not too
require too much custom code. I know Nick is also currently doing some
EWS integration into the Scheduler too. Maybe there's an opportunity to
create some documentation and best practices around Exchange
integration? How've you found the Java library your'e using to be so far?

- Jen

On Thu, Nov 10, 2011 at 9:21 AM, Jen Bourey mailto:jennifer.bou...@gmail.com>> wrote:

Hey Anthony,

The calendar portlet actually already has an Exchange adapter out of
the box. It uses spring-ws to connect to the services, which seems
not too require too much custom code. I know Nick is also currently
doing some EWS integration into the Scheduler too. Maybe there's an
opportunity to create some documentation and best practices around
Exchange integration? How've you found the Java library your'e using
to be so far?

    - Jen



On Nov 9, 2011, at 7:31 PM, Anthony Colebourne wrote:


cc: licens...@jasig.org <mailto:licens...@jasig.org>

Hi,

I want to contribute some Exchange 2010 adapters (development in
progress).
* CalendarPortlet
* NotificationsPortlet
Also in future
* ContactsPortlet
* EmailPreviewPortlet
* ScheduleAssistant

The jar is available form

http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5754

Would it be possible to get this into Jasig's Maven repo?

It has the following dependencies:
Apache Commons HttpClient 3.1
Apache Commons Codec 1.4
Apache Commons Logging 1.1.1
JCIFS 1.3.15

JCIFS is available from http://maven.jahia.org/maven2/
Others available in Maven central.

Could these dependencies also be made available?

Thanks,
Anthony.

--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as:
jennifer.bou...@gmail.com <mailto:jennifer.bou...@gmail.com>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev





--
Jen Bourey

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Microsoft EWS API

[Anthony Colebourne]

cc: licens...@jasig.org

Hi,

I want to contribute some Exchange 2010 adapters (development in progress).
 * CalendarPortlet
 * NotificationsPortlet
Also in future
 * ContactsPortlet
 * EmailPreviewPortlet
 * ScheduleAssistant

The jar is available form
http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5754

Would it be possible to get this into Jasig's Maven repo?

It has the following dependencies:
Apache Commons HttpClient 3.1
Apache Commons Codec 1.4
Apache Commons Logging 1.1.1
JCIFS 1.3.15

JCIFS is available from http://maven.jahia.org/maven2/
Others available in Maven central.

Could these dependencies also be made available?

Thanks,
Anthony.

--
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] Vote for UP-2960 uP 3.2.5

[Anthony Colebourne]

Hi,

I've seen a few posts that talk about a uP 3.2.5 release.

The issue UP-2960 is causing us some pain. I'd be very happy to help 
getting this fixed by way of testing and posting errors / stack traces.


The reason I've posted a 'vote' in this way is that I've not seen much 
discussion around this issue, yet its quite rightly is marked as a blocker.


Generally with issues such as this I see lots of discussion, so I'm 
wondering whether it is only an issue in certain edge cases?


Thanks,
Anthony.

p.s. Do people use Jira voting?

--
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] Nokia N900 user agent

[Anthony Colebourne]

Sorry I really should have read the thread "uPortal with Mobile" before 
posting ;-)


-- Anthony,

Anthony Colebourne wrote:

Hi,

Just playing with uP 3.2.1 on a Nokia N900, it didn't detect that it was 
a mobile device.


Here is the user agent:

"Mozilla/5.0 (X11; U; Linux armv7l; en-GB; rv:1.9.2a1pre) Gecko/20091127 
Firefox/3.5 Maemo Browser 1.5.6 RX-51 N900"


Should I create a Jira for this?

 do we need another Jira Component setting up for mobile issues?

-- Anthony.



--
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] Nokia N900 user agent

[Anthony Colebourne]

Hi,

Just playing with uP 3.2.1 on a Nokia N900, it didn't detect that it was 
a mobile device.


Here is the user agent:

"Mozilla/5.0 (X11; U; Linux armv7l; en-GB; rv:1.9.2a1pre) Gecko/20091127 
Firefox/3.5 Maemo Browser 1.5.6 RX-51 N900"


Should I create a Jira for this?

 do we need another Jira Component setting up for mobile issues?

-- Anthony.

--
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] Multi-valued Attributes in PersonDirectoryUserInfoService

[Anthony Colebourne]

+1 for getting this into 3.0.5

Great work, Thanks.

-- Anthony.


Eric Dalquist wrote:

Eric's patch will be in 3.2 and likely in 3.1.2 and 3.0.5

The problem with changing the results of USER_INFO is the JSR-168 spec 
PDF explicitly states that it returns Map so we can't 
change that at all. The spec was written before generics so the 
interface doesn't document that. There are also specific rules about 
what a null value for an existing key versus a missing key and such all 
detailed in the spec.



-Eric

Chris Doyle wrote:

Nice!  I'll check this out...

Thanks!

--Chris
  


--
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] nominating Eric Dalquist to serve again

[Anthony Colebourne]

+1 vote from Manchester.

-- Anthony.

Susan Bramhall wrote:
I believe the developers need 2 representatives on the steering 
committee.  I would like to nominate Eric Dalquist to continue on the 
committee.  As the lead developer is contribution is extremely 
valuable.  Although he is enjoying some personal time off at the moment 
I believe he is willing to serve for another term.

Susan
--

Susan Bramhall (susan.bramh...@yale.edu )
Senior Developer, Technology & Planning Operations (T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone:  203 432 6697

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] Nominating Jen Bourey for uPortal Project Steering Committee

[Anthony Colebourne]

+1 vote form Manchester.

-- Anthony.

Andrew Petro wrote:

uPortal developers,

I'd like to nominate Jen Bourey as a uPortal developer representative to 
the uPortal Steering Committee.


I believe Jen needs no introduction to the community of uPortal 
committers, but I'd nonetheless take a moment to remind of her recent 
and ongoing contributions to uPortal.


Ohloh credits  Jen with more 
than 200 commits to the uPortal codebase (which feels awfully low, in 
part because Jen has been a leader or major contributor to several Jasig 
portlet projects, including the Calendar portlet 
, the Feedback 
portlet 
, 
and the Tabbed Search portlet 
). Jen has 
given several popular Jasig conference presentations about uPortal, 
including on JavaScript in uPortal 3, on using AJAX to improve the user 
experience, on uPortal 3 configuration and deployment automation, and on 
open source portlet incubation.


Jen regularly posts to this developer email list and has answered many 
questions on the uportal-user@ email list. She is also regularly 
available and active in the uPortal IRC channel.


In short, I believe Jen is eminently qualified to represent uPortal 
developers on the uPortal project steering committee and I would expect 
she would bring enthusiasm, technical competence, and particularly 
attention to continuing to grow the set of portlets and the quality of 
the user experience in uPortal.


With many thanks to Jen for all her contributions to uPortal,

Andrew


- Original Message -
From: "Jonathan Markow" 
To: uportal-dev@lists.ja-sig.org
Cc: "uPortal PSC" , 
cas-steering-commit...@lists.ja-sig.org, "JA-SIG Board" 

Sent: Wednesday, June 10, 2009 8:48:29 AM GMT -07:00 U.S. Mountain Time 
(Arizona)
Subject: [uportal-dev] Developer Representatives to Project Steering 
Committees


Developers:

You have received a couple of emails recently about the Jasig 2009 
Elections, during which our membership will be selecting stakeholder 
positions on the project steering committees for both uPortal and CAS.


At the same time we will be asking you to select developer 
representatives to each of the committees. uPortal has two developer 
positions and CAS has one:


Current uPortal Reps:
Eric Dalquist
Andrew Petro

Current CAS Rep:
Scott Battaglia

These developer positions are not subject to term limits, and incumbents 
may serve successive terms. But we do ask each team to revisit their 
selections each year and make fresh recommendations.


The way the process works is this:

1. Any developer may serve if selected
2. Only committers have votes; they are not required to belong to 
Member organizations

3. Discussion is open to all on the developer lists
4. Please initiate discussion on your list when the spirit moves you 
(This week would be a good time to start :-)

5. You may nominate others or yourself
6. We will need a decision on your selections by the end of the 
Jasig election process, which is July 17, 2009
7. Committee chairs should monitor these selections and report 
results back to the steering committees.

8. New terms officially begin on September 1, 2009

Questions? Please feel free to ask.

Thank you!
Jonathan




--
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: 
anthony.colebou...@manchester.ac.uk
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] Encryption of cached passwords

[Anthony Colebourne]

Hi,

+1 support for this.

While at the conference in Dallas, I discussed with many people about 
the CAS ClearPass code. I spoke mainly about the longevity of this 
codebase, many people were in support of getting this code to a level 
where it would be maintained across such changes.


Would such a change impact on this code? A feature where password were 
encrypted at the CAS end before being transfered into the portal session 
as pre-encrypted could benefit this code.


http://www.ja-sig.org/wiki/display/CAS/Proxying+clear-text+credentials

Thanks,
Anthony.

Jen Bourey wrote:

Hi all,

I wanted to propose contributing some uPortal enhancements on behalf of 
the University of Chicago.  The enhancements improve the existing 
CachePasswordSecurityContext to encrypt the password with a 
Spring-configurable encryption service before storing it in the 
session.  We've also updated the CachedPasswordUserInfoService to 
configurably either decrypt the cached password before adding it to a 
portlet's UserInfoMap, or to pass it through in its encrypted form.  
These changes are intended to preserve the ability of uPortal to 
potentially cache user passwords, while ensuring that any passwords 
present in the user session are encrypted.


Is this a change that we could contribute to the uPortal 3.2-oriented trunk?

- Jen


--
Jen Bourey

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
anthony.colebou...@manchester.ac.uk
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] SVN

[Anthony Colebourne]

Hi,

Thanks Eric for your help. I expect I'll be getting most of my
experience from the CalendarPortlet project, but it's a real boost to
have a uPortal commit under my belt.

Also I expect Jen will want to manage the CalendarPortlet releases in
much the same way.

-- Anthony.

Eric Dalquist wrote:
> Anthony Colebourne wrote:
>> Hi,
>>
>> Just made a small commit on uPortal!
>>
>> 1) I committed to the Trunk. Should I have also merged this to the
>> rel-3-0-patches?
>>   
> Yes please, also if you wouldn't mind using the svnmerge utility to do
> so it would be much appreciated:
> http://www.ja-sig.org/wiki/display/UPC/Branch+Maintenance
>> 2) The commit log contained the JIRA number (UP-2048), is there a batch
>> process that updates JIRA at some point or is this a manual process?
>>   
> Once the patch has been comitted to all fix-for versions you can resolve
> the Jira issue. I added you to the uportal-developers group in Jira so
> you should see some new options now.
>> 3) JIRA fix-for tag? I see most issues have this set, UP-2048 did not.
>> Can anybody explain how this should work.
>>   
> Fix-for marks the next versions that will have the patch included. In
> this case it would be 3.0.1 and 3.1.0
>> I remember a few years back there was a wiki page about uPortal's CVS
>> strategy, is there an SVN equivalent?
>>
>> (http://www.ja-sig.org/wiki/display/UPC/uPortal+CVS)
>>   
> There isn't such a page but we should probably create one and remove the
> CVS page.
>> Thanks,
>> Anthony.
>>
>>   

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

[uportal-dev] SVN

[Anthony Colebourne]

Hi,

Just made a small commit on uPortal!

1) I committed to the Trunk. Should I have also merged this to the
rel-3-0-patches?

2) The commit log contained the JIRA number (UP-2048), is there a batch
process that updates JIRA at some point or is this a manual process?

3) JIRA fix-for tag? I see most issues have this set, UP-2048 did not.
Can anybody explain how this should work.

I remember a few years back there was a wiki page about uPortal's CVS
strategy, is there an SVN equivalent?

(http://www.ja-sig.org/wiki/display/UPC/uPortal+CVS)

Thanks,
Anthony.

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

Re: [uportal-dev] proposing Anthony Colebourne as a portlet project committer

[Anthony Colebourne]

Thank you everybody for your vote of confidence  :-)

-- Anthony.

Jen Bourey wrote:
> Hi all,
> 
> I'd like to propose making Anthony Colebourne a committer for the
> portlet projects.  He's written some excellent adapters for Oracle
> Calendar and Blackboard Vista for the calendar portlet project.  He's
> also had some great input and fixes for the core calendar portlet code. 
> I'd love for him to be able to continue to easily contribute code, as
> well as keep his contributed code up to date.
> 
> I'm CC'ing the uportal dev list, since I believe at the current moment
> the portlet and uportal subversion spaces share a committer list.
> 
> - Jen
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
> PROTECTED]
> 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: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev