[jasig-uportal-dev] moving portlets to svn

[Eric Dalquist]

I'm going to be working on migrating the portal_portlets CVS module to 
SVN this evening. The actual migration will take place tomorrow 
(Wednesday) morning unless there are any objections or issues 
discovered. Also if there are other projects that folks would be 
interested in getting moved to SVN please let me know and we can 
coordinate moving other projects as well.


-Eric

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in 
Denver, CO USA.

Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source

For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe click here: 
https://lists.wisc.edu/u?id=5712631E&n=T&l=jasig-uportal-dev&o=4534733
or send a blank email to [EMAIL PROTECTED]

Re: [jasig-uportal-dev] moving portlets to svn

[Eric Dalquist]

So I ran into a few issues this morning so the migration will be later 
in the day.


-Eric

Eric Dalquist wrote:
I'm going to be working on migrating the portal_portlets CVS module to 
SVN this evening. The actual migration will take place tomorrow 
(Wednesday) morning unless there are any objections or issues 
discovered. Also if there are other projects that folks would be 
interested in getting moved to SVN please let me know and we can 
coordinate moving other projects as well.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] moving portlets to svn

[Eric Dalquist]

All JA-SIG portlet projects have been moved to subversion. They can be 
viewed via FishEye: 
http://developer.ja-sig.org/source/browse/jasigsvn/portlets The portlet 
files in CVS have also been moved to the attic.


Chris Doyle will be going through documentation to ensure the wiki 
points to the new location.


-Eric

Eric Dalquist wrote:
So I ran into a few issues this morning so the migration will be later 
in the day.


-Eric

Eric Dalquist wrote:
I'm going to be working on migrating the portal_portlets CVS module 
to SVN this evening. The actual migration will take place tomorrow 
(Wednesday) morning unless there are any objections or issues 
discovered. Also if there are other projects that folks would be 
interested in getting moved to SVN please let me know and we can 
coordinate moving other projects as well.


-Eric



smime.p7s
Description: S/MIME Cryptographic Signature

[jasig-uportal-dev] uPortal 2 CVS to SVN

[Eric Dalquist]

Picking up on some discussion from a while back I'm going to be moving 
the uPortal 2 CVS code to SVN this afternoon. There will be another 
email when the move is complete. All tags, branches and version history 
will be retained.


_*If you have the uPortal 2 source code checked out you will need to 
remove that project and checkout from svn after the move.*_



-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] uPortal 2 CVS to SVN

[Eric Dalquist]

The uPortal 2 source code has been migrated to Subversion. The base URL 
for the subversion repository is here: https://www.ja-sig.org/svn/up2/


All of the tags and branches have been preserved, the portal module in 
CVS will be changed to read only shortly so no further commits can be 
done there. The wiki documentation and uportal website will be updated 
tomorrow morning.


-Eric

Eric Dalquist wrote:
Picking up on some discussion from a while back I'm going to be moving 
the uPortal 2 CVS code to SVN this afternoon. There will be another 
email when the move is complete. All tags, branches and version 
history will be retained.


_*If you have the uPortal 2 source code checked out you will need to 
remove that project and checkout from svn after the move.*_



-Eric 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] uPortal 2 CVS to SVN

[Eric Dalquist]

The appropriate approach would be to create a diff of your changes then 
check out the same branch/version from SVN and apply the diff locally.


-Eric

Vangel V. Ajanovski wrote:

Eric Dalquist wrote:
The uPortal 2 source code has been migrated to Subversion. The base 
URL for the subversion repository is here: 
https://www.ja-sig.org/svn/up2/
Is there some automated way to switch from CVS to Subversion in my 
checked-out version of uPortal which has a dozen of modifications? If 
check it out of Subversion again, I will loose all my modifications 
and then I will have to manually change the modified files. 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] SVN accounts

[Eric Dalquist]

I can also create SVN accounts for folks on a case by case basis (to 
make sure Andrew doesn't get overwhelmed).


-Eric

Andrew Petro wrote:

uPortal developers,

The move from CVS to SVN is an excellent and large step forward for 
uPortal.  I appreciate not having to SSH tunnel anymore.


However, one overlooked detail in this migration is: the user CVS 
accounts did not migrate.  People who previously were able to commit 
to the uPortal project, largely, are no longer able to do so, because 
you don't have an SVN account.


For now, this will be handled on a case by case basis.  Please contact 
me when you're ready to have your SVN account created and we'll 
synchronize on a password for the new account.


Andrew



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] SVN accounts

[Eric Dalquist]

George,

We can look into doing that, I'll keep folks posted on progress.

-Eric

George Lindholm wrote:

Andrew Petro wrote:
  

uPortal developers,

The move from CVS to SVN is an excellent and large step forward for
uPortal.  I appreciate not having to SSH tunnel anymore.

However, one overlooked detail in this migration is: the user CVS
accounts did not migrate.  People who previously were able to commit to
the uPortal project, largely, are no longer able to do so, because you
don't have an SVN account.



Hi Andrew,
  any chance you could use mod_auth_external
(http://www.unixpapa.com/mod_auth_external/) and use
/etc/passwd for authentication so that
we can manage our own passwords through passwd?

Thanks

   George

  


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jasig-uportal-dev] svn browser down?

[Eric Dalquist]

The recent migration of up2 to svn seems to have overloaded it. We will 
be doing some svn cleanup later this week or early next to address the 
issues.


-Eric

George Lindholm wrote:

The web interface to svn seems to be down.

   George

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in 
Denver, CO USA.

Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source

For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
  


smime.p7s
Description: S/MIME Cryptographic Signature

[jasig-uportal-dev] cas3 and portal_channels moving to SVN

[Eric Dalquist]

I've worked out a time with ScottB and will be moving CAS3 to SVN 
tomorrow (Friday May 4). That will leave portal_channels as the only 
code left in CVS so I will be moving it to SVN tomorrow as well.


I would like to have a sanity check from other users to verify that 
everything of interest has been moved to SVN. Once the migration is 
complete the CVS repository will be converted to read-only for a while 
before being removed to ensure people can migrate local modifications 
over to the new repository.


-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[jasig-uportal-dev] Subversion Migration Complete

[Eric Dalquist]

All projects have been migrated from the JA-SIG CVS repository to the 
Subversion repository. The repository can be found here: 
https://www.ja-sig.org/svn/ The CVS repository will remain available for 
the next few weeks but will be read-only.


If you need a SVN account for commit access please email me directly.


-Eric Dalquist


smime.p7s
Description: S/MIME Cryptographic Signature

[jasig-uportal-dev] Fix for UP-1040 (portlet preferences bug)

[Eric Dalquist]

Tim Carrol's latest patch for 
http://www.ja-sig.org/issues/browse/UP-1040 appears to be working 
correctly. I've tested it in the 2.5-patches branch and the trunk and 
applied it to both locations. This should resolve the common shared 
portlet preferences bug.


-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] re-architected approach to managing jar dependencies

[Eric Dalquist]

Sounds like a great change!

-Eric

Andrew Petro wrote:

uPortal developers,

Drew Wills and I cooked up a new approach to managing .jar 
dependencies in uPortal that I'd like to use for the 2.6 release.


The fundamental idea is that instead of build.properties properties 
naming paths to individual .jars and hard-coded logic in build.xml to 
treat these .jars differently, such that to add a .jar you've gotta 
update build.properties and build.xml, there are instead (optionally 
configurable) magic directories.  The build process discovers .jars in 
these directories and treats them according to the properties of the 
directory they're in.  To add a .jar to the build, simply drop it into 
the /lib/compile directory.  To instruct the build to include a .jar 
at compile time but not deploy it with uPortal because you believe 
your container will provide it, stick it in /lib/provided .  Etc.


This approach makes it easier to update .jars in maintaining uPortal 
(less configuration to update every time a .jar changes) yet allows 
the build to continue to include .jar names that include version 
numbers for easy identification.


This approach also allows uPortal deployers to add locally required 
.jars without touching build.properties and/or build.xml


I've committed a working version of this new approach in HEAD for 
developer community review.  If it ends up blowing up I'll be happy to 
back it out, but I hope it can roll forward alleviate some of the pain 
of keeping dependencies up to date.  I'm testing support for some of 
the extra build targets, such as JavaDoc generation, now.


Andrew

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
[EMAIL PROTECTED]
To unsubscribe send a blank email to 
[EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Portlet API source

[Eric Dalquist]

The Pluto project hosts the source code for the portlet api. Their SVN 
repository is: http://svn.apache.org/repos/asf/portals/pluto


-Eric

Paul Gazda wrote:

Is the source code for the Portlet API (portlet-api-1.0.jar) available
anywhere?

Paul Gazda
Senior Web Developer
Information Technology Services
Northern Arizona University
[EMAIL PROTECTED]
(928) 523-6844



--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in 
Denver, CO USA.

Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source

For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
  


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] compelling ootb JSR-168s in 2.6?

[Eric Dalquist]

The bookmarks portlet (in SVN) is very simple / easy to configure. It 
would just need to be configured to use the portal db.


-Eric

Andrew Petro wrote:

uPortal developers,

Maybe too late for Friday's RC feature-completeness deadline, but I 
gotta ask:


Anyone have any compelling generic JSR-168s under suitable opensource 
licenses they'd like to ship with uP 2.6?  Those JSR-168 examples 
we're shipping aren't totally thrilling -- I gotta believe this 
community has got better examples.


If you can't get your portlet in for 2.6, it's not too early to commit 
efforts to make 2.7 sing...


I'm going to take a look at Eric's Bookmarks portlet this evening, see 
whether that can be a quick win.


Small. Simple.  Quick.  Low-risk.  But more compelling than that 
Google portlet would be nice...


Andrew


--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
[EMAIL PROTECTED]
To unsubscribe send a blank email to 
[EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Bookmarks Portlet

[Eric Dalquist]

Sounds wonderful Chris. With the current place bookmarks is I think you 
can probably do the development in the trunk. If we need to fix 
something in 1.0.7 we can just branch back there and fix it. My first 
thought as to how to approach the changes would be in an incremental 
fashion so things still work after each change. That may not be possible 
for all changes but it is a noble goal :)


Also would you be interested in being listed as the project lead for 
bookmarks? All that means is you get to cut releases (or delegate that 
responsibility) and manage the Jira project.


Thanks for the interest in moving bookmarks forward.
-Eric

Chris Doyle wrote:

I just wanted to give everyone a quick heads-up regarding some work I am
interested in tackling (pending the groups' blessings, of course).  Last
year I began working on (yet another) Bookmarks Portlet here at JHU,
which was prior to my awareness of Eric's.  At the developer's meeting
in April, I shared my progress with Eric and we agreed it might be
beneficial to try and merge some of the more useful features of mine in
with his.  Most notably, I have implemented features that address the
following open issues:

PBOOK-7Drag and drop folder and bookmark moving
PBOOK-24   Seeding the bookmarks portlet
PBOOK-25   Multiply publishable
PBOOK-26   Multiply subscribable (*partially begun work on
subscription mechanism)
PBOOK-27   Read-only, administrator updatable mode
PBOOK-29   CBookmarks upgrade path
PBOOK-42   Provide a user option for default folder state

To begin this work, I'd like to create a new working development branch
in SVN:


https://www.ja-sig.org/svn/portlets/BookmarksPortlet/branches/JHU

I don't anticipate being able to complete the merge in time for the
upcoming conference, but would like to aim for a release later this
summer.  How does this all sound to everyone?

Just a little background on my current version...

- It's already Maven-ized (using Maven2)
- I use the Spring Portlet MVC (the project is very Spring-y in
general)
- I use the concept of "groupings" or sets of bookmarks:
- Conceptually, one XBEL document = one grouping
- Groupings can be "pushed" to specific uPortal
users/groups
- Administration of groupings can be delegated to
specific users/groups
- Groupings can be set to read-only
- There are some nice portlet parameters for configuration
- I have written some web services around it using Axis2
- I developed and use both a Java client, as well as a
JS client via AJAX
- due to AJAX web service calls, there are very few
actual page reloads
- I wrote a conversion utility used to upgrade from CBookmarks
- Caching using ehcache
- The UI is pretty nice (floating DIVs for input, dropdown
menus, etc.)
- Drag and Drop!  :)

All that being said, there are also some major deficiencies,
limitations, and definitely some portability obstacles to be addressed.
(Everything is a constant work in progress, right?)  But I think I might
be ambitious (or crazy) enough to give this merge a try.

Thoughts?  Blessings?  Curses?

Thanks,

--Chris

  


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] about licenses

[Eric Dalquist]

I don't think maven gets us around this. The big thing with GPL jars is 
if they have the classpath exception:


http://www.gnu.org/software/classpath/license.html
http://en.wikipedia.org/wiki/GPL_linking_exception

That exception allows distribution of GPL jars that have it as long as 
you don't change the jar in any way.


-Eric

Jason Shao wrote:

On Jun 1, 2007, at 1:29 PM, Andrew Petro wrote:

I see two needs of an opensource project respecting the licenses of 
its dependencies.


One is to actually comply with the terms of those licenses, which 
often includes a requirement of acknowledgement and inclusion of the 
license under which the dependency is used in and redistributed with 
the project.


Two is to document this compliance in such a way that one can be 
reasonably confident in it and that it is maintainable.


For example, it might technically be sufficient for license X to 
appear somewhere in the project and to ship Jar Y which is available 
under license X.  It's still desirable to articulate that that's what 
we're doing, otherwise over and over again people will have to wonder 
about whether and how we're shipping Jar Y.


Moving this to uportal-dev...

Hmmm... biggest license compliance question for me is whether it's 
legit to bundle GPL jars (Apache doesn't -- our license looks a lot 
like theirs). 

Does Maven get us around this (since we're not redistributing the 
artifacts?)


Jason

--

Jason Shao
Application Developer
Rutgers University, Office of Instructional & Research Technology
v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
 | http://jay.shao.org




--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
%%emailaddr%%.
To unsubscribe send a blank email to 
[EMAIL PROTECTED] 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Bookmarks Portlet

[Eric Dalquist]

I'd like to see the following for bookmarks and for 'birthing' projects 
in general.


- The project should be maven based and follow the outline here 
http://www.ja-sig.org/wiki/x/QgIl
-- Along these lines project leads need SSH access to the ja-sig.org 
machine to publish maven artifacts & sites
- The 'main' web-presence for the project should be in confluence, 
weather a whole space or just a set of pages in the 
Portlets/Channels/Services spaces
- The project confluence presence should link to the maven generated 
site. The separation here is that the confluence space is more end user 
documentation where as the maven site is generated developer documentation.

- Lists should be created, as JimH stated this is a very cheap process.
- A Jira project should be created for the project.

Bookmarks has all of this except a more focused presence in Confluence 
and mailing lists. Things we can solve this week.


-Eric

PS: I'd like to get feedback on that list and stick it in the wiki 
eventually.




Chris Doyle wrote:


I would very much love to see this project break out of the 
aforementioned “trappings of projectness” as well, yes. Is there a 
venue preference for its web presence (wiki vs. 
http://www.ja-sig.org/products/portlets/bookmarks/)? I’m a fan of 
cleaning up the Channels and Portlets spaces in the wiki, following 
suit with the great work being done in the uPortal manual space. I’m 
also a fan of creating supporting e-mail lists for such projects, so 
long as it doesn’t create more of an administrative burden than it’s 
worth. Any thoughts on naming convention for such lists 
(@lists.ja-sig.org)?


--Chris

*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew Petro

*Sent:* Saturday, June 02, 2007 1:14 PM
*To:* uportal-dev@lists.ja-sig.org
*Subject:* Re: [uportal-dev] Bookmarks Portlet

Chris,


The incremental approach sounds best, yes.  I have no problem being
listed as the project lead, so long as it's okay with everyone else.
  



+1 [1] for an incremental approach involving making these improvements 
in bookmarks /trunk and frequently tagging and releasing working code.


Thanks to some last-minute assistance by Eric and others, this 
Bookmarks Portlet will ship with uPortal 2.6.0 as an example 
showcasing the JSR-168 support. I'd love to see it be feasible to 
include updated versions of the portlet in subsequent patch releases 
of 2.6.


Chris, per our discussion at the JHU dev meeting, I wonder if this is 
an opportunity to build out the "trappings of projectness" around this 
project -- a clearer web presence, whether in confluence or at 
http://www.ja-sig.org/products/portlets/bookmarks/. Email list(s) 
dedicated to discussing developing and deploying this portlet could 
help to give it identity?


Andrew

[1]: (including the Apache sense of implicit volunteerism to help if 
necessary)


-Original Message-
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Dalquist
Sent: Saturday, June 02, 2007 9:44 AM
To: uportal-dev@lists.ja-sig.org <mailto:uportal-dev@lists.ja-sig.org>
Subject: Re: [uportal-dev] Bookmarks Portlet
 
Sounds wonderful Chris. With the current place bookmarks is I think you 
can probably do the development in the trunk. If we need to fix 
something in 1.0.7 we can just branch back there and fix it. My first 
thought as to how to approach the changes would be in an incremental 
fashion so things still work after each change. That may not be possible
 
for all changes but it is a noble goal :)
 
Also would you be interested in being listed as the project lead for 
bookmarks? All that means is you get to cut releases (or delegate that 
responsibility) and manage the Jira project.
 
Thanks for the interest in moving bookmarks forward.

-Eric
 
Chris Doyle wrote:
  


I just wanted to give everyone a quick heads-up regarding some work I




am
  


interested in tackling (pending the groups' blessings, of course).




Last
  


year I began working on (yet another) Bookmarks Portlet here at JHU,

which was prior to my awareness of Eric's.  At the developer's meeting

in April, I shared my progress with Eric and we agreed it might be

beneficial to try and merge some of the more useful features of mine




in
  


with his.  Most notably, I have implemented features that address the

following open issues:

 


  PBOOK-7Drag and drop folder and bookmark moving

  PBOOK-24   Seeding the bookmarks portlet

  PBOOK-25   Multiply publishable

  PBOOK-26   Multiply subscribable (*partially begun work on

subscription mechanism)

  PBOOK-27   Read-only, administrator updatable mode

  PBOOK-29   CBookmarks upgrade path

  PBOOK-42   Provide a user option for default folder state

 


To begin this work

Re: [uportal-dev] Bookmarks Portlet

[Eric Dalquist]

Jason Shao wrote:


On Jun 4, 2007, at 11:23 AM, Eric Dalquist wrote:

I'd like to see the following for bookmarks and for 'birthing' 
projects in general.


- The project should be maven based and follow the outline here 
http://www.ja-sig.org/wiki/x/QgIl


I doubt this is or should be a requirement. Even Apache doesn't 
*require* projects to be based on Maven. Having said that, for new 
development it certainly seems reasonable.


-- Along these lines project leads need SSH access to the ja-sig.org 
machine to publish maven artifacts & sites


Or they could have quickbuilder make them for them... ;) Scott -- do 
we have reusable enough steps we could provide a skeleton quickbuild 
project to do that kind of stuff?
Quickbuild seems to be good for continuous integration type work but for 
publishing artifacts & site based on a specific release of a project I'm 
not sure if quickbuild is the way to go versus just the mvn release 
plugin and an ssh account.


- The 'main' web-presence for the project should be in confluence, 
weather a whole space or just a set of pages in the 
Portlets/Channels/Services spaces
- The project confluence presence should link to the maven generated 
site. The separation here is that the confluence space is more end 
user documentation where as the maven site is generated developer 
documentation.


I think the key here is there's a developer focused site, and at least 
a short introduction/"marketing" site. What the project is, what it 
does, deployer documentation, etc.


Jason

--

Jason Shao
Application Developer
Rutgers University, Office of Instructional & Research Technology
v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]> | http://jay.shao.org




--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
%%emailaddr%%.
To unsubscribe send a blank email to 
[EMAIL PROTECTED] 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] birthing projects

[Eric Dalquist]

Although I am partial to -discuss we should probably stick with -user 
since that is what we have for uportal.


-Eric

Jason Shao wrote:

On Jun 3, 2007, at 11:55 AM, Andrew Petro wrote:


I'd look for a naming convention like:
[EMAIL PROTECTED]  for 
collaboration of actual development of a project, and
[EMAIL PROTECTED]  
for more open-ended discussion


I think -users is a more common convention than -discuss, I think it 
also helps scope the lists better.


Jason

--

Jason Shao
Application Developer
Rutgers University, Office of Instructional & Research Technology
v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
 | http://jay.shao.org




--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
%%emailaddr%%.
To unsubscribe send a blank email to 
[EMAIL PROTECTED] 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Brad Rippe uPortal commit access

[Eric Dalquist]

+1 from me.

-Eric

Andrew Petro wrote:

I'd like to grant (restore?) uPortal commiter status to Brad Rippe.

He's got a fix for IStatsRecorderEventHandlerAdapter that needs to go 
into /trunk for uP 2.6 .


In 2003 he wrote an article about uPortal in Java World 
.  
Work on a gradebook channel in uPortal 
.


+1

Andrew



--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
[EMAIL PROTECTED]
To unsubscribe send a blank email to 
[EMAIL PROTECTED] 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Remove tomcat 5.0.x support in 2.6.x, 2.7.x and beyond?

[Eric Dalquist]

Sounds like a good change to me and it should reduce a lot of confusion.

+1

-Eric

Cris J Holdorph wrote:
Hi, I was talking with Andrew Petro and Andrew Wills about the uPortal 
2.6.0 build.properties file.


It occurred to us that because uPortal 2.6 now requires JDK 1.5, it 
will be very hard, possibly "improbable", to deploy uPortal 2.6 on 
Tomcat 5.0.x.


Given this, does it make sense to remove the line that is currently 
commented out in build.properties for the tomcat 5.0.x config file, 
and to remove the tomcat 5.0.x config file (currently named 
uportal.xml) from the properties directory?


Andrew Wills and I agree tha change makes sense, but it's not the kind 
of change I want to do without some kind of validation from the 
developer community.


 Cris J H

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
[EMAIL PROTECTED]
To unsubscribe send a blank email to 
[EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal 2.6.0 RC2 now available

[Eric Dalquist]

Andrew,

Are there any particular things you would like a hand with for the 2.6 
release? If so let me know.


-Eric

Andrew Petro wrote:

uPortal developers,

uPortal 2.6.0 release candidate two is now available from the uPortal 
downloads page <http://www.uportal.org/release/allReleases.html>.


I hope it will be particularly helpful to have a latest-code release 
candidate available going into this conference,  making a binary 
available for easier testing, and providing a concrete artifact to 
talk about and open issues against.


Twenty-two non-trivial Jira issues have been resolved since release 
candidate one. Release notes are available in the wiki 
<http://www.ja-sig.org/wiki/display/UPC/2.6.0+RC2>.


2.6.0 includes many enhancements and fixes, including both those 
developed along the 2.5.x branch and new ones:


* Drag and Drop preferences
* fixed handling of portlet preferences
* a pluggable DLM processing pipeline
* XHTML output
* fixes and performance enhancements, including some derived from
  Unicon's Academus product
* CSyndFeedReader syndicated feed reader channel
* a more deployer-friendly approach to adding dependencies to
  uPortal builds
* dedicated error rendering thread pool
* now includes Eric Dalquist's Bookmarks Portlet and Cris
  Holdorph's Google AJAX search API integration portlet as
  examples of JSR-168 support
* updated versions of dependencies
* support for JSP as a channel view technology



Many people have contributed code, testing, feedback, and issues so 
far for uPortal 2.6.0, including Faizan Ahmed, Nick Bolton, Jen 
Bourey, Mark Boyd, Susan Bramhall, Eric Dalquist, Don Fracapane, David 
Grimwood, Cris Holdorph, Brad Johnson, George Lindholm, Elliot 
Metsger, and Jason Shao, to name a few. These people and others 
deserve thanks for their contributions to progress so far.



Andrew

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 
2007 in Denver, CO USA.


Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source


For more information & registration visit: 
http://www.ja-sig.org/conferences/07summer/index.html

---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
[EMAIL PROTECTED]
To unsubscribe send a blank email to 
[EMAIL PROTECTED] 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] caching XML and background refresh

[Eric Dalquist]

I'd actually like to get Matt from Duke involved here. From a portlet 
developer's point of view something that was more of a HTTP based 
service would work better since it could be used by more than just 
internal channels. From talking with Matt at the conference it sounds 
like he has a servlet that can do just that, it uses url parameters to 
denote remote urls, cache timeouts, dirty cache options and such. 
Expanding on that to support asynchronous retrieval seems like a natural 
progression.


Currently we have a little perl script that periodically goes out and 
fetches documents and caches them on the local file system, it works but 
as with others isn't the best solution.


I think it is time to start some requirements on the wiki and figure out 
what we need for a service like this for uPortal. (I'll do this on 
Monday if no one beats me to it).


-Eric

Cris J Holdorph wrote:
Sounds like a natural candidate to be done with Quartz.  I think 
adding Quartz to uPortal wouldn't be bad for this and potentially many 
other types of tasks.  If done well enough, a UI for an admin tool can 
even be created to allow the admin some control over the jobs that 
quartz is running and their schedules.


 Cris J H

Susan Bramhall wrote:
I'd like to see uPortal have the ability to cache XML documents used 
by channels and a worker of some kind that can refresh the cache in 
the background so that user requests do not wait for xml to be 
retrieved from badly behaved sites.


Yale has been running such a service for many years - but it is not 
entirely stable and I don't think it is a good design.  It relies on 
one background thread to refresh stale documents based on parameters 
passed.  It is enormously helpful to the portal's performance to have 
shared documents cached and refreshed on a requested interval.
How many other similar implementations are out there to address the 
problem of slow or broken external xml dependencies?


Would someone care to recommend or donate a robust and well designed 
implementation?


Susan





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal3 Community Goals and Objectives: A common path forward...

[Eric Dalquist]

Bill,

The list on the wiki looks great. It describes the upcoming goals well 
and an overview of what will be involved with getting there.


Currently I'm working on helping Andrew get 2.6 released so we can get 
started on the work on this list. Once we get to that point I'll be 
coming to this list for help deciding how to implement many of the 
changes described on the wiki.


-Eric

William G. Thompson, Jr. wrote:

uPortal Developers,

Those of you who where lucky enough to have attended the best JASIG 
Conference to date are already well aware of the exciting events that 
have unfolded this past week.  For all the others, this is an open 
invitation to join party and help continue to this great open source 
experiment called uPortal.


Already heady from the EDUCAUSE Catalyst Award announcement, the 
community crafted a common path forward toward the much anticipated 
uPortal3 release.  The ultimate goal is a uPortal3 GA release ready 
for production deployment by Winter 2007 that meets the community 
goals for a next generation Enterprise Portal Platform and leverages 
the best of uPortal2.


Discussions on the common path forward started at the the uPortal 
Developer lunch on Monday, continued through the conference and 
culminated at the BarCamp on Wednesday.


The common path forward provides a platform for evolution & innovation 
based on a modern software architecture, thus achieving the original 
goals of uPortal3, while leveraging as much as possible the production 
tested, scalable, award winning, rock solid uPortal2 code base.


A draft of the Community Goals and Technical Deliverables for uPortal3 
GA Winter 2007 is now available in the wiki at:


http://www.ja-sig.org/wiki/display/UP3/uPortal3+Community+Goals+and+Objectives 



This draft represents my personal take on the community consensus at 
the conference and needs to be discussed, vetted, modified, corrected, 
and spell checked before it can become an actionable plan. :)


I took the liberty to seed the Project Team section of the doc with 
examples for Eric, Elliot and myself.  If you are interested in 
collaborating on any of the technical deliverables please go ahead add 
yourself to the list.  Rutgers will be adding at least one developer, 
maybe two, to the list shortly.


Even if you can't yet commit to any of the deliverables, please don't 
hold back any comments, questions, suggestions, etc on the common path 
forward.


Cheers,
Bill


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Minimized portlets & DLM

[Eric Dalquist]

I'm working on http://www.ja-sig.org/issues/browse/UP-1768 which is an 
issue where the minimize change the chrome provides actually hides the 
portlet's output. Some logic needs to be added to the theme to allow the 
rendered output of a minimized portlet to be displayed (per the JSR-168 
spec). I'm looking for the appropriate place to add information to the 
layout about if the channel is a portlet or not.


The IUserLayoutChannelDescription interface has a "boolean isPortlet()" 
and the impl (UserLayoutChannelDescription) does properly implement this 
method. The "public void addNodeAttributes(Element node)" method didn't 
do anything with isPortlet but trying to add logic there to add the 
attribute doesn't seem to work and after adding a breakpoint in that 
method it doesn't appear to be used.


Anyone with more familiarity in the underpinnings of DLM know where the 
appropriate place would be to add detection of the type of  
element being added to the layout XML and adding a 
isPortlet=(true|false) attribute?


Thanks,
-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Minimized portlets & DLM

[Eric Dalquist]

Mark,

I haven't yet, though I haven't spent much time on it since I sent the 
email. Any pointers as to where in DLM I should look to add such an 
attribute to the XML the theme transform gets?


-Eric

Mark Boyd wrote:

Eric,

did you figure this out?

Mark

On 7/9/07, *Eric Dalquist* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]> > wrote:


I'm working on http://www.ja-sig.org/issues/browse/UP-1768
<http://www.ja-sig.org/issues/browse/UP-1768> which is an
issue where the minimize change the chrome provides actually hides the
portlet's output. Some logic needs to be added to the theme to
allow the
rendered output of a minimized portlet to be displayed (per the
JSR-168
spec). I'm looking for the appropriate place to add information to the
layout about if the channel is a portlet or not.

The IUserLayoutChannelDescription interface has a "boolean
isPortlet()"
and the impl (UserLayoutChannelDescription) does properly
implement this
method. The "public void addNodeAttributes(Element node)" method
didn't
do anything with isPortlet but trying to add logic there to add the
attribute doesn't seem to work and after adding a breakpoint in that
method it doesn't appear to be used.

Anyone with more familiarity in the underpinnings of DLM know
where the
appropriate place would be to add detection of the type of 
element being added to the layout XML and adding a
isPortlet=(true|false) attribute?

Thanks,
-Eric


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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] weird channel/portlet content substitution issue

[Eric Dalquist]

I'll see if I can get some cycles to look at this early next week. If it 
is the JSP race condition issue I'm thinking of the solution is to 
create a custom HttpServletRequest wrapper impl the container can't 
unwrap to ensure the JSP rendering request attributes are scoped 
correctly to each channel rendering thread.


-Eric

Cris J Holdorph wrote:
maybe.  I can't recall the exact mix I had on the page at the time.  
But definitely a possibility.


 Cris J H

Eric Dalquist wrote:
Are all of the portlets and channels using JSPs to render? If so 
there may be an issue that we experienced here at UW but I couldn't 
reproduce in the core codebase at that time.


-Eric

Andrew Petro wrote:


The other issue, I can't pin down yet, is occassionally I'm seeing 
some channels/portlets display other channels and portlets 
content.  So if I have 4 portlets on a page, call them "A" "B" "C" 
and "D".  If I interact quickly enough with them, it's not uncommon 
that I might start seeing the "C" content in the "B" position.  So 
my page looks "A" "C" "C" "D".  Now if I 'maximize' a portlet and 
go back or go to another tab and go back, the problem seems to 
'clear' itself up.  This problem does not, unfortunately, happen 
consistently enough to make debugging easy.


Has this issue become concrete enough to have a particular Jira 
issue?  I'd like to better get a handle on this, or better 
understand that it is resolved, continuing to move towards uPortal 
2.6.0 GA...







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] weird channel/portlet content substitution issue

[Eric Dalquist]

Are all of the portlets and channels using JSPs to render? If so there 
may be an issue that we experienced here at UW but I couldn't reproduce 
in the core codebase at that time.


-Eric

Andrew Petro wrote:


The other issue, I can't pin down yet, is occassionally I'm seeing 
some channels/portlets display other channels and portlets content.  
So if I have 4 portlets on a page, call them "A" "B" "C" and "D".  If 
I interact quickly enough with them, it's not uncommon that I might 
start seeing the "C" content in the "B" position.  So my page looks 
"A" "C" "C" "D".  Now if I 'maximize' a portlet and go back or go to 
another tab and go back, the problem seems to 'clear' itself up.  
This problem does not, unfortunately, happen consistently enough to 
make debugging easy.


Has this issue become concrete enough to have a particular Jira 
issue?  I'd like to better get a handle on this, or better understand 
that it is resolved, continuing to move towards uPortal 2.6.0 GA...





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] GAP Question: what entity type are PAGS groups?

[Eric Dalquist]

I'm almost certain they are IPerson groups, you may want to bump up 
logging for the PAGs packages and see what is going on during the search.

-Eric

PS: Shouldn't this be on the -user list ;)

Drew Wills wrote:
> Let's say I want to use the following Java call:
>
> --> GroupService.searchForGroups(grpName, IGroupConstants.IS, leafType)
>
> where leafType is an instance of Class (i.e. IPerson.class, 
> ChannelDefinition.class).
>
> What Class do I pass if I'm searching for a PAGS group?
>
> Intuitively I'd say IPerson.class... but I'm not getting the results I 
> expect at the moment.
>
> drew wills
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] validationQuery

[Eric Dalquist]

As good as a default validation query should be perhaps just a comment 
in the XML file with a few examples? Having to deal with figuring out 
what sort of query you need for your specific DB just to develop seems 
like a bit of a pain.

-Eric

Susan Bramhall wrote:
> Oh thank you!  I was wondering what broke my dev set up.  Since we 
> know the database contains certain tables we could make it independent 
> with something like "select 1 from up_versions" which is pretty 
> innocuous.
> Susan
>
> Parker Grimes wrote:
>> Just a quick post regarding the recent fixed issue UP-1771. The 
>> validationQuery="SELECT 1" is invalid SQL in Oracle. You will end up 
>> with "java.sql.SQLException: ORA-00923: FROM keyword not found where 
>> expected"
>>
>> I fixed it in my uPortal55.xml file by changing that to "SELECT 1 
>> FROM DUAL", but that is Oracle specific. I wonder if it would be 
>> better to define that select string in the rdbm.properties file so 
>> that uPortal55.xml picks it up from there and thus could be changed 
>> per database vendor (since all other connection details are pulled 
>> from there anyway).
>>
>> Just my thoughts,
>>
>> Parker
>> Programmer / Analyst
>> Southern Utah University
>> -- 
>> 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
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] validationQuery

[Eric Dalquist]

I think the main point this thread is making is there is no one good 
validation query. Each database may have one but I highly doubt there is 
something generic enough we could include by default. I think rolling 
back the validation query change would be a good thing.

-Eric

George Lindholm wrote:
> Cris J Holdorph wrote:
>   
>> safe, but not nearly as performant as the 'select 1' varities.
>> 
>
> No, but is a safe default value. And if we provide some alternate
> queries like Eric suggested
> each site can customize the query as appropriate.
>
>George
>   
>>  Cris J H
>>
>> George Lindholm wrote:
>> 
>>> Cris J Holdorph wrote:
>>>   
>>>> I think the change in UP-1771 should be rolled back, until a better
>>>> more cross-database solution is developed.  At least the major dbs
>>>> that most uPortal deployers are using (postgres, mysql, sql server,
>>>> oracle and HSQLDB for development).
>>>> 
>>> The ultimate safe query would be "SELECT user_id FROM up_user WHERE
>>> user_id = 1"
>>>
>>>   George
>>>   
>>>>  Cris J H
>>>>
>>>> Eric Dalquist wrote:
>>>> 
>>>>> As good as a default validation query should be perhaps just a
>>>>> comment in the XML file with a few examples? Having to deal with
>>>>> figuring out what sort of query you need for your specific DB just to
>>>>> develop seems like a bit of a pain.
>>>>>
>>>>> -Eric
>>>>>
>>>>> Susan Bramhall wrote:
>>>>>   
>>>>>> Oh thank you!  I was wondering what broke my dev set up.  Since we
>>>>>> know the database contains certain tables we could make it
>>>>>> independent with something like "select 1 from up_versions" which is
>>>>>> pretty innocuous.
>>>>>> Susan
>>>>>>
>>>>>> Parker Grimes wrote:
>>>>>> 
>>>>>>> Just a quick post regarding the recent fixed issue UP-1771. The
>>>>>>> validationQuery="SELECT 1" is invalid SQL in Oracle. You will end
>>>>>>> up with "java.sql.SQLException: ORA-00923: FROM keyword not found
>>>>>>> where expected"
>>>>>>>
>>>>>>> I fixed it in my uPortal55.xml file by changing that to "SELECT 1
>>>>>>> FROM DUAL", but that is Oracle specific. I wonder if it would be
>>>>>>> better to define that select string in the rdbm.properties file so
>>>>>>> that uPortal55.xml picks it up from there and thus could be changed
>>>>>>> per database vendor (since all other connection details are pulled
>>>>>>> from there anyway).
>>>>>>>
>>>>>>> Just my thoughts,
>>>>>>>
>>>>>>> Parker
>>>>>>> Programmer / Analyst
>>>>>>> Southern Utah University
>>>>>>> -- 
>>>>>>> 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
>>>>>>>   
>>>   
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Custom group store question

[Eric Dalquist]

I'm writing a JDBC based group store to go against a set of tables with 
group information maintained by another group. I have everything working 
but can't figure out some of the caching issues. Data will be added and 
removed from the tables by an external process. The service is 
configured as externally managed and has caching disabled. Even so I get 
failures (null pointers) in groups manager if groups or members are 
removed from the DB and groups/members that are added don't show up 
until the portal is restarted.

Any help configuring this would be much appreciated.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal Project Steering Committee

[Eric Dalquist]

I think the informal +/- voting works for this as well unless there are 
any issues that anyone on this list may have with the process. Barring 
that the time line that Andrew laid out looks good.

I would only ask that Bill Thompson or Jonathan keep track of the vote 
progress and email the list with the results after the Sept. 4th deadline.

-Eric

Andrew Petro wrote:
> Jonathan, thank you for bringing this nomination and selection task to 
> the attention of the uPortal developers.
>
> > I would appreciate one of you picking up the ball and taking the 
> next step.
>
> uPortal committers:
> I see this going one of two directions, either fine.  One is that, 
> Apache-style, we arrive at happy consensus as to whom the two 
> uPortal-developer-selected steering committee members will be.  I see 
> that Cris Holdorph and Drew Wills have already spoken up along these 
> lines.  Additional momentum could result in a feeling of consensus.  
> Enough +1s and no objections to Cris's proposal, and we've had our 
> vote.  It's not totally implausible that this approach could work for 
> a small community such as ours.  And I think Eric Dalquist would make 
> a particularly excellent steering committee representative.
>
>
>
> Another direction we may need to go here is a more formal process of 
> nominations and voting.  In order to go that route we'd need to 
> bootstrap some rules.
>
>
> Here's what I propose as a framework for voting:
>
> 1) uPortal committers may post nominations to this uportal-dev@ list, 
> with the same deadline for nominations as that for the stakeholder 
> nominations.  That is, nominations must be posted to the list by 5:00 
> PM EDT (GMT-4) on Wednesday, August 15, 2007.
> 2) We then vote, on the uportal-dev@ list, with each committer invited 
> to cast one vote for each open position (that is, in the present case, 
> two votes).  Voting closes on Tuesday, September 4, 2007 (to comport 
> with "results announced soon after Wednesday, September 5, 2007").
> 3) The top two vote recipients as of the election deadline are 
> recognized as the uPortal developer representatives to the steering 
> committee.
> 4) The uportal committers look to the JA-SIG Elections Committee to 
> moderate this process, decide any election issues that may arise.
>
> I would look to the steering committee itself once instituted to 
> establish some procedures around future elections, handling future 
> committee vacancies, etc.
>
>
> So, two questions:
> 1) Is there interest in pursuing Cris's nomination of myself and Eric 
> Dalquist to be the uPortal developer representatives to the uPortal 
> project steering committee, such that a more formal vote is not 
> necessary? +1s and/or objections to that approach would be helpful.  
> If anyone has the objection "I'd prefer we have a more formal vote 
> than look for less formal consensus", I think that's worth hearing and 
> would be a good reason to go the more formal vote route.
>
> 2) If a more formal vote is necessary, are the above rules supported 
> by the participants?  Are they sufficient? Discussion towards 
> consensus on the rules here may be helpful.
>
> Andrew
>
> Jonathan Markow wrote:
>> Yesterday the JA-SIG Election Committee distributed a Call for 
>> Nominations announcing the start of an election cycle for two board 
>> director positions and three uPortal Project Steering Committee 
>> stakeholder positions.  Information about the steering committee, the 
>> elections, and other governance-related items can be found at 
>> http://www.ja-sig.org/wiki/display/JSG/JA-SIG+Governance.
>>
>> The steering committee model calls for two developers, to be selected 
>> by the group of current committers, to serve on the committee.  This 
>> selection isn't governed by a board-defined election process.  It's 
>> left up to you to determine how to best choose the two developer 
>> representatives.
>>
>> The formal election process for directors and stakeholders will take 
>> approximately six weeks, starting with yesterday's announcement.  I'd 
>> like to encourage you folks to begin your own process now so that the 
>> developer representatives can be announced concurrently with the 
>> stakeholders and board rep.  At that point we should be ready to go 
>> with a first steering committee meeting (which likely will be via 
>> telephone).  I will also participate in an ex officio capacity as 
>> Acting JA-SIG Executive Director.
>>
>> The wiki documentation about the uPortal Project Steering Committee 
>> is fairly skeletal and that's intentio

Re: [uportal-dev] Custom group store question

[Eric Dalquist]

Thanks for the insight Dan, I was starting to wonder if that is what was 
happing. The sample looks like it should solve my problem.

-Eric

Dan Ellentuck wrote:
> Hi Eric,
>
> The default IEntityGroup implementation, 
> o.j.p.groups.EntityGroupImpl, caches its member keys.  As a 
> result, once an EntityGroupImpl leaks out of an 
> externally-managed service, it is vulnerable to becoming out 
> of sync with its store.  I think the easiest approach is to 
> extend EntityGroupImpl to delegate member queries 
> (contains(), getMemberEntities() and getMemberGroups()) to 
> the local group service and have your group store 
> instantiate instances of this class.  I'm attaching an 
> example of this approach.
>
> Dan
>
> Eric Dalquist wrote:
>   
>> I'm writing a JDBC based group store to go against a set of tables with 
>> group information maintained by another group. I have everything working 
>> but can't figure out some of the caching issues. Data will be added and 
>> removed from the tables by an external process. The service is 
>> configured as externally managed and has caching disabled. Even so I get 
>> failures (null pointers) in groups manager if groups or members are 
>> removed from the DB and groups/members that are added don't show up 
>> until the portal is restarted.
>>
>> Any help configuring this would be much appreciated.
>>
>> -Eric
>> 
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal Project Steering Committee

[Eric Dalquist]

Yes, I accept the nomination.

-Eric

Jason Shao wrote:
> On Jul 30, 2007, at 12:32 PM, Eric Dalquist wrote:
>
>> I think the informal +/- voting works for this as well unless there are 
>> any issues that anyone on this list may have with the process. Barring 
>> that the time line that Andrew laid out looks good.
>>
>> I would only ask that Bill Thompson or Jonathan keep track of the vote 
>> progress and email the list with the results after the Sept. 4th 
>> deadline.
>>
>> -Eric
>
> Err... just to be clear, Eric I take it you accept the nomination? 
> Assuming that's the case, let me also chime in with my +1 for both 
> yourself and Andrew as the initial dev-reps to the project steering 
> committee.
>
> Jason
>
> --
>
> Jason Shao
> Application Developer
> Rutgers University, Office of Instructional & Research Technology
> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]> | http://jay.shao.org
>
>
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] validationQuery

[Eric Dalquist]

I just made this change in head, there is a comment in uPortal55.xml 
about connection validation and removed the actual validation queries. 
If moving to a universally valid query against a uPortal table is 
desired we can make that change. My vote would be a query against 
UP_VERSIONS since it should only have a row or two in it ensuring it 
returns very quickly.

Oh the Jira issue for my change is UP-1781

-Eric

Susan Bramhall wrote:
> If there isn't an acceptable universal validation query then I like 
> the idea of just leaving it in the comments of the current config 
> file.  There are plenty of universally valid queries for the uP 
> database if we know the schema has been created but they wouldn't work 
> for the personDB anyway since that schema is opaque.
> -Susan
>
> Andrew Petro wrote:
>> Yes, that validation query in the default context descriptor template 
>> not working in all dbs was my bad.  Brooklyn College was good enough 
>> to have me work on their portal last week and we discovered that 
>> introducing validating connections on checkout is very helpful and I 
>> was over-eager to share that default configuration with the uPortal 
>> world.
>>
>> Validating connections on checkout from the pool is in general a good 
>> thing.
>>
>> What if we were to introduce a new property in rdbm.properties 
>> supplying the validation query, to be token-replaced into the context 
>> descriptor like the other tokens are currently replaced, with 
>> examples of valid queries for each of the example RDBMS 
>> configurations in rdbm.properties?
>>
>> If a validation query isn't included in the default context 
>> descriptor, then inertia will lead to many uPortal deployments simply 
>> not using validation on connection checkout, and that seems like a 
>> missed opportunity.  Rather than rolling back the change, I'd prefer 
>> to roll forward with the further tweaks necessary to make it 
>> successful.  The problem here is not in concept -- it is in poor 
>> execution (my bad).
>>
>> Andrew
>>
>>
>>> ...I think rolling back the validation query change would be a good 
>>> thing.
>>>
>>> -Eric
>>>
>>> George Lindholm wrote:
>>>  
>>>> Cris J Holdorph wrote:
>>>> 
>>>>> safe, but not nearly as performant as the 'select 1' varities.
>>>>>   
>>>> No, but is a safe default value. And if we provide some alternate
>>>> queries like Eric suggested
>>>> each site can customize the query as appropriate.
>>>>
>>>>George
>>>> 
>>>>>  Cris J H
>>>>>
>>>>> George Lindholm wrote:
>>>>> 
>>>>>> Cris J Holdorph wrote:
>>>>>> 
>>>>>>> I think the change in UP-1771 should be rolled back, until a better
>>>>>>> more cross-database solution is developed.  At least the major dbs
>>>>>>> that most uPortal deployers are using (postgres, mysql, sql server,
>>>>>>> oracle and HSQLDB for development).
>>>>>>>   
>>>>>> The ultimate safe query would be "SELECT user_id FROM up_user WHERE
>>>>>> user_id = 1"
>>>>>>
>>>>>>   George
>>>>>> 
>>>>>>>  Cris J H
>>>>>>>
>>>>>>> Eric Dalquist wrote:
>>>>>>> 
>>>>>>>> As good as a default validation query should be perhaps just a
>>>>>>>> comment in the XML file with a few examples? Having to deal with
>>>>>>>> figuring out what sort of query you need for your specific DB 
>>>>>>>> just to
>>>>>>>> develop seems like a bit of a pain.
>>>>>>>>
>>>>>>>> -Eric
>>>>>>>>
>>>>>>>> Susan Bramhall wrote:
>>>>>>>> 
>>>>>>>>> Oh thank you!  I was wondering what broke my dev set up.  
>>>>>>>>> Since we
>>>>>>>>> know the database contains certain tables we could make it
>>>>>>>>> independent with something like "select 1 from up_versions" 
>>>>>>>>> which is
>>>>>>>>> pretty innocuous.
>>>>>&

Re: [uportal-dev] build.xml change suggestion

[Eric Dalquist]

Sounds great, thanks for the effort on the enhancement Andy.

-Eric

Andy Gherna wrote:
> OK, I started a ticket in JIRA (UP-1742) and I'll start working on getting a 
> patch for build.properties and build.xml soon.  Thanks.
>   


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] [VOTE] Commit access for Andy Gherna

[Eric Dalquist]

Andy has submitted several good patches for uPortal recently and is 
interested in commit access.

+1 from me.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Commit access for Lennard Fuller

[Eric Dalquist]

+1

Lennard Fuller wrote:
> I would like to request commit access to the uPortal project.  I am 
> currently an architect who has been working on the Pearson project 
> (large scale uPortal deployment) for roughly the last two years.  
> Until fairly recently any bug fixes or enhancements that the Pearson 
> team had to contribute back to the uPortal community were funneled 
> through Andreas Christoforides or Cris Holdorph.  Both have since 
> moved on to other projects and my attempt to snag a slice of Andrew 
> Petro's time has met with failure hence the request:)
>
> For those of you that don't know me
> Am a Unicon employee (6+ years), have 8+ years of java development 
> experience, a degree in Computer Science from ASU and have lead 
> development efforts for the past 5 years for Cisco and Pearson 
> Education.  Over the last 2 years I've been lucky enough to attend a 
> number of ja-sig conferences and have presented on a number of topics.
>
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [VOTE] Commit access for Timothy Carroll

[Eric Dalquist]

+1

Andrew Petro wrote:
> (Forking thread for clarity)
>
> We have a bid for commitership here for Timothy Carroll, with a +1 
> from newest commiter Andy Gherna.
>
> Timothy, could you post sharing a few more words about your background 
> with uPortal, interests in contributing?
>
> Andrew
>
> Andy Gherna wrote:
>> I would second this.  Tim's work was instrumental to fixing UP-1040.
>>
>>  Original message 
>>   
>>> Date: Fri, 03 Aug 2007 19:53:42 -0500
>>> From: Timothy Carroll <[EMAIL PROTECTED]>  
>>> Subject: Re: [uportal-dev] [VOTE] Commit access for Andy Gherna  
>>> To: uportal-dev@lists.ja-sig.org
>>>
>>> i would like to piggy-back on this request, as andy and i work closely 
>>> together on this project... and, i have recently introduced some fixes 
>>> as well.
>>>
>>> Eric Dalquist wrote:
>>> 
>>>> Andy has submitted several good patches for uPortal recently and is 
>>>> interested in commit access.
>>>>
>>>> +1 from me.
>>>>
>>>> -Eric
>>>>   
>>>>   
>>> -- 
>>> 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
>>> 
>> --
>> Andy Gherna   |
>> Senior Research Programmer| Phone:  (217) 265-9490
>> CITES, University of Illinois | Email:  [EMAIL PROTECTED]
>>
>>   
>
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Welcome to new committer Andy Gherna, maintaining wiki page listing committers

[Eric Dalquist]

Thanks Andy.


Now that CVS is in read-only mode and has been for a while can we prune 
that wiki page down to just those folks with SVN commit access?

-Eric

Andy Gherna wrote:
>
> Done.
>
>  
>
> 
>
> *From:* Andrew Petro [mailto:[EMAIL PROTECTED]
> *Sent:* Saturday, August 04, 2007 8:56 PM
> *To:* uportal-dev@lists.ja-sig.org
> *Subject:* [uportal-dev] Welcome to new committer Andy Gherna, 
> maintaining wiki page listing committers
>
>  
>
> Andy,
>
> Welcome.
>
> I see someone (presumably Eric) has already set you up with SVN 
> credentials. Please also update this wiki page listing commiters 
> <http://www.ja-sig.org/wiki/display/UPC/Committers>, highlighting the 
> areas of uPortal you're most interested in contributing to.
>
> Thanks,
>
> Andrew
>
>
> +1
>
>  Cris J H
>
> Eric Dalquist wrote:
>
> Andy has submitted several good patches for uPortal recently and is 
> interested in commit access.
>
> +1 from me.
>
> -Eric
>
>  
>
>  
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.4.2-derived ALM maintenance branch

[Eric Dalquist]

Would this branch be temporary and eventually the code is merged into 
the 'real' 2.4 and 2.5 branches or would this stick around for a while? 
What are the downsides of just patching up the existing 2.4 branch?

-Eriuc

Andrew Petro wrote:
> uPortal developers,
>
> A client [1] has been generous enough to throw me a few [2] hours to 
> work on ALM diagnostics, error detection, and bugfixing, with an 
> especial need to apply these changes to 2.4.2.  I'd like to create a 
> "2-4-2-alm-maint" exploratory branch for the purpose of sharing this 
> maintenance code.  I hope this will be of interest and use to fewer 
> and fewer uPortals as folks migrate to DLM, but since this is 
> maintenance of uPortal itself it seems to me to belong in uPortal 
> source control.
>
> Andrew
>
>
>
> [1]: I dislike that cloak and dagger "some client, somewhere" allusion 
> probably even more than you do, and I'll see about giving credit where 
> credit is due on any fruits of this labor.  More openness is better.  
> Unfortunately, it's not always clear how much it is acceptable to 
> share when.
>
> [2]: Don't expect the realization of all ALM hopes and dreams ever had 
> out of this effort -- it's a very few hours involved.  However, with a 
> maintenance branch to explore mitigating issues in ALM in older 
> uPortal environments, there's a place for continued collaboration on 
> this if desired.
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Pruning the list of uPortal committers

[Eric Dalquist]

Good point.

I'll go through later today and do some 'informed pruning' and group 
people as active/inactive and unsure.

-Eric

Andrew Petro wrote:
> Eric,
>
> Are folks who haven't yet migrated their credentials to SVN no longer 
> committers, or are they latent committers who have not yet addressed 
> an annoying bit of administrivia?
>
> Given the fun this weekend of getting Susan's SVN access figured out 
> again, and that she definitely qualifies as a "core commiter" and an 
> active contributor to present efforts, I think we should take care not 
> to be too hasty to prune out folks who haven't made the jump.
>
> Andrew
>
>> Thanks Andy.
>>
>>
>> Now that CVS is in read-only mode and has been for a while can we 
>> prune that wiki page down to just those folks with SVN commit access?
>>
>> -Eric
>>
>> Andy Gherna wrote:
>>  
>>> Done.
>>>
>>>  
>>> 
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.4.2-derived ALM maintenance branch

[Eric Dalquist]

Sounds good. I think creating the branch is ok thought if it doesn't 
prove to be viable to merged back into the core code or no one is 
actively maintaining it after 4 months I'd like to have the option to 
remove it to ensure we keep things clearly delineated as to what is the 
'correct' 2.4 patches branch.

-Eric

Andrew Petro wrote:
> Eric,
>
> The branch would be ad-hoc -- for the specific purpose of exploring 
> ALM maintenance against uPortal 2.4.2, and not for other general fixes.
>
> I expect it would be temporary in that over time people will care 
> about ALM maintenance less and less, having moved on to DLM and bigger 
> and better things.
>
> I'm not volunteering to merge this code into the real ongoing 
> 2-4-patches branch.  I'd be open to doing that work if it proves 
> desirable.  Presently I'm looking to do the "simplest thing that could 
> possibly work" to do uPortal 2.4.2 ALM triage in an open way.
>
> Downsides of patching up the existing 2-4-patches branch include: 
> having to patch up this deployment to latest 2-4-patches or having to 
> deal with unrelated differences since 2.4.2.  Presumably valuable but 
> not the present project.  The ALM-specific exploratory branch is not 
> guaranteed to be backwards compatible and countenances more daring 
> changes.  Its purpose is different from that of 2-4-patches.
>
> Andrew
>
>> Would this branch be temporary and eventually the code is merged into 
>> the 'real' 2.4 and 2.5 branches or would this stick around for a 
>> while? What are the downsides of just patching up the existing 2.4 
>> branch?
>>
>> -Eriuc
>>
>> Andrew Petro wrote:
>>  
>>> uPortal developers,
>>>
>>> A client [1] has been generous enough to throw me a few [2] hours to 
>>> work on ALM diagnostics, error detection, and bugfixing, with an 
>>> especial need to apply these changes to 2.4.2.  I'd like to create a 
>>> "2-4-2-alm-maint" exploratory branch for the purpose of sharing this 
>>> maintenance code.  I hope this will be of interest and use to fewer 
>>> and fewer uPortals as folks migrate to DLM, but since this is 
>>> maintenance of uPortal itself it seems to me to belong in uPortal 
>>> source control.
>>>
>>> Andrew
>>>
>>>
>>>
>>> [1]: I dislike that cloak and dagger "some client, somewhere" 
>>> allusion probably even more than you do, and I'll see about giving 
>>> credit where credit is due on any fruits of this labor.  More 
>>> openness is better.  Unfortunately, it's not always clear how much 
>>> it is acceptable to share when.
>>>
>>> [2]: Don't expect the realization of all ALM hopes and dreams ever 
>>> had out of this effort -- it's a very few hours involved.  However, 
>>> with a maintenance branch to explore mitigating issues in ALM in 
>>> older uPortal environments, there's a place for continued 
>>> collaboration on this if desired.
>>>
>>> 
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Purging a Channel from all layouts

[Eric Dalquist]

Part of the post 2.6 plan I think will include this change. Switching to 
a more sane DAO for the layout store perhaps even using hibernate to 
leverage the great CLOB (and in some cases XML object) support databases 
have now would likely improve performance as well as clarity.

-Eric


Mark Boyd wrote:
> Having a chunk of XML would be nice and would certainly remove a chunk 
> of confusing code from the layout stores. And with all of the 
> standards that have matured since the beginings of uPortal there 
> really is a lot that we could leverage in such an initiative.
>
> Mark
>
> On 8/6/07, *Susan Bramhall* <[EMAIL PROTECTED] 
> > wrote:
>
> Another approach would be to change the layout manager (or ??) to
> remove
> the channel from the layout as it builds it instead of
> substituting the
> "channel not found error".  We talked about doing this but decided
> against it.
> Susan
>
> Andrew Petro wrote:
> > Philip,
> >
> > It might be best to write some Java code to actuate the layout
> > management API to load each user's layout, change it as you desire,
> > and save it again.  This would make a very nice addition to the
> > channel manager -- perhaps a button to "Remove this channel from all
> > user layouts".
> >
> > Andrew
> >
> > PS: I'm becoming increasingly convinced that the approach in the
> > sandbox uPortal code of storing layout fragments as really wide
> > database columns containing the layout XML instead of representing
> > each node  as a database row is a very good idea -- it's
> probably just
> > as performant if not more performant for real uses, and it's a whole
> > lot simpler to understand and code against.  I suspect that if
> layout
> > storage were implemented this way, you'd be done with this
> > remove-a-channel-from-everyone's-layout task already.
> >
> >> I'm looking for a way to purge a channel from both the channel
> >> registry and all layouts it is contained in.
> >>
> >> Deleting a channel in ChannelManager gives 'Channel not found'
> errors
> >> in any layouts that already had the channel.  Deleting the record
> >> directly from the LAYOUT_STRUCT table seems to completely ruin
> that
> >> users layout.  (I've done deluser on myself a few times now.)
> >>
> >> Are there multiple tables that would need to be changed in order to
> >> not destroy the layout?
> >>
> >> Thanks
> >> Phil
> >>
> >>
> >> ps. Sorry, if there is some simple solution to this, and I'm
> >> completely over thinking the problem!
> >>
> >>
> >
> >
>
> --
> It's no use trying to be clever--we are all clever here; just try
> to be kind--a little kind.
> -- F.J. Foakes Jackson
>
>
> --
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Commit access for Lennard Fuller

[Eric Dalquist]

With >3 +1s and no objections it looks good to add Lennard as a committer.

Lennard, you can contact me off-list or Andrew in person to get set up.

-Eric

Lennard Fuller wrote:
> I would like to request commit access to the uPortal project.  I am 
> currently an architect who has been working on the Pearson project 
> (large scale uPortal deployment) for roughly the last two years.  
> Until fairly recently any bug fixes or enhancements that the Pearson 
> team had to contribute back to the uPortal community were funneled 
> through Andreas Christoforides or Cris Holdorph.  Both have since 
> moved on to other projects and my attempt to snag a slice of Andrew 
> Petro's time has met with failure hence the request:)
>
> For those of you that don't know me
> Am a Unicon employee (6+ years), have 8+ years of java development 
> experience, a degree in Computer Science from ASU and have lead 
> development efforts for the past 5 years for Cisco and Pearson 
> Education.  Over the last 2 years I've been lucky enough to attend a 
> number of ja-sig conferences and have presented on a number of topics.
>
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] VOTE to release 2.6.0 GA

[Eric Dalquist]

Just checked it out and ran it, looks good.

+1 for release

-Eric

Andrew Petro wrote:
> uPortal developers,
>
> I write to call the question of releasing uPortal 2.6.0 general 
> audience , the further 
> incremental improvement on the available RC2 
> , as staged in SVN as
>
> https://www.ja-sig.org/svn/up2/tags/rel-2-6-0-GA/
>
> Releasing 2.6.0 GA creates a maintenance branch for 
> backwards-compatible patches towards 2.6.1, 2.6.2, etc. and frees the 
> HEAD for evolutionary work.
>
> With Eric's recent burst of activity to tie off niggling remaining 
> issues, I think we've gotten what we're going to get out of an RC 
> series on this and need to put this binary out there and start work 
> towards a 2.6.1 etc.
>
> +1 to release 2.6.0 GA.
>
> Andrew
>
>
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Post 2.6 development & planning

[Eric Dalquist]

With the 2.6 release imminent it is time to start planning how the 
changes outlined here 
http://www.ja-sig.org/wiki/display/UP3/uPortal3+Community+Goals+and+Objectives 
will be carried out.

I'll be detailing this plan in Jira this week but wanted to get some 
feedback here as well.

The list in the wiki has been re-ordered a bit after looking at code and 
talking with other developers. The plan right now is to approach tasks 
in the following order:

1. Convert to Maven for build management
2. Unify the Spring configuration and usage
3. Code cleanup, this goes along closely with 2. Includes removal of 
deprecated code, using the externalized GAP and PersonDirectory jars and 
similar changes.
4. Upgrade to Pluto 1.1

I'd like to get feedback on this roadmap (either on the list or in the 
wiki). I'm also looking for ideas on naming versions in Jira. We have 
already had M1 through M4 and an RC from the sandbox code. Should we 
start with a 3.0.0-M5 and then go to a RC2 once we're at the RC stage?

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] differentiating milestones from release candidates by naming

[Eric Dalquist]

I completely agree, the question of what we call the next 3 related release?

As much as starting over with M1 would be nice we already have released 
artifacts with M1-M4 and RC1 names. I'd bet that would cause a fair 
amount of confusion. So is starting at M5 and only doing milestone 
releases until we have a real RC the way to go? I'm thinking yes but I'd 
like some confirmation.

-Eric

Andrew Petro wrote:
> Eric,
>
> I strongly feel that we should take care in the naming of releases to 
> reflect what they are.  The amount of new functionality snuck in 
> post-RC on 2.6.0 was probably too much and probably slowed things up, 
> someone should slap my wrist.
>
> While the uPortal sandbox project produced a release named a "release 
> candidate" I think on sober second thought that was a mistake -- that 
> it wasn't actually a candidate for release since it was acknowledged 
> at the time to lack significant amounts of needed functionality.
>
> Going forward IMHO we should absolutely switch back to producing 
> milestones until there's something that's a candidate for release.  RC 
> needs to mean something that is functionally complete and releasable 
> but for a need for QA.
>
> Andrew
>
>
>> I'm also looking for ideas on naming versions in Jira. We have 
>> already had M1 through M4 and an RC from the sandbox code. Should we 
>> start with a 3.0.0-M5 and then go to a RC2 once we're at the RC stage?
>>
>> -Eric
>>   
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] names of near-term releases of HEAD

[Eric Dalquist]

Sounds like a good plan. I've already updated the uP3 Jira project 
renaming it to uPortal3 Sandbox and making it read-only. I'll start on 
SVN next, creating a sandbox folder and moving up3 under it.

 From the CVS sandbox what needs to be moved? The following modules 
exist: Merlin, al, gap, uP2_7_i18n, up3, userexperience, xalan

Is uP2_7_i18n the DLM2/i18n code from SCT that we should move over? Do 
any of the other modules need to be moved?

-Eric

Andrew Petro wrote:
> Starting with M5 sounds good to me.
>
> While I agree that uPortal cannot "take back" the existing M and RC 
> "uPortal 3" releases, I do think the verbiage on the downloads page 
> about those releases can be improved for better clarity about what 
> they are and how they relate to what will eventually be released as uP 
> 3 GA.
>
> I think some SVN adjustments are also in order -- the code currently 
> in /up3/ needs to be moved to a less confusing namespace, probably in 
> /sandbox/, which nicely relates to the work of moving over the CVS 
> sandbox to un-orphan Mark's improved DLM code.
>
> Andrew
>
>
>> I completely agree, the question of what we call the next 3 related 
>> release?
>>
>> As much as starting over with M1 would be nice we already have 
>> released artifacts with M1-M4 and RC1 names. I'd bet that would cause 
>> a fair amount of confusion. So is starting at M5 and only doing 
>> milestone releases until we have a real RC the way to go? I'm 
>> thinking yes but I'd like some confirmation.
>>
>> -Eric
>>
>> Andrew Petro wrote:
>>  
>>> Eric,
>>>
>>> I strongly feel that we should take care in the naming of releases 
>>> to reflect what they are.  The amount of new functionality snuck in 
>>> post-RC on 2.6.0 was probably too much and probably slowed things 
>>> up, someone should slap my wrist.
>>>
>>> While the uPortal sandbox project produced a release named a 
>>> "release candidate" I think on sober second thought that was a 
>>> mistake -- that it wasn't actually a candidate for release since it 
>>> was acknowledged at the time to lack significant amounts of needed 
>>> functionality.
>>>
>>> Going forward IMHO we should absolutely switch back to producing 
>>> milestones until there's something that's a candidate for release.  
>>> RC needs to mean something that is functionally complete and 
>>> releasable but for a need for QA.
>>>
>>> Andrew
>>>
>>>
>>>
 I'm also looking for ideas on naming versions in Jira. We have 
 already had M1 through M4 and an RC from the sandbox code. Should 
 we start with a 3.0.0-M5 and then go to a RC2 once we're at the RC 
 stage?

 -Eric
 
>>> 
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Xalan 2.70 and Netbeans

[Eric Dalquist]

I'll check when I get home and on my mac but I'm pretty sure I have JDK 
1.4 and 1.5 installed. I'll let you know what I find.

-Eric

Timothy Carroll wrote:
> i agree to moving forward.  however, i think a documented work-around 
> to this issue should accompany the ga release.
>
> as for "What happened to the work-around of using two JDKs, one to run 
> the IDE and another to build/run uPortal?", i have yet to get this to 
> work in the mac environment.  the mac likes to manage the available 
> jre implementations, so having two instances of the same version 
> co-habitating is somewhat tricky.
>
> erik (or anyone else), do you have any suggestions on how to install 
> and manage two instances of the same jre on a mac?
>
> thanks, tim
>
>
>
> Cris J Holdorph wrote:
>> uPortal 2.5.x also had to create a uPortal specific patch of xalan 
>> 2.6, in order to fix a critical memory leak (if I remember 
>> correctly).  While that got us by, it was never the desired approach 
>> to have a patched version of the xalan libraries.
>>
>> I believe even with the problems with netbeans, xalan 2.7 is a better 
>> library for uPortal 2.6.0 to use.
>>
>>  Cris J H
>>
>> Andrew Petro wrote:
>>> Timothy,
>>>
>>> I hear your pain, and hope that by welcoming a couple Netbeans users 
>>> closer into the cadre of uPortal developers understanding and 
>>> support for using the IDE will improve.
>>>
>>> However, I think there are important ways in which the Xalan 2.7.0 
>>> requirement is a feature rather than an impediment - uPortal is very 
>>> XML/XSLT heavy.  Adopting the latest and greatest mainstream XML 
>>> libraries we can is a sound move.
>>>
>>> I'd suggest that this issue not impede 2.6.0 GA and become instead a 
>>> follow-on issue, likely one addressed by better doco on how to 
>>> develop uPortal using various IDEs.
>>>
>>> What happened to the work-around of using two JDKs, one to run the 
>>> IDE and another to build/run uPortal?
>>>
>>> Andrew
>>>
 the only major impediment that i see is the xalan 2.7.0 requirement.

 it is a problem for those of us using netbeans for development

 there may be a work-around, but i have yet to find one that is 
 desirable...



 Andrew Petro wrote:
> uPortal developers,
>
> I write to call the question of releasing uPortal 2.6.0 general 
> audience , the 
> further incremental improvement on the available RC2 
> , as staged in 
> SVN as
>
> https://www.ja-sig.org/svn/up2/tags/rel-2-6-0-GA/
>
> Releasing 2.6.0 GA creates a maintenance branch for 
> backwards-compatible patches towards 2.6.1, 2.6.2, etc. and frees 
> the HEAD for evolutionary work.
>
> With Eric's recent burst of activity to tie off niggling remaining 
> issues, I think we've gotten what we're going to get out of an RC 
> series on this and need to put this binary out there and start 
> work towards a 2.6.1 etc.
>
> +1 to release 2.6.0 GA.
>
> Andrew
>
>
>
> -- 
> 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

>>>
>>>
>>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Xalan 2.70 and Netbeans

[Eric Dalquist]

Yes but this really seems more like a NetBeans issue than a uPortal 
issue. You would be running into the same problem with any project that 
needed to use Xalan 2.7 I'm assuming. Is there any chance of getting the 
NetBeans developers to provide a solution?

I'm still at +1 for releasing and just adding some documentation to the 
release notes about known issues with this version of NetBeans on OS X.

-Eric

Andy Gherna wrote:
> At the same time though, not being able to work w/ uPortal on your tool of
> choice is a limiting factor for some folks.
>
>   
>> -Original Message-
>> From: Cris J Holdorph [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, August 07, 2007 11:41 AM
>> To: uportal-dev@lists.ja-sig.org
>> Subject: Re: [uportal-dev] Xalan 2.70 and Netbeans
>>
>> Hmm... I have to disagree with this.  I'd also feel the same way about
>> Eclipse.  We're trying to get 2.6.0 GA out the door.  It's just my
>> opinion, but I don't believe any issues that are specific to an IDE
>> (Eclipse, Netbeans, Intellij, ...) should cause a delay in the release
>> at this point in the release process.
>>
>>  Cris J H
>>
>> Timothy Carroll wrote:
>> 
>>> i agree to moving forward.  however, i think a documented work-around to
>>> this issue should accompany the ga release.
>>>   
>> --
>> 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
>> 
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Xalan 2.70 and Netbeans

[Eric Dalquist]

Tim,

Can you outline the exact issue again and what the possible work arounds 
are?

Thanks,
-Eric

Timothy Carroll wrote:
> due to productivity issues, adopting this release will not be an 
> option for us until a work-around is in place, which is a shame 
> because there are so many improvements over 2.5.x (some of which we 
> contributed).
>
> however, i understand that netbeans does not hold a significant market 
> share among uportal developers, so from a practicality stand-point i 
> can justify moving forward since this is an issue with netbeans.  this 
> would be similar to rolling out a ga release that does not operate 
> with jboss, because it does work with tomcat.
>
> if this issue applied to eclipse, rolling out would be completely 
> unacceptable due to the volume of users of that ide in correlation 
> with the uportal community.  that would be similar to rolling out a ga 
> release that did not operate under tomcat.
>
> i'd like to see us take an approach that ensures support for the top 
> three tools of a category (i.e. ide-s, servlet containers, databases, 
> etc.)
>
>
>
> Cris J Holdorph wrote:
>> Hmm... I have to disagree with this.  I'd also feel the same way 
>> about Eclipse.  We're trying to get 2.6.0 GA out the door.  It's just 
>> my opinion, but I don't believe any issues that are specific to an 
>> IDE (Eclipse, Netbeans, Intellij, ...) should cause a delay in the 
>> release at this point in the release process.
>>
>>  Cris J H
>>
>> Timothy Carroll wrote:
>>> i agree to moving forward.  however, i think a documented 
>>> work-around to this issue should accompany the ga release.
>>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Xalan 2.70 and Netbeans

[Eric Dalquist]

I believe that is only a requirement if using JDK 1.4. The problem was 
the version of DOM needed to be changed so the JAR had to be put in the 
JDK's endorsed directory. I just double checked and I don't have any 
libraries in my JDK's endorsed directory.

Also I do believe that uPortal 2.6 requires JDK 1.5

-Eric

Andy Gherna wrote:
> IIRC, the requirement is to put the xalan-2.7.0.jar in to the endorsed
> directory on the JDK specifically for use by uPortal.  By putting that jar
> into that directory (which affects the entire JDK that's being used), I
> don't think this is necessarily just a Netbeans issue.
>
> Is there a way to install this jar so that there is less of an impact to the
> entire JDK?  For example, the endorsed/lib directory in Tomcat would be a
> good place since its on the classpath for all its own internal workings and
> web applications.  And, this directory could easily be added to the
> classpath for the command line tools in build.xml.  This would
> (theoretically) allow Netbeans to be used without changing the JDK.
>
>   
>> -Original Message-
>> From: Eric Dalquist [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, August 07, 2007 12:03 PM
>> To: uportal-dev@lists.ja-sig.org
>> Subject: Re: [uportal-dev] Xalan 2.70 and Netbeans
>>
>> Yes but this really seems more like a NetBeans issue than a uPortal
>> issue. You would be running into the same problem with any project that
>> needed to use Xalan 2.7 I'm assuming. Is there any chance of getting the
>> NetBeans developers to provide a solution?
>>
>> I'm still at +1 for releasing and just adding some documentation to the
>> release notes about known issues with this version of NetBeans on OS X.
>>
>> -Eric
>>
>> Andy Gherna wrote:
>> 
>>> At the same time though, not being able to work w/ uPortal on your tool
>>>   
>> of
>> 
>>> choice is a limiting factor for some folks.
>>>
>>>
>>>   
>>>> -Original Message-
>>>> From: Cris J Holdorph [mailto:[EMAIL PROTECTED]
>>>> Sent: Tuesday, August 07, 2007 11:41 AM
>>>> To: uportal-dev@lists.ja-sig.org
>>>> Subject: Re: [uportal-dev] Xalan 2.70 and Netbeans
>>>>
>>>> Hmm... I have to disagree with this.  I'd also feel the same way about
>>>> Eclipse.  We're trying to get 2.6.0 GA out the door.  It's just my
>>>> opinion, but I don't believe any issues that are specific to an IDE
>>>> (Eclipse, Netbeans, Intellij, ...) should cause a delay in the release
>>>> at this point in the release process.
>>>>
>>>>  Cris J H
>>>>
>>>> Timothy Carroll wrote:
>>>>
>>>> 
>>>>> i agree to moving forward.  however, i think a documented work-around
>>>>>   
>> to
>> 
>>>>> this issue should accompany the ga release.
>>>>>
>>>>>   
>>>> --
>>>> 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
>>>>
>>>> 
>>>
>>>   
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] DLM restrictions

[Eric Dalquist]

Mind explaining so those of us that are curious (and others finding this 
thread in the archives) know what the solution is?

-Eric

Berry, Patrick wrote:
>
> Never mind, I’m an idiot. Although, the commented out code will 
> confuse the easily confused ;-)
>
> *From:* Berry, Patrick [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, August 07, 2007 10:05 AM
> *To:* uportal-dev@lists.ja-sig.org
> *Subject:* [uportal-dev] DLM restrictions
>
> So, I’m cruisin’ through the XSL for the DLM preferences and a lot of 
> things that would prevents locked things from being edited is 
> commented out.
>
> http://developer.ja-sig.org/source/browse/jasigsvn/up2/trunk/webpages/stylesheets/org/jasig/portal/channels/DLMUserPreferences/tab-column/default.xsl?r=35853
>
> Is this intentional?
>
> Thanks,
>
> Pat
>
> -- 
> 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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Post 2.6 development & planning

[Eric Dalquist]

Yes, I have a copy of 2.6 mostly Mavenized right now. Once we're happy 
with the 2.6 release I'll actually be creating a temporary branch to do 
the work in and then merge it back in to trunk.

We don't have any commit message notification, the RSS feed from Fisheye 
is the best solution (better than a mailing list imo) For Jira there is 
a list for each project: 
http://www.ja-sig.org/wiki/display/JSG/Jira+Notifications

-Eric

Elliot Metsger wrote:
> Seems like a reasonable plan to me.  I understand you've already got 
> some Maven 2 things ready to rock once the GA is released?
>
> Also, is there a email list that commit messages are sent to, or are 
> we relying on Fisheye's feeds?  I didn't see an SVN or SCM commit list 
> on the wiki page of email lists.
>
> Thanks for everyone's effort with 2.6.0!
>
> Elliot
>
> Eric Dalquist wrote:
>> With the 2.6 release imminent it is time to start planning how the 
>> changes outlined here 
>> http://www.ja-sig.org/wiki/display/UP3/uPortal3+Community+Goals+and+Objectives
>>  
>> will be carried out.
>>
>> I'll be detailing this plan in Jira this week but wanted to get some 
>> feedback here as well.
>>
>> The list in the wiki has been re-ordered a bit after looking at code 
>> and talking with other developers. The plan right now is to approach 
>> tasks in the following order:
>>
>> 1. Convert to Maven for build management
>> 2. Unify the Spring configuration and usage
>> 3. Code cleanup, this goes along closely with 2. Includes removal of 
>> deprecated code, using the externalized GAP and PersonDirectory jars 
>> and similar changes.
>> 4. Upgrade to Pluto 1.1
>>
>> I'd like to get feedback on this roadmap (either on the list or in 
>> the wiki). I'm also looking for ideas on naming versions in Jira. We 
>> have already had M1 through M4 and an RC from the sandbox code. 
>> Should we start with a 3.0.0-M5 and then go to a RC2 once we're at 
>> the RC stage?
>>
>> -Eric
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.4.2-derived ALM maintenance branch

[Eric Dalquist]

I think the working- prefix would be very helpful. I'm going to be doing 
something similar soon for maven work on the trunk and will plan on 
using the working- prefix if that sounds like a good option to the rest 
of the committers.

-Eric

Jason Shao wrote:
> On Aug 6, 2007, at 2:11 PM, Eric Dalquist wrote:
>
>> Sounds good. I think creating the branch is ok thought if it doesn't 
>> prove to be viable to merged back into the core code or no one is 
>> actively maintaining it after 4 months I'd like to have the option to 
>> remove it to ensure we keep things clearly delineated as to what is the 
>> 'correct' 2.4 patches branch.
>>
>> -Eric
>
> Sounds like we need a naming convention for working branches -- 
> something like 'exploratory-2-4-2-alm' or 'working-2-4-2-alm' perhaps. 
> Since SVN users tend to make more usage of branches, it seems like a 
> worthwhile convention. Also, leveraging the fact that you can remove 
> old working branches (tags should probably stick around).
>
> An interesting side note is that Sakai is moving towards branches 
> organized around JIRA issue numbers - e.g. a SAK-X branch that can 
> be removed later if it's unviable or merged into trunk.
>
> Jason
>
> --
>
> Jason Shao
> Application Developer
> Rutgers University, Office of Instructional & Research Technology
> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]> | http://jay.shao.org
>
>
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] VOTE to release 2.6.0 GA

[Eric Dalquist]

So currently there have only been two +1 votes. There has been some 
voiced support and descent but no actual votes. Any of the other 
committers out there have a chance to check out and give 2.6 a quick trial?

-Eric

Andrew Petro wrote:
> uPortal developers,
>
> I write to call the question of releasing uPortal 2.6.0 general 
> audience , the further 
> incremental improvement on the available RC2 
> , as staged in SVN as
>
> https://www.ja-sig.org/svn/up2/tags/rel-2-6-0-GA/
>
> Releasing 2.6.0 GA creates a maintenance branch for 
> backwards-compatible patches towards 2.6.1, 2.6.2, etc. and frees the 
> HEAD for evolutionary work.
>
> With Eric's recent burst of activity to tie off niggling remaining 
> issues, I think we've gotten what we're going to get out of an RC 
> series on this and need to put this binary out there and start work 
> towards a 2.6.1 etc.
>
> +1 to release 2.6.0 GA.
>
> Andrew
>
>
>
> -- 
> 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


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Maven branch

[Eric Dalquist]

I've created a 'working-maven2' branch off the trunk today to start on 
converting to maven for the build management. I'm trying out svnmerge 
http://www.orcaware.com/svn/wiki/Svnmerge.py a tool that is supposed to 
help ease some of the issues involved in branching and merging in SVN. I 
would ask if you are going to be merging in either direction on the 
'working-maven2' branch that you use this tool. Other activity on 
uPortal 2 doesn't need to worry about this.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 2.6.1 Release

[Eric Dalquist]

It looks like this deployPortletApp issue is causing quite a few people 
problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792 
fixed and a 2.6.1 release out ASAP to address the problem so people can 
actually use 2.6. If no one else gets to it first I'll try my hand at 
fixing it this afternoon and see how it goes. Are there any other issues 
that we would like to get in to a 2.6.1 release?

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.6.1 Release

[Eric Dalquist]

I believe there is a logging stats recorder configured by default now. 
Is this something that should be disabled for 2.6.1?

-Eric

Cris J Holdorph wrote:
> The following is the catalina.out, after server startup, bringing up 
> the guest page and logging in as demo.  Seems excessive to me, and not 
> present in previous uPortal GA releases.
>
> INFO: Server startup in 8208 ms
> Session created for GUEST_USER (guest) at Mon Aug 13 10:41:27 MST 2007
> Channel [Header, 10, n2] was instantiated in layout 1 by GUEST_USER 
> (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [Login, 99, n3] was instantiated in layout 1 by GUEST_USER 
> (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [Locale Chooser, 96, n333] was instantiated in layout 1 by 
> GUEST_USER (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [DLM Administrator's Guide, 50, u8l1n52] was instantiated in 
> layout 1 by GUEST_USER (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [Footer, 19, n26] was instantiated in layout 1 by GUEST_USER 
> (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [Login, 99, n3] was rendered in layout 1 by GUEST_USER (guest) 
> at Mon Aug 13 10:41:28 MST 2007
> Channel [Header, 10, n2] was rendered in layout 1 by GUEST_USER 
> (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [DLM Administrator's Guide, 50, u8l1n52] was rendered in 
> layout 1 by GUEST_USER (guest) at Mon Aug 13 10:41:28 MST 2007
> Channel [Footer, 19, n26] was rendered in layout 1 by GUEST_USER 
> (guest) at Mon Aug 13 10:41:28 MST 2007
> Session destroyed for GUEST_USER (guest) at Mon Aug 13 10:41:33 MST 2007
> Demo User (demo) logged in successfully at Mon Aug 13 10:41:33 MST 2007
> Session created for Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Header, 10, n2] was instantiated in layout 1 by Demo User 
> (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Login, 99, n3] was instantiated in layout 1 by Demo User 
> (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Locale Chooser, 96, n333] was instantiated in layout 1 by 
> Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Number Guessing Game, 14, u4l1n49] was instantiated in layout 
> 1 by Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Minesweeper, 9, u4l1n51] was instantiated in layout 1 by Demo 
> User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Daily Business Cartoon, 1, u4l1n50] was instantiated in 
> layout 1 by Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Footer, 19, n28] was instantiated in layout 1 by Demo User 
> (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Login, 99, n3] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:41:33 MST 2007
> Channel [Header, 10, n2] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:41:33 MST 2007
> Channel [Number Guessing Game, 14, u4l1n49] was rendered in layout 1 
> by Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Minesweeper, 9, u4l1n51] was rendered in layout 1 by Demo 
> User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Daily Business Cartoon, 1, u4l1n50] was rendered in layout 1 
> by Demo User (demo) at Mon Aug 13 10:41:33 MST 2007
> Channel [Footer, 19, n28] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:41:33 MST 2007
> Channel [User Preferences, 91, ctf1] was targeted in layout 1 by Demo 
> User (demo) at Mon Aug 13 10:42:02 MST 2007
> Channel [User Preferences, 91, ctf1] was instantiated in layout 1 by 
> Demo User (demo) at Mon Aug 13 10:42:02 MST 2007
> Channel [Login, 99, n3] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:42:02 MST 2007
> Channel [Header, 10, n2] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:42:02 MST 2007
> Channel [User Preferences, 91, ctf1] was rendered in layout 1 by Demo 
> User (demo) at Mon Aug 13 10:42:03 MST 2007
> Channel [Footer, 19, n28] was rendered in layout 1 by Demo User (demo) 
> at Mon Aug 13 10:42:03 MST 2007
>
>
> Cris J Holdorph wrote:
>> Log levels seem too high for default use.  I don't remember any 
>> previous uPortal GA release containing logs about channels being 
>> rendered.
>>
>>  Cris J H
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] 2-6-patches branch

[Eric Dalquist]

Just a friendly reminder that all work on 2.6.1 and other 2.6 related 
work needs to happen on the 2-6-patches branch. I'll be watching the 
branch and merging changes back into the trunk as needed.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.6.1 Release

[Eric Dalquist]

Sounds like we have two new issues here that need to be created.

1. Turn off stats logging (things are verbose enough already)

2. Possible markup / horizontal scrollbar issue.

I have enough info to file and fix 1 but would need more details to 
attempt 2.

My goal is to do a 2.6.1-RC1 Tuesday next week and then GA the Monday 
after that. Please take a look at 
http://www.ja-sig.org/issues/secure/IssueNavigator.jspa?reset=true&pid=10020&fixfor=10481
 
and make sure any issues important to you are there.

-Eric


Cris J Holdorph wrote:
> Another thing I've noticed, that I thought Mark McCellan at Unicon 
> said was fixed, is there is commonly (not all the time) a horizontal 
> scrollbar being displayed.  I know this is only an issue with the 
> default theme/skin, but it would be nice to tidy it up, if possible.
>
>  Cris J H
>
> Eric Dalquist wrote:
>> It looks like this deployPortletApp issue is causing quite a few 
>> people problems. I'd like to get 
>> http://www.ja-sig.org/issues/browse/UP-1792 fixed and a 2.6.1 release 
>> out ASAP to address the problem so people can actually use 2.6. If no 
>> one else gets to it first I'll try my hand at fixing it this 
>> afternoon and see how it goes. Are there any other issues that we 
>> would like to get in to a 2.6.1 release?
>>
>> -Eric
>


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] uPortal packaging

[Eric Dalquist]

I'm working on mavenizing the trunk of uPortal and have run into a few 
questions I'd like to pose to the group.

The big one is packaging. Using maven for build management really lends 
itself to generating an EAR since it allows multiple WARs (uPortal and 
each portlet app) and shared libraries. For uPortal 3 sandbox 
development we already have an EAR -> Tomcat deployer tool which puts 
the WARs and JARs in the correct locations.

The problem with the EAR approach is it does not (as far as I can tell) 
allow for differentiation of what libraries are shared by just the WARs 
(pluto) and what libraries need to be shared with the servlet container 
(jdbc driver for JNDI datasource).

I'm not quite sure what to do about this. We don't really need to use 
JNDI for the DataSource in the quickstart / out of the box configuration 
but providing a way to do it without having to come up with a custom 
development process would be very good.

Discussion and suggestions are both welcome.
-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] UP-1794: Filter out unsafe href and src schemes from RSS content in CSyndFeed channel

[Eric Dalquist]

Nope, it should make it in. I'll take a look tomorrow.

-Eric

Brad Johnson wrote:
> Hello All,
>
> I've posted a patch for UP-1794 (Filter out unsafe href and src schemes
> from RSS content in CSyndFeed channel) and would appreciate comments and
> feedback.
>
> Also, is it too late for this fix to go into 2.6.1-RC1?
>
> thanks,
> Brad Johnson
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal packaging

[Eric Dalquist]

That would be wonderful, could you just attach them to an email in this 
thread? That sounds like a good approach to generating the final 
artifact to deploy.

-Eric

Brad Szabo wrote:
> Hi Eric, 
>
> I utilize the Maven Assembly plugin to create a Tomcat overlay archive
> (zip file in my case) which allows for easy extraction of items into
> various Tomcat directories as needed... webapps, common, conf etc...
>
> I can contribute the POM configuration and the assembly descriptor if
> you are interested.
>
> Thanks,
> Brad
>
> On Thu, 2007-08-16 at 17:15 -0500, Eric Dalquist wrote:
>   
>> I'm working on mavenizing the trunk of uPortal and have run into a few 
>> questions I'd like to pose to the group.
>>
>> The big one is packaging. Using maven for build management really lends 
>> itself to generating an EAR since it allows multiple WARs (uPortal and 
>> each portlet app) and shared libraries. For uPortal 3 sandbox 
>> development we already have an EAR -> Tomcat deployer tool which puts 
>> the WARs and JARs in the correct locations.
>>
>> The problem with the EAR approach is it does not (as far as I can tell) 
>> allow for differentiation of what libraries are shared by just the WARs 
>> (pluto) and what libraries need to be shared with the servlet container 
>> (jdbc driver for JNDI datasource).
>>
>> I'm not quite sure what to do about this. We don't really need to use 
>> JNDI for the DataSource in the quickstart / out of the box configuration 
>> but providing a way to do it without having to come up with a custom 
>> development process would be very good.
>>
>> Discussion and suggestions are both welcome.
>> -Eric
>> 
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uPortal packaging

[Eric Dalquist]

Elliot Metsger wrote:
>
>
> Eric Dalquist wrote:
>> I'm working on mavenizing the trunk of uPortal and have run into a 
>> few questions I'd like to pose to the group.
>>
>> The big one is packaging. 
>
> Are you referring to packaging up uPortal for a release (i.e. a binary 
> distribution) or are you talking about a developer deploying from the 
> command line (say, someone who has checked out the tag from SVN) using 
> Maven?
Well actually we need to figure out both.
>
>> Using maven for build management really lends itself to generating an 
>> EAR since it allows multiple WARs (uPortal and each portlet app) and 
>> shared libraries. For uPortal 3 sandbox development we already have 
>> an EAR -> Tomcat deployer tool which puts the WARs and JARs in the 
>> correct locations.
>
> It has been a while - did the sandbox ear deployer ever correctly 
> deploy shared libraries, or did we punt on that?
The sandbox deployer would put the JARs in the EAR into shared/lib and 
then deploy the WARs to webapps named based on info in 
META-INF/application.xml
>
>> The problem with the EAR approach is it does not (as far as I can 
>> tell) allow for differentiation of what libraries are shared by just 
>> the WARs (pluto) and what libraries need to be shared with the 
>> servlet container (jdbc driver for JNDI datasource).
>
> I agree, afaik ear packaging isn't able to specify what goes into a 
> shared classloader.  If a webapp jar has a dependency on a shared 
> library, it needs to add the shared library in its MANIFEST.MF file, 
> but the ear itself doesn't contain the shared lib.
>
> I think of it as the  dependency scope in M2.  The 
> dependency exists but it is provided by the container at runtime.
EARs can contain JAR resources. The problem comes in that Tomcat has 
different places for shared libraries, some go in shared/lib some go in 
common/lib and differentiating that isn't possible as far as I can tell.
>
>> I'm not quite sure what to do about this. We don't really need to use 
>> JNDI for the DataSource in the quickstart / out of the box 
>> configuration but providing a way to do it without having to come up 
>> with a custom development process would be very good.
>
> I think if we're talking about a binary distribution (not a 
> quickstart), it is reasonable to ask deployers of uPortal to download 
> their JDBC driver and put it into the shared classloader of their 
> servlet container.  Perhaps the uPortal binary distribution ships with 
> some common JDBC drivers, and an ant installer takes care of the rest.
I thought about that, it is a similar approach to what I've seen other 
projects do. The downside to this is almost everyone is going to be 
putting their JDBC driver in shared/lib and configuring context.xml 
(though that can go in uPortal/META-INF) with JNDI datasources. Since 
most people are going to want to include that process in their overall 
build having something in the default build process that addresses this 
would be nice. At this point I'm thinking of a combination of building 
an EAR (that has a lot of appeal to me as it is a standard packaging) 
with an assembly profile for tomcat to get packaging figured out.
>
> Or perhaps I'm not fully understanding the issue,
> Elliot
>


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Merging & SVN

[Eric Dalquist]

Not sure how many people here used the CVS merge functionality when 
committing to a branch & trunk or to multiple branches. If you did you 
may have noticed that SVN's merge support is less than stellar.

I've started using svnmerge ( 
http://www.orcaware.com/svn/wiki/Svnmerge.py ) which uses properties to 
keep track of revisions that have and have not been merged between 
branches. The wiki page they have gives good examples of common use 
cases and can make moving changes between branches much easier. People 
are welcome to use this to facilitate merges and post questions about 
the tool here if you have them.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Requiring Jira issue ids in commit messages

[Eric Dalquist]

Brad Szabo was kind enough to share a SVN script that would require a 
Jira issue id to be referenced in the commit message for any commit. The 
script can be bypassed explicitly by adding NOJIRA instead of an issue 
ID and also allow commits from some automated tools such as the maven 
release plugin.

What are people's feelings on adding this script to our repository? It 
would require developers to at least acknowledge if there isn't a 
relevant Jira issue and remind us when we forget to add a reference to 
the relevant issue that does exist. I don't want to add something that 
is going to cause headaches or difficulties for commitiers but an 
automated catch might be nice to help enforce good behavior.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re:[uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution

[Eric Dalquist]

Moving this to the dev list.

After further consideration I would also like to put of the 2.6.1 
release until more time can be spent on this issue. I'll be doing some 
more digging tomorrow to see what the options are for a resolution to 
this problem. Any ideas and suggestions are welcome.

-Eric

Cris J Holdorph wrote:
> Just to bring this issue back to the foreground.  I believe the state 
> of affairs that Drew describes below, means that one of the primary 
> goals stated by Eric Dalquist, for a 2.6.1 release, has not been met.
>
> "It looks like this deployPortletApp issue is causing quite a few people
> problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792
> fixed and a 2.6.1 release out ASAP to address the problem so people can
> actually use 2.6."
>
> To sum up, I believe the issues with deployPortletApp (and drew gives 
> the latest version below) are with people trying to do "ant 
> initportal" from machines without general internet connectivity.
>
> The current "ant initportal" will still not run without internet 
> connectivity.  Just pull out your internet connection and try it.
>
> Previously, Eric had said he would tag up 2.6.1RC1 tomorrow morning. 
> Does this mean we should hold off tagging that RC, until we have a 
> solution for "ant initportal" with no internet?
>
>  Cris J H
>
> ps.  fwiw, the 'logging' issue is at least fixed ;)
>
> Drew Wills wrote:
>> For anyone who remembers and wondered about the issues with 
>> deployPortletApp that Sherwin of BYU was having last week...
>>
>> I worked with Sherwin off-list to get to the heart of the matter.
>>
>> At first, you'll remember, Sherwin wasn't able to connect to 
>> svn.apache.org to pull the portlet.tld because the server he was 
>> using wasn't able to see the outside Internet.  We all agreed that 
>> the deployer should be reworked to pull that tld file from somewhere 
>> local.  Additionally, Eric Dalquist pointed out that the version of 
>> the tld was incorrect:  the script was pointing to the pluto 1.1 
>> version where we needed 1.0.1.
>>
>> Eric created 2 JIRA issues (one to pull locally, one to fix the 
>> version) and I made the changes -- 2.6.1 will have both fixes.  But 
>> Sherwin was still having problems.
>>
>> It turns out he wasn't able to deploy any portletApp that contains a 
>> web.xml file with a  declaration like the following:
>>
>> > 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";>
>>
>> It looks as though the XML parser will *always* try to load the DTD 
>> from java.sun.com, even if validation is turned off.  I suppose it 
>> makes sense, since the DTD may contain entities (or default 
>> attributes?) used in the document.
>>
>> This means that the 'deployPortletApp' target requires an Internet 
>> connection, or (alternately) someone must manually remove the DTD 
>> references or entire  declarations (it works without them) 
>> from the web.xml files of any portletApps that will be deployed.
>>
>> For comparison, the previous deployer used the WebAppDtdResolver 
>> class to intercept the XML parser's attempt to load a DTD and supply 
>> a local copy.  The DTD to use was hard-coded (the 'systemId' 
>> parameter was not even referenced), such that all web.xml files 
>> essentially referenced the servlet spec 2.3 DTD... which is of course 
>> the major problem the new deployer fixes.
>>
>> Does anyone have a problem with *not* intercepting these DTD 
>> references?  Does anyone have any other really cool suggestions?
>>
>> drew wills
>
> --- You are currently subscribed to [EMAIL PROTECTED] as: 
> [EMAIL PROTECTED]
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-user


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Requiring Jira issue ids in commit messages

[Eric Dalquist]

Sounds like everyone is for it (the CAS folks are as well), I'll work on 
getting this set up next week.

Currently the script will allow commits with any of these strings in the 
message to go through (none are case sensitive):
NOJIRA
JIRA Issue: AA-
[maven-release-plugin]

If people have suggestions for changes or other allowed strings let me know.

-Eric

George Lindholm wrote:
> I'm all for. If you use Mylyn this will be done automatically for you
> when you do a commit.
>
> +1
>
> George
>
> Eric Dalquist wrote:
>   
>> Brad Szabo was kind enough to share a SVN script that would require a 
>> Jira issue id to be referenced in the commit message for any commit. The 
>> script can be bypassed explicitly by adding NOJIRA instead of an issue 
>> ID and also allow commits from some automated tools such as the maven 
>> release plugin.
>>
>> What are people's feelings on adding this script to our repository? It 
>> would require developers to at least acknowledge if there isn't a 
>> relevant Jira issue and remind us when we forget to add a reference to 
>> the relevant issue that does exist. I don't want to add something that 
>> is going to cause headaches or difficulties for commitiers but an 
>> automated catch might be nice to help enforce good behavior.
>>
>> -Eric
>>   
>> 
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution

[Eric Dalquist]

That is a great link Alex, I was thinking there had to be a common 
EntityResolver impl that could look at the local file system first 
before going to the net. We'll look at using this for the portlet 
deployer for 2.6.1

-Eric

Alex Vigdor wrote:
> Hey Eric (and everybody),
> Just a tip since I've dealt with this problem a few times before, 
> first with HyperContent.  You just need to configure a SAX 
> EntityResolver that will look up local copies of resources that are 
> normally found online.  This way you can leave doctypes intact and 
> still work offline.  The standard way to do this is with a "catalog 
> file" that maps system or public identifiers to local file paths.  The 
> catalog file is based on an Oasis standard.  Here's an open-source 
> catalog resolver implementation:
>
> http://xml.apache.org/commons/components/resolver/
>
> You can set the EntityResolver on the XMLReader used for parsing.
>
> -Alex
>
> On Aug 20, 2007, at 7:13 PM, Eric Dalquist wrote:
>
>> Moving this to the dev list.
>>
>> After further consideration I would also like to put of the 2.6.1
>> release until more time can be spent on this issue. I'll be doing some
>> more digging tomorrow to see what the options are for a resolution to
>> this problem. Any ideas and suggestions are welcome.
>>
>> -Eric
>>
>> Cris J Holdorph wrote:
>>> Just to bring this issue back to the foreground.  I believe the state
>>> of affairs that Drew describes below, means that one of the primary
>>> goals stated by Eric Dalquist, for a 2.6.1 release, has not been met.
>>>
>>> "It looks like this deployPortletApp issue is causing quite a few 
>>> people
>>> problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792
>>> fixed and a 2.6.1 release out ASAP to address the problem so people can
>>> actually use 2.6."
>>>
>>> To sum up, I believe the issues with deployPortletApp (and drew gives
>>> the latest version below) are with people trying to do "ant
>>> initportal" from machines without general internet connectivity.
>>>
>>> The current "ant initportal" will still not run without internet
>>> connectivity.  Just pull out your internet connection and try it.
>>>
>>> Previously, Eric had said he would tag up 2.6.1RC1 tomorrow morning.
>>> Does this mean we should hold off tagging that RC, until we have a
>>> solution for "ant initportal" with no internet?
>>>
>>>  Cris J H
>>>
>>> ps.  fwiw, the 'logging' issue is at least fixed ;)
>>>
>>> Drew Wills wrote:
>>>> For anyone who remembers and wondered about the issues with
>>>> deployPortletApp that Sherwin of BYU was having last week...
>>>>
>>>> I worked with Sherwin off-list to get to the heart of the matter.
>>>>
>>>> At first, you'll remember, Sherwin wasn't able to connect to
>>>> svn.apache.org to pull the portlet.tld because the server he was
>>>> using wasn't able to see the outside Internet.  We all agreed that
>>>> the deployer should be reworked to pull that tld file from somewhere
>>>> local.  Additionally, Eric Dalquist pointed out that the version of
>>>> the tld was incorrect:  the script was pointing to the pluto 1.1
>>>> version where we needed 1.0.1.
>>>>
>>>> Eric created 2 JIRA issues (one to pull locally, one to fix the
>>>> version) and I made the changes -- 2.6.1 will have both fixes.  But
>>>> Sherwin was still having problems.
>>>>
>>>> It turns out he wasn't able to deploy any portletApp that contains a
>>>> web.xml file with a  declaration like the following:
>>>>
>>>> >>> Application
>>>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";>
>>>>
>>>> It looks as though the XML parser will *always* try to load the DTD
>>>> from java.sun.com, even if validation is turned off.  I suppose it
>>>> makes sense, since the DTD may contain entities (or default
>>>> attributes?) used in the document.
>>>>
>>>> This means that the 'deployPortletApp' target requires an Internet
>>>> connection, or (alternately) someone must manually remove the DTD
>>>> references or entire  declarations (it works without them)
>>>> from the web.xml files of any portletApps that will be deployed.
>>>>
>>>> For comparison, the previous deployer used the WebAppDtdResolver
>>>> class to intercept the XML parser's attempt to load a DTD and supply
>>>> a local copy.  The DTD to use was hard-coded (the 'systemId'
>>>> parameter was not even referenced), such that all web.xml files
>>>> essentially referenced the servlet spec 2.3 DTD... which is of course
>>>> the major problem the new deployer fixes.
>>>>
>>>> Does anyone have a problem with *not* intercepting these DTD
>>>> references?  Does anyone have any other really cool suggestions?
>>>>
>>>> drew wills
>>>
>>> --- You are currently subscribed to [EMAIL PROTECTED] as:
>>> [EMAIL PROTECTED]
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Requiring Jira issue ids in commit messages

[Eric Dalquist]

I just had the same comment from the CAS side. I think I'll replace the  
'JIRA Issue: AA-' with a rule that allows any commit through that 
starts with  'AA-'. Just doing AA- anywhere in the message is 
very likely to find false positives which is why I would require it at 
the start of the message.

-Eric

George Lindholm wrote:
> Eric Dalquist wrote:
>   
>> Sounds like everyone is for it (the CAS folks are as well), I'll work
>> on getting this set up next week.
>>
>> Currently the script will allow commits with any of these strings in
>> the message to go through (none are case sensitive):
>> NOJIRA
>> JIRA Issue: AA-
>> [maven-release-plugin]
>>
>> If people have suggestions for changes or other allowed strings let me
>> know.
>> 
>
>
> Hi Eric,
>   is that literally "JIRA Issue: AA-", or would the comment really
> start with "AA-"?
> My preferences would be for "AA-", again using Mylyn.
>
>George
>   
>> -Eric
>>
>> George Lindholm wrote:
>> 
>>> I'm all for. If you use Mylyn this will be done automatically for you
>>> when you do a commit.
>>>
>>> +1
>>>
>>> George
>>>
>>> Eric Dalquist wrote:
>>>   
>>>   
>>>> Brad Szabo was kind enough to share a SVN script that would require a 
>>>> Jira issue id to be referenced in the commit message for any commit. The 
>>>> script can be bypassed explicitly by adding NOJIRA instead of an issue 
>>>> ID and also allow commits from some automated tools such as the maven 
>>>> release plugin.
>>>>
>>>> What are people's feelings on adding this script to our repository? It 
>>>> would require developers to at least acknowledge if there isn't a 
>>>> relevant Jira issue and remind us when we forget to add a reference to 
>>>> the relevant issue that does exist. I don't want to add something that 
>>>> is going to cause headaches or difficulties for commitiers but an 
>>>> automated catch might be nice to help enforce good behavior.
>>>>
>>>> -Eric
>>>>   
>>>> 
>>>> 
>>>   
>>>   
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Requiring Jira issue ids in commit messages

[Eric Dalquist]

Sounds like a good plan for the expressions.

As for validating against Jira. I had thought about that but I'm not 
sure I want commits to fail if Jira is down. Does anyone else have 
thoughts on doing Jira issue ID validation?

-Eric

George Lindholm wrote:
> Eric Dalquist wrote:
>   
>> I just had the same comment from the CAS side. I think I'll replace
>> the  'JIRA Issue: AA-' with a rule that allows any commit through
>> that starts with  'AA-'. Just doing AA- anywhere in the
>> message is very likely to find false positives which is why I would
>> require it at the start of the message.
>> 
>
> Hi Eric,
>   I agree. The issue number should be at the begining. How about
> requiring that the commit
> message must match:
>
> ^(NOJIRA|\[maven-release-plugin\]|[A-Z]+?-\d=?):
>
> I think you should be able to validate the issue number against jira in
> the commit hook script as well.
>
>George
>   
>> -Eric
>>
>> George Lindholm wrote:
>> 
>>> Eric Dalquist wrote:
>>>   
>>>   
>>>> Sounds like everyone is for it (the CAS folks are as well), I'll work
>>>> on getting this set up next week.
>>>>
>>>> Currently the script will allow commits with any of these strings in
>>>> the message to go through (none are case sensitive):
>>>> NOJIRA
>>>> JIRA Issue: AA-
>>>> [maven-release-plugin]
>>>>
>>>> If people have suggestions for changes or other allowed strings let me
>>>> know.
>>>> 
>>>> 
>>> Hi Eric,
>>>   is that literally "JIRA Issue: AA-", or would the comment really
>>> start with "AA-"?
>>> My preferences would be for "AA-", again using Mylyn.
>>>
>>>George
>>>   
>>>   
>>>> -Eric
>>>>
>>>> George Lindholm wrote:
>>>> 
>>>> 
>>>>> I'm all for. If you use Mylyn this will be done automatically for you
>>>>> when you do a commit.
>>>>>
>>>>> +1
>>>>>
>>>>> George
>>>>>
>>>>> Eric Dalquist wrote:
>>>>>   
>>>>>   
>>>>>   
>>>>>> Brad Szabo was kind enough to share a SVN script that would require a 
>>>>>> Jira issue id to be referenced in the commit message for any commit. The 
>>>>>> script can be bypassed explicitly by adding NOJIRA instead of an issue 
>>>>>> ID and also allow commits from some automated tools such as the maven 
>>>>>> release plugin.
>>>>>>
>>>>>> What are people's feelings on adding this script to our repository? It 
>>>>>> would require developers to at least acknowledge if there isn't a 
>>>>>> relevant Jira issue and remind us when we forget to add a reference to 
>>>>>> the relevant issue that does exist. I don't want to add something that 
>>>>>> is going to cause headaches or difficulties for commitiers but an 
>>>>>> automated catch might be nice to help enforce good behavior.
>>>>>>
>>>>>> -Eric
>>>>>>   
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>   
>>>>>   
>>>>>   
>>>   
>>>   
>
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Can't initportal 2.6GA -- Resolution

[Eric Dalquist]

Looks like a great resolution Drew and should provided options going 
forward for better offline DTD handling in other parts of the framework.

I'm heading out for a long weekend tomorrow afternoon so I'll resume the 
2.6.1 RC1 push when I get back.

-Eric

Drew Wills wrote:
> I created JIRA UP-1800 (http://www.ja-sig.org/issues/browse/UP-1800) 
> to track this effort, then I created a solution based on Alex's 
> suggestion.
>
> The enhancement is checked into 2-6-patches & trunk, and the JIRA is 
> resolved.
>
> As it stands, the only DTD that the EntityResolver can load locally is 
> the servlet 2.3 DTD, located in webpages/dtd/ -- but of course, that's 
> the only one that was preventing disconnected michines from deploying.
>
> If you want to provide local support for any other DTDs, place them in 
> the same folder and create an entry for each of them in the 
> webpages/dtd/xml-catalog.xml file.
>
>
> drew wills
>
>
> Eric Dalquist wrote:
>> That is a great link Alex, I was thinking there had to be a common 
>> EntityResolver impl that could look at the local file system first 
>> before going to the net. We'll look at using this for the portlet 
>> deployer for 2.6.1
>>
>> -Eric
>>
>> Alex Vigdor wrote:
>>> Hey Eric (and everybody),
>>> Just a tip since I've dealt with this problem a few times 
>>> before, first with HyperContent.  You just need to configure a SAX 
>>> EntityResolver that will look up local copies of resources that are 
>>> normally found online.  This way you can leave doctypes intact and 
>>> still work offline.  The standard way to do this is with a "catalog 
>>> file" that maps system or public identifiers to local file paths.  
>>> The catalog file is based on an Oasis standard.  Here's an 
>>> open-source catalog resolver implementation:
>>>
>>> http://xml.apache.org/commons/components/resolver/
>>>
>>> You can set the EntityResolver on the XMLReader used for parsing.
>>>
>>> -Alex
>>>
>>> On Aug 20, 2007, at 7:13 PM, Eric Dalquist wrote:
>>>
>>>> Moving this to the dev list.
>>>>
>>>> After further consideration I would also like to put of the 2.6.1
>>>> release until more time can be spent on this issue. I'll be doing some
>>>> more digging tomorrow to see what the options are for a resolution to
>>>> this problem. Any ideas and suggestions are welcome.
>>>>
>>>> -Eric
>>>>
>>>> Cris J Holdorph wrote:
>>>>> Just to bring this issue back to the foreground.  I believe the state
>>>>> of affairs that Drew describes below, means that one of the primary
>>>>> goals stated by Eric Dalquist, for a 2.6.1 release, has not been met.
>>>>>
>>>>> "It looks like this deployPortletApp issue is causing quite a few 
>>>>> people
>>>>> problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792
>>>>> fixed and a 2.6.1 release out ASAP to address the problem so 
>>>>> people can
>>>>> actually use 2.6."
>>>>>
>>>>> To sum up, I believe the issues with deployPortletApp (and drew gives
>>>>> the latest version below) are with people trying to do "ant
>>>>> initportal" from machines without general internet connectivity.
>>>>>
>>>>> The current "ant initportal" will still not run without internet
>>>>> connectivity.  Just pull out your internet connection and try it.
>>>>>
>>>>> Previously, Eric had said he would tag up 2.6.1RC1 tomorrow morning.
>>>>> Does this mean we should hold off tagging that RC, until we have a
>>>>> solution for "ant initportal" with no internet?
>>>>>
>>>>>  Cris J H
>>>>>
>>>>> ps.  fwiw, the 'logging' issue is at least fixed ;)
>>>>>
>>>>> Drew Wills wrote:
>>>>>> For anyone who remembers and wondered about the issues with
>>>>>> deployPortletApp that Sherwin of BYU was having last week...
>>>>>>
>>>>>> I worked with Sherwin off-list to get to the heart of the matter.
>>>>>>
>>>>>> At first, you'll remember, Sherwin wasn't able to connect to
>>>>>> svn.apache.org to pull the portlet.tld because the server he was
>>>&g

[uportal-dev] 2.6.1-RC

[Eric Dalquist]

I'd like to cut RC1 of 2.6.1 this evening or tomorrow morning. A summary 
of fixes and such can be found on Jira:
http://www.ja-sig.org/issues/secure/IssueNavigator.jspa?reset=true&&pid=10020&fixfor=10497&sorter/field=issuekey&sorter/order=DESC&sorter/field=status&sorter/order=ASC

If I don't hear any objections to the current state of the patches 
branch I'll be getting it cut this evening.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.6.1-RC

[Eric Dalquist]

uPortal developers,
uPortal 2.6.1 release candidate one is now available from the uPortal downloads page.
A release candidate signals "feature completeness", makes a binary
available for easy downloading and testing, and provides a concrete
artifact to talk about and open issues against. It also defines a
serious candidate for release as uPortal 2.6.1 GA. There are a short
list of known issues to be resolved before GA, but it's a short list.
Unless additional significant issues are raised, this will be uPortal
2.6.1.
Release notes are available in
the wiki.
Since the GA release of uPortal 2.6.0, six issues have been
addressed, including a functional off-line build and deploy script.
Eric Dalquist
uPortal 2.6.1 release engineer




smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Updated Commit Conventions for JA-SIG Subversion

[Eric Dalquist]

uPortal Developers,

Though adding the JIRA issue to your commit message has been our policy 
for a while, the JA-SIG Subversion will now require it.  Your commit 
will be rejected if there is no corresponding JIRA issue at the start of 
the commit message (or that you specifically note there is no JIRA issue.

The following are acceptable starts to a commit message:

NOJIRA
AA-
[maven-release-plugin]

The first being the message that explicitly says there is no JIRA issue, 
the second being a valid JIRA issue ( i.e. the correct format) and the 
third being if you use the maven-release plugin.

This will go into effect today.  If you experience any issues please let 
me know.

Thanks
-Eric 


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] [VOTE] 2.6.1-GA

[Eric Dalquist]

With no negative feedback on the RC I'd like to propose cutting the
2.6.1-GA release based on this code. Please respond with your vote on
releasing.

Thank you,
-Eric

Eric Dalquist wrote:

  
uPortal developers,
uPortal 2.6.1 release candidate one is now available from the
uPortal downloads page.
  A release candidate signals "feature completeness", makes a binary
available for easy downloading and testing, and provides a concrete
artifact to talk about and open issues against. It also defines a
serious candidate for release as uPortal 2.6.1 GA. There are a short
list of known issues to be resolved before GA, but it's a short list.
Unless additional significant issues are raised, this will be uPortal
2.6.1.
  Release notes are available in
the wiki.
  Since the GA release of uPortal 2.6.0, six issues have been
addressed, including a functional off-line build and deploy script.
  Eric Dalquist
uPortal 2.6.1 release engineer





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [VOTE] 2.6.1-GA

[Eric Dalquist]

With this known issue I'm going to put the prospects of a GA release on 
hold for now. We'll see what Drew & Elliot come up with and go from there.

-Eric

Elliot Metsger wrote:
> I'm working on testing http://www.ja-sig.org/issues/browse/UP-1819 - 
> see the "Cernnunos error with HEAD of rel-2-6-patches" thread.
>
> It may be specific to the Mac platform, I'm not sure.  I'm going to 
> run a couple of additional tests for Drew.
>
> Elliot
>
> Eric Dalquist wrote:
>> With no negative feedback on the RC I'd like to propose cutting the 
>> 2.6.1-GA release based on this code. Please respond with your vote on 
>> releasing.
>>
>> Thank you,
>> -Eric
>>
>> Eric Dalquist wrote:
>>> uPortal developers,
>>> uPortal 2.6.1 release candidate one is now available from the 
>>> uPortal downloads page^ 
>>> <http://www.uportal.org/release/allReleases.html>.
>>>
>>> A release candidate signals "feature completeness", makes a binary 
>>> available for easy downloading and testing, and provides a concrete 
>>> artifact to talk about and open issues against. It also defines a 
>>> serious candidate for release as uPortal 2.6.1 GA. There are a short 
>>> list of known issues to be resolved before GA, but it's a short 
>>> list. Unless additional significant issues are raised, this will be 
>>> uPortal 2.6.1.
>>>
>>> Release notes are available in the wiki^ 
>>> <http://www.ja-sig.org/wiki/display/UPC/2.6.1+RC1>.
>>>
>>> Since the GA release of uPortal 2.6.0, six issues have been 
>>> addressed, including a functional off-line build and deploy script.
>>>
>>> Eric Dalquist
>>> uPortal 2.6.1 release engineer
>>>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re:[uportal-dev] [uportal-user] uPortal Session Failures?

[Eric Dalquist]

There is a possible patch for this issue attached to the Jira case: 
http://www.ja-sig.org/issues/browse/UP-1816

This patch *_HAS NOT_* been extensively tested yet and makes some 
significant changes in the ChannelRender and related code. The Jira 
issue also has a link to yesterday's IRC log which I would recommend 
reading if you are interested in an in-depth discussion about the 
probably underlying issue causing the session bug.

The high level overview is that due to uPortal's multi-threaded 
rendering model the Tomcat requestDispatcher is creating incorrectly 
wrapped HttpServletRequest objects to pass to the portlets for rendering.


A more detailed overview follows, if there are questions about the patch 
please ask.

Until an errata was recently filed in the servlet 2.4 spec it was 
against spec to allow multiple threads to access the request or response 
objects. The errata changed this so that it is no longer against spec 
but containers can optionally support multi-threaded access to these 
objects. With this wording it is not specifically a Tomcat bug, just an 
optional part of the spec that Tomcat does not implement.

The patch involves having the ChannelRenderer.Worker class, which 
invokes rendering on a channel, create a wrapper around the 
HttpServletRequest specific for the thread that Worker is running in. 
The wrapper implements HttpServletRequest directly instead of extending 
HttpServletRequestWrapper to stop Tomcat from un-wrapping the wrapper. 
Passing objects back to the servlet container that are not either the 
original request object or extended from HttpServletRequestWrapper is 
also against the servlet spec, though breaking spec compliance in this 
area should fix the session problem and doesn't appear to cause other 
problems.

The objects, specifically PortalControlStructures, which track the 
request and response through the rendering pipeline have also been 
modified to use ThreadLocals. This allows each rendering thread to have 
its own request and response objects as required by this patch.

This patch is very closely based on code that UW-Madison has been 
running since going live in June 2006. It was not contributed back 
earlier due to both the significance of the changes in the rendering 
pipeline and the thought that the problem being addressed by the change 
was specific to a special case here at UW.

I would encourage people experiencing the session problem and those who 
are familiar with the inner workings of the uPortal channel rendering 
code to try the patch and provide feedback. The patch was created 
against the 2.5-patches branch. Once some testing has been done on it 
confirming its viability I will create a patch for the 2.6-patches 
branch as well.

-Eric

Elliot Metsger wrote:
> Yup,
>
> I pulled HEAD of the 2-6-patches branch, and the buggy behavior still 
> exists
>
> Parker Grimes wrote:
>> Elliot,
>>
>> Yes we are using uPortal 2.6.0 GA with no custom patches. getMarkup() in
>> CPortletAdapter is synchronized.
>>
>> -Parker
>>
>> On 9/9/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi Parker,
>>>
>>> Quick question: are you using uPortal 2.6.0 GA?  Have you applied any
>>> custom
>>> patches?
>>>
>>> I'm curious if your CPortletAdapter's getMarkup() method is 
>>> synchronized.
>>>
>>>
>>> Parker Grimes wrote:
 This is sounding very familiar to what we have been experiencing. 
 We use
 uPortal 2.6.0 and the Spring Portlet MVC.

>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 
>>>
>>> Sent from the uPortal - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---
>>> You are currently subscribed to [EMAIL PROTECTED] as:
>>> [EMAIL PROTECTED]
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>>>
>>
>> --- You are currently subscribed to [EMAIL PROTECTED] as: 
>> [EMAIL PROTECTED]
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>
> --- You are currently subscribed to [EMAIL PROTECTED] as: 
> [EMAIL PROTECTED]
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-user


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [uportal-user] uPortal Session Failures?

[Eric Dalquist]

I'll get one ready ASAP with that kind of testing offer.

-Eric

Cris J Holdorph wrote:
> Please let me know when a 2.6 patch is available, I have a training 
> class going right now, where multiple machines are experiencing this 
> problem with uPortal 2.6.0.  If we see a patch we could test it on a 
> couple machines.
>
>  Cris J H
>
> Eric Dalquist wrote:
>> There is a possible patch for this issue attached to the Jira case: 
>> http://www.ja-sig.org/issues/browse/UP-1816
>>
>> This patch *_HAS NOT_* been extensively tested yet and makes some 
>> significant changes in the ChannelRender and related code. The Jira 
>> issue also has a link to yesterday's IRC log which I would recommend 
>> reading if you are interested in an in-depth discussion about the 
>> probably underlying issue causing the session bug.
>>
>> The high level overview is that due to uPortal's multi-threaded 
>> rendering model the Tomcat requestDispatcher is creating incorrectly 
>> wrapped HttpServletRequest objects to pass to the portlets for 
>> rendering.
>>
>>
>> A more detailed overview follows, if there are questions about the 
>> patch please ask.
>>
>> Until an errata was recently filed in the servlet 2.4 spec it was 
>> against spec to allow multiple threads to access the request or 
>> response objects. The errata changed this so that it is no longer 
>> against spec but containers can optionally support multi-threaded 
>> access to these objects. With this wording it is not specifically a 
>> Tomcat bug, just an optional part of the spec that Tomcat does not 
>> implement.
>>
>> The patch involves having the ChannelRenderer.Worker class, which 
>> invokes rendering on a channel, create a wrapper around the 
>> HttpServletRequest specific for the thread that Worker is running in. 
>> The wrapper implements HttpServletRequest directly instead of 
>> extending HttpServletRequestWrapper to stop Tomcat from un-wrapping 
>> the wrapper. Passing objects back to the servlet container that are 
>> not either the original request object or extended from 
>> HttpServletRequestWrapper is also against the servlet spec, though 
>> breaking spec compliance in this area should fix the session problem 
>> and doesn't appear to cause other problems.
>>
>> The objects, specifically PortalControlStructures, which track the 
>> request and response through the rendering pipeline have also been 
>> modified to use ThreadLocals. This allows each rendering thread to 
>> have its own request and response objects as required by this patch.
>>
>> This patch is very closely based on code that UW-Madison has been 
>> running since going live in June 2006. It was not contributed back 
>> earlier due to both the significance of the changes in the rendering 
>> pipeline and the thought that the problem being addressed by the 
>> change was specific to a special case here at UW.
>>
>> I would encourage people experiencing the session problem and those 
>> who are familiar with the inner workings of the uPortal channel 
>> rendering code to try the patch and provide feedback. The patch was 
>> created against the 2.5-patches branch. Once some testing has been 
>> done on it confirming its viability I will create a patch for the 
>> 2.6-patches branch as well.
>>
>> -Eric
>>
>> Elliot Metsger wrote:
>>> Yup,
>>>
>>> I pulled HEAD of the 2-6-patches branch, and the buggy behavior 
>>> still exists
>>>
>>> Parker Grimes wrote:
>>>> Elliot,
>>>>
>>>> Yes we are using uPortal 2.6.0 GA with no custom patches. 
>>>> getMarkup() in
>>>> CPortletAdapter is synchronized.
>>>>
>>>> -Parker
>>>>
>>>> On 9/9/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Hi Parker,
>>>>>
>>>>> Quick question: are you using uPortal 2.6.0 GA?  Have you applied any
>>>>> custom
>>>>> patches?
>>>>>
>>>>> I'm curious if your CPortletAdapter's getMarkup() method is 
>>>>> synchronized.
>>>>>
>>>>>
>>>>> Parker Grimes wrote:
>>>>>> This is sounding very familiar to what we have been experiencing. 
>>>>>> We use
>>>>>> uPortal 2.6.0 and the Spring Portlet MVC.
>>>>>>
>>>>> -- 
>>>>> View this message in context:
>>>>> http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 
>>>>>
>>>>> Sent from the uPortal - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---
>>>>> You are currently subscribed to [EMAIL PROTECTED] as:
>>>>> [EMAIL PROTECTED]
>>>>> To unsubscribe, change settings or access archives, see
>>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>>>>>
>>>>
>>>> --- You are currently subscribed to [EMAIL PROTECTED] 
>>>> as: [EMAIL PROTECTED]
>>>> To unsubscribe, change settings or access archives, see 
>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>>>
>>> --- You are currently subscribed to [EMAIL PROTECTED] 
>>> as: [EMAIL PROTECTED]
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] [uportal-user] uPortal Session Failures?

[Eric Dalquist]

1) The Pluto 1.1 driver renders serially (and so do most other portal 
frameworks from the research I've done on this). In the uP3 sandbox code 
this unwrappable-wrapper concept was already implemented.

2) I have no idea. This is a pretty big change and we need a lot of 
testing from uPortal implementers before it is going to get applied in SVN.

3) I don't know, do you have any idea Elliot?

-Eric

We always have the fall back of trying to add synchronization around the 
request in CPortletAdapter and only allow serial rendering for portlets. 
This would be a smaller change as far as things breaking but would 
require implementers to re-evaluate rendering performance.


Cris J Holdorph wrote:
> I apologize if this is in the IRC log.
>
> two questions.
>
> 1) why does the pluto 1.1 driver (test portal) not exhibit the same 
> problem?  Do they do something similar to what your patch does for 
> uPortal?  Specifically breaking part of the servlet spec (even though 
> it probably is ok to do so)?
>
> 2) Will this change work in other containers?  I know that CalPoly 
> uses WebSphere (or did at some point in the past) and Colorado uses 
> Resin.
>
> And a bonus question...
> * Does Tomcat 6 implement this optional 'erata' part of the Servlet 
> spec?  That is if, someone spent enough time to get uPortal 2.6.0 
> running in Tomcat 6, are they unlikely to see the same problem?
>
>  Cris J H
>
> Eric Dalquist wrote:
>> There is a possible patch for this issue attached to the Jira case: 
>> http://www.ja-sig.org/issues/browse/UP-1816
>>
>> This patch *_HAS NOT_* been extensively tested yet and makes some 
>> significant changes in the ChannelRender and related code. The Jira 
>> issue also has a link to yesterday's IRC log which I would recommend 
>> reading if you are interested in an in-depth discussion about the 
>> probably underlying issue causing the session bug.
>>
>> The high level overview is that due to uPortal's multi-threaded 
>> rendering model the Tomcat requestDispatcher is creating incorrectly 
>> wrapped HttpServletRequest objects to pass to the portlets for 
>> rendering.
>>
>>
>> A more detailed overview follows, if there are questions about the 
>> patch please ask.
>>
>> Until an errata was recently filed in the servlet 2.4 spec it was 
>> against spec to allow multiple threads to access the request or 
>> response objects. The errata changed this so that it is no longer 
>> against spec but containers can optionally support multi-threaded 
>> access to these objects. With this wording it is not specifically a 
>> Tomcat bug, just an optional part of the spec that Tomcat does not 
>> implement.
>>
>> The patch involves having the ChannelRenderer.Worker class, which 
>> invokes rendering on a channel, create a wrapper around the 
>> HttpServletRequest specific for the thread that Worker is running in. 
>> The wrapper implements HttpServletRequest directly instead of 
>> extending HttpServletRequestWrapper to stop Tomcat from un-wrapping 
>> the wrapper. Passing objects back to the servlet container that are 
>> not either the original request object or extended from 
>> HttpServletRequestWrapper is also against the servlet spec, though 
>> breaking spec compliance in this area should fix the session problem 
>> and doesn't appear to cause other problems.
>>
>> The objects, specifically PortalControlStructures, which track the 
>> request and response through the rendering pipeline have also been 
>> modified to use ThreadLocals. This allows each rendering thread to 
>> have its own request and response objects as required by this patch.
>>
>> This patch is very closely based on code that UW-Madison has been 
>> running since going live in June 2006. It was not contributed back 
>> earlier due to both the significance of the changes in the rendering 
>> pipeline and the thought that the problem being addressed by the 
>> change was specific to a special case here at UW.
>>
>> I would encourage people experiencing the session problem and those 
>> who are familiar with the inner workings of the uPortal channel 
>> rendering code to try the patch and provide feedback. The patch was 
>> created against the 2.5-patches branch. Once some testing has been 
>> done on it confirming its viability I will create a patch for the 
>> 2.6-patches branch as well.
>>
>> -Eric
>>
>> Elliot Metsger wrote:
>>> Yup,
>>>
>>> I pulled HEAD of the 2-6-patches branch, and the buggy behavior 
>>> still exists
>>>
>>>

Re: [uportal-dev] [uportal-user] uPortal Session Failures?

[Eric Dalquist]

Patches that should work on the last rev from both the 2-5-patches and 
2-6-patches are now attached to the Jira issue: 
http://www.ja-sig.org/issues/browse/UP-1816

-Eric

Cris J Holdorph wrote:
> I apologize if this is in the IRC log.
>
> two questions.
>
> 1) why does the pluto 1.1 driver (test portal) not exhibit the same 
> problem?  Do they do something similar to what your patch does for 
> uPortal?  Specifically breaking part of the servlet spec (even though 
> it probably is ok to do so)?
>
> 2) Will this change work in other containers?  I know that CalPoly 
> uses WebSphere (or did at some point in the past) and Colorado uses 
> Resin.
>
> And a bonus question...
> * Does Tomcat 6 implement this optional 'erata' part of the Servlet 
> spec?  That is if, someone spent enough time to get uPortal 2.6.0 
> running in Tomcat 6, are they unlikely to see the same problem?
>
>  Cris J H
>
> Eric Dalquist wrote:
>> There is a possible patch for this issue attached to the Jira case: 
>> http://www.ja-sig.org/issues/browse/UP-1816
>>
>> This patch *_HAS NOT_* been extensively tested yet and makes some 
>> significant changes in the ChannelRender and related code. The Jira 
>> issue also has a link to yesterday's IRC log which I would recommend 
>> reading if you are interested in an in-depth discussion about the 
>> probably underlying issue causing the session bug.
>>
>> The high level overview is that due to uPortal's multi-threaded 
>> rendering model the Tomcat requestDispatcher is creating incorrectly 
>> wrapped HttpServletRequest objects to pass to the portlets for 
>> rendering.
>>
>>
>> A more detailed overview follows, if there are questions about the 
>> patch please ask.
>>
>> Until an errata was recently filed in the servlet 2.4 spec it was 
>> against spec to allow multiple threads to access the request or 
>> response objects. The errata changed this so that it is no longer 
>> against spec but containers can optionally support multi-threaded 
>> access to these objects. With this wording it is not specifically a 
>> Tomcat bug, just an optional part of the spec that Tomcat does not 
>> implement.
>>
>> The patch involves having the ChannelRenderer.Worker class, which 
>> invokes rendering on a channel, create a wrapper around the 
>> HttpServletRequest specific for the thread that Worker is running in. 
>> The wrapper implements HttpServletRequest directly instead of 
>> extending HttpServletRequestWrapper to stop Tomcat from un-wrapping 
>> the wrapper. Passing objects back to the servlet container that are 
>> not either the original request object or extended from 
>> HttpServletRequestWrapper is also against the servlet spec, though 
>> breaking spec compliance in this area should fix the session problem 
>> and doesn't appear to cause other problems.
>>
>> The objects, specifically PortalControlStructures, which track the 
>> request and response through the rendering pipeline have also been 
>> modified to use ThreadLocals. This allows each rendering thread to 
>> have its own request and response objects as required by this patch.
>>
>> This patch is very closely based on code that UW-Madison has been 
>> running since going live in June 2006. It was not contributed back 
>> earlier due to both the significance of the changes in the rendering 
>> pipeline and the thought that the problem being addressed by the 
>> change was specific to a special case here at UW.
>>
>> I would encourage people experiencing the session problem and those 
>> who are familiar with the inner workings of the uPortal channel 
>> rendering code to try the patch and provide feedback. The patch was 
>> created against the 2.5-patches branch. Once some testing has been 
>> done on it confirming its viability I will create a patch for the 
>> 2.6-patches branch as well.
>>
>> -Eric
>>
>> Elliot Metsger wrote:
>>> Yup,
>>>
>>> I pulled HEAD of the 2-6-patches branch, and the buggy behavior 
>>> still exists
>>>
>>> Parker Grimes wrote:
>>>> Elliot,
>>>>
>>>> Yes we are using uPortal 2.6.0 GA with no custom patches. 
>>>> getMarkup() in
>>>> CPortletAdapter is synchronized.
>>>>
>>>> -Parker
>>>>
>>>> On 9/9/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Hi Parker,
>>>>>
>>>>> Quick question: are you using uPortal 2.6.0 GA?  Have you applied 

[uportal-dev] uP3 Progress Report

[Eric Dalquist]

There hasn't been much traffic on about the uP3 work since the 
conference and hopefully this is the first of many messages resolving 
that problem.

Work has been happening on converting the trunk of the uPortal project 
to use Maven 2 as the build system. This has been a complete conversion 
so much of the directory structure has been re-arranged. The work is 
complete and, with a little testing from folks on this list, ready to be 
merged from the 'working-maven' branch back into the trunk. I would 
encourage everyone to check out from the branch and give it a try. There 
is a build.xml file that at this point replicates the main Ant targets 
used by developers pre-conversion, initportal is still all you need to 
run to get everything going after setting up build.properties. Please 
provide feedback, there are bound to be rough spots and missing 
developer features and hearing from developers is how they will be fixed.

One known issue: Ant 1.7 will not work, there is a nasty little bug that 
will be fixed in 1.7.1, for now use Ant 1.6


With this progress and new build system I need to get it properly 
documented and have a place for documentation as this effort moves 
forward. After looking through the wiki and chatting in IRC I have the 
following proposal. All documentation in the uPortal 3 space related to 
the uPortal 3 sandbox code would be consolidated and moved under a 
uP3-Sandbox page then the uPortal 3 space would be used for 
documentation of the goals of this effort and documentation of changes 
as they happen. I'd like to get other thoughts and suggestions as to how 
to deal with the wiki documentation as well.


The next step in the uP3 effort is consolidating the multiple Spring 
configurations in the project and replacing the inner workings of the 
static services with Spring configurations. Also related to this would 
be looking at using a Spring DispatcherServlet as the root servlet for 
uPortal, using Acegi to replace security.properties and similar tasks. 
Along side the documentation effort I'll be detailing these as sub-tasks 
of the root Spring related issue: 
http://www.ja-sig.org/issues/browse/UP-1789 I'll post an update when I 
get these sub-tasks details to look for some help in getting them done.


-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uP3 Progress Report

[Eric Dalquist]

Good points,

The Maven and Spring work are pre-requisites for the larger change which 
is moving to Pluto 1.1 or 2.0 (depending on what is available when). The 
big changes that will be included in a 3.0 release are Maven  for a 
build system, more coherent architecture via Spring and Pluto 1.1 
(possibly 2.0 with 286 support). More specifically the goals outlined at 
the barcamp in June our outlined here: http://www.ja-sig.org/wiki/x/tgFl

One part of this is soliciting ideas from folks familiar with the 
internals of uPortal as to how we want to do that Pluto upgrade. Do we 
keep the concept of the channel adapter and add features to the IChannel 
interface to account for the portlet features that channels don't 
support? Do we change the layout/rendering architecture to support two 
similar but separate concepts of channels and portlets and make them 
equals in the internals of the framework? I don't think this will be an 
easy question to answer but I would very much appreciate as much 
discussion on it as possible.

I hope that helps,
-Eric

Cris J Holdorph wrote:
> I know there was discussion of up3 at the barcamp at the ja-sig 
> conference in June.  Unfortunately, I had a 3.5 hour workshop to 
> deliver during that time so I was unable to participate.
>
> What I don't understand is why the initial effort is being put towards 
> the activities you mention and converting uPortal to Pluto 1.1 (or 
> hopefully pluto 2.0) is not mentioned at all.
>
> JSR 286 was Finalized on August 27, 2007 (that was the date votes 
> closed).  If we release uPortal 3.0 nearly 1 year later in summer 2008 
> without JSR 286 support, I think that will send an unintentional 
> message to Portal consumers/adopters/developers.
>
> So, while I can appreciate the great value in the conversion to Maven, 
> and Spring Web MVC Dispatcher Servlet, I would to know more about how 
> uPortal 3 is going to improve on it's support of Portlets (or even 
> Channels if that was worthwhile).
>
>  Cris J H
>
> Eric Dalquist wrote:
>> There hasn't been much traffic on about the uP3 work since the 
>> conference and hopefully this is the first of many messages resolving 
>> that problem.
>>
>> Work has been happening on converting the trunk of the uPortal 
>> project to use Maven 2 as the build system. This has been a complete 
>> conversion so much of the directory structure has been re-arranged. 
>> The work is complete and, with a little testing from folks on this 
>> list, ready to be merged from the 'working-maven' branch back into 
>> the trunk. I would encourage everyone to check out from the branch 
>> and give it a try. There is a build.xml file that at this point 
>> replicates the main Ant targets used by developers pre-conversion, 
>> initportal is still all you need to run to get everything going after 
>> setting up build.properties. Please provide feedback, there are bound 
>> to be rough spots and missing developer features and hearing from 
>> developers is how they will be fixed.
>>
>> One known issue: Ant 1.7 will not work, there is a nasty little bug 
>> that will be fixed in 1.7.1, for now use Ant 1.6
>>
>>
>> With this progress and new build system I need to get it properly 
>> documented and have a place for documentation as this effort moves 
>> forward. After looking through the wiki and chatting in IRC I have 
>> the following proposal. All documentation in the uPortal 3 space 
>> related to the uPortal 3 sandbox code would be consolidated and moved 
>> under a uP3-Sandbox page then the uPortal 3 space would be used for 
>> documentation of the goals of this effort and documentation of 
>> changes as they happen. I'd like to get other thoughts and 
>> suggestions as to how to deal with the wiki documentation as well.
>>
>>
>> The next step in the uP3 effort is consolidating the multiple Spring 
>> configurations in the project and replacing the inner workings of the 
>> static services with Spring configurations. Also related to this 
>> would be looking at using a Spring DispatcherServlet as the root 
>> servlet for uPortal, using Acegi to replace security.properties and 
>> similar tasks. Along side the documentation effort I'll be detailing 
>> these as sub-tasks of the root Spring related issue: 
>> http://www.ja-sig.org/issues/browse/UP-1789 I'll post an update when 
>> I get these sub-tasks details to look for some help in getting them 
>> done.
>>
>>
>> -Eric
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] uP3 Progress Report

[Eric Dalquist]

Thanks for testing out the branch Colin. I believe I just fixed the 
Windows related build bug so the build scripts should work as expected 
on Windows, *nix & OS X.

As for how to distinguish between the up3-sandbox code and what is 
currently being worked on? I'm not sure either other than the simple 
'move stuff around' approach I outlined in my first email. Any other 
comments/suggestions would be great.

-Eric

Colin Clark wrote:
> Hi Eric,
>
> You've done a lot of work in quite a short amount of time. Having gone 
> through the experience of converting a number of Fluid-related builds 
> to Maven 2, I'm impressed!
>
> Eric Dalquist wrote:
>> Work has been happening on converting the trunk of the uPortal 
>> project to use Maven 2 as the build system. This has been a complete 
>> conversion so much of the directory structure has been re-arranged. 
>> The work is complete and, with a little testing from folks on this 
>> list, ready to be merged from the 'working-maven' branch back into 
>> the trunk. I would encourage everyone to check out from the branch 
>> and give it a try. There is a build.xml file that at this point 
>> replicates the main Ant targets used by developers pre-conversion, 
>> initportal is still all you need to run to get everything going after 
>> setting up build.properties. Please provide feedback, there are bound 
>> to be rough spots and missing developer features and hearing from 
>> developers is how they will be fixed.
>
> We chatted about this in the IRC forum, but I haven't yet been able to 
> get the build to work on my Windows machine. Could be environmental, 
> I'm not sure. Has anyone else on Windows had any trouble getting the 
> new M2 builds to work?
>
>> With this progress and new build system I need to get it properly 
>> documented and have a place for documentation as this effort moves 
>> forward. After looking through the wiki and chatting in IRC I have 
>> the following proposal. All documentation in the uPortal 3 space 
>> related to the uPortal 3 sandbox code would be consolidated and moved 
>> under a uP3-Sandbox page then the uPortal 3 space would be used for 
>> documentation of the goals of this effort and documentation of 
>> changes as they happen. I'd like to get other thoughts and 
>> suggestions as to how to deal with the wiki documentation as well.
>
> I think it makes a lot of sense to distinguish between our new, 
> evolutionary approach to uPortal 3 and the older branch of it, 
> especially in the wiki.
>
> One very minor comment I'd make is that the term "uP3-Sandbox" might 
> not be clear enough for newcomers to the community to recognize the 
> difference between the old "sandbox" version and the current version. 
> Given that the architecture is so different, it's worth making the 
> distinction obvious. On the other hand, I don't have any brilliant 
> naming suggestions. :)
>
> Again, nice work!
>
> Colin
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] where to document the uPortal 3 efforts in the wiki

[Eric Dalquist]

I agree with the idea of renaming the current uPortal 3 (UPT) space to 
Archived Portal Exploration and putting a relevant header on the space 
explaining what the documentation is for in greater detail.

Documenting the current effort in the current uPortal space is good for 
continuity but I'm not quite sure where to put the new documents and how 
to ensure people understand that this is documentation for 
in-development code. The immediate need is that I need to document the 
new Maven build management system and helper Ant tasks but I don't want 
to cause confusion for people looking for help with uPortal 2.6. Is just 
putting a {note} at the top of each page good enough for now?

-Eric




Andrew Petro wrote:
> Jason,
>
> > I almost wonder if we move the pages into an Archive section
> > of the uPortal space, and then delete the uPortal3 space.
>
> -1
>
> I think the most confusing thing we could do would be to put these 
> pages into the uPortal space.  Confluence savvy users may understand 
> that Confluence is a tree and that since the trunk of the tree in 
> which these archived pages inhabit is "Archive" these pages don't 
> actually apply to the uPortal they're trying to work with, but many 
> users will be confused, having done a search in the uPortal space on 
> confluence, to come across pages that have little applicability.
>
> A separate space named "Archived portal exploration" or the like might 
> be better -- maybe the root of your objection, Jason, was to the name 
> "Sandbox" as being insufficiently expressive of something that is frozen.
>
> That separation of space is doing important work for clarity.  One 
> good move might be to slap a header into the theme for that space 
> making it especially clear that what is documented is archived 
> explorations into a better portal, and not necessarily uPortal 
> itself.  That way when users do naive Confluence searches and come 
> across these pages, they are more able to make sense of what they have 
> found.
>
>> On Sep 17, 2007, at 3:49 PM, Andrew Petro wrote:
>>
>>> I wonder if it would be clearer to re-name the entire current 
>>> "uPortal 3" space to something like "uPortal Sandbox"
>>
>> I think this is confusing. I think we need to make it clear that no 
>> more work is going into the codebase, and Sandbox seems ambiguous. I 
>> almost wonder if we move the pages into an Archive section of the 
>> uPortal space, and then delete the uPortal3 space.
>>
>>> And then I wonder whether creating a new uPortal 3 wiki space is a 
>>> good idea, or if the uPortal 3 efforts should be undertaken in the 
>>> existing uPortal wiki space.  The change the project has made in its 
>>> approach to uPortal 3 is to be more evolutionary.  uPortal 3 *is* 
>>> uPortal 2, cleaned up quite a bit and with pointed improvements.  So 
>>> maybe, just as the existing code evolves to become uPortal 3, the 
>>> existing wiki space evolves to become a wiki space that documents 
>>> uPortal, inclusive of uPortal 3.
>>
>> +1 I think they key factor in our new strategy moving forward is that 
>> the New uPortal 3 is uportal -- with a direct lineage to previous 
>> efforts. Given that shift, I don't think a separate wiki space is 
>> really appropriate -- I'd rather see a linear release progression.
>>
>>> Likewise, I don't think it will be necessary to have an entirely new 
>>> uPortal manual, more a matter of growing and enhancing the existing 
>>> uPortal manual wiki space to document the project as it grows and is 
>>> enhanced.
>>
>> +1 again.
>>
>> Jason
>>
>> --
>>
>> Jason Shao
>> Application Developer
>> Rutgers University, Office of Instructional & Research Technology
>> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] 
>>  | http://jay.shao.org
>>
>>
>>
>> -- 
>> 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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] where to document the uPortal 3 efforts in the wiki

[Eric Dalquist]

That is possible. At this point I've renamed the space, added a note 
that appears at the top of all pages and locked the space so that only 
confluence administrators can edit it. 
http://www.ja-sig.org/wiki/display/UP3/Home

Unfortunately there is no way to change the key for the space that I can 
see though I image some sort of export/import is possible to achieve 
that goal?

As for a note on documentation related to the present effort would 
something like the following suffice at the top of each page?

"This documentation is for the uPortal 3 work being done on the trunk of 
the uPortal framework. It does not pertain to uPortal 2.6 or any other 
uPortal 2.X release."

-Eric

[EMAIL PROTECTED] wrote:
> Could we use a different color / theme for UPT? With some kind of dev logo?
> Susan
> -Original Message-
>
> From:  Andrew Petro <[EMAIL PROTECTED]>
> Subj:  Re: [uportal-dev] where to document the uPortal 3 efforts in the wiki
> Date:  Tue Sep 18, 2007 12:18 pm
> Size:  8K
> To:  uportal-dev@lists.ja-sig.org
>
>   Eric,
>  
>  > Is just putting a {note} at the top of each page good enough for now?
>  
>  Yes, I think.
>  
>  While uPortal is gearing up to have this problem of what documentation 
> applies to what versions *more* with the present uP3 efforts, this is not a 
> new problem for uPortal. Cf. the way that the wiki documents PersonDirectory, 
> with pages attempting to explain how it works in the different versions and 
> acknowledging the change over time.
>  
>  Andrew
>  
>  
>I agree with the idea of renaming the current uPortal 3 (UPT) space to 
> Archived Portal Exploration and putting a relevant header on the space 
> explaining what the documentation is for in greater detail.
>  
>  Documenting the current effort in the current uPortal space is good for 
> continuity but I'm not quite sure where to put the new documents and how to 
> ensure people understand that this is documentation for in-development code. 
> The immediate need is that I need to document the new Maven build management 
> system and helper Ant tasks but I don't want to cause confusion for people 
> looking for help with uPortal 2.6. Is just putting a {note} at the top of 
> each page good enough for now?
>  
>  -Eric
>  
>  
>  
>  
>  Andrew Petro wrote:   Jason,
>  
>  > I almost wonder if we move the pages into an Archive section 
>  > of the uPortal space, and then delete the uPortal3 space.
>  
>  -1
>  
>  I think the most confusing thing we could do would be to put these pages 
> into the uPortal space. Confluence savvy users may understand that Confluence 
> is a tree and that since the trunk of the tree in which these archived pages 
> inhabit is "Archive" these pages don't actually apply to the uPortal they're 
> trying to work with, but many users will be confused, having done a search in 
> the uPortal space on confluence, to come across pages that have little 
> applicability.
>  
>  A separate space named "Archived portal exploration" or the like might be 
> better -- maybe the root of your objection, Jason, was to the name "Sandbox" 
> as being insufficiently expressive of something that is frozen.
>  
>  That separation of space is doing important work for clarity. One good move 
> might be to slap a header into the theme for that space making it especially 
> clear that what is documented is archived explorations into a better portal, 
> and not necessarily uPortal itself. That way when users do naive Confluence 
> searches and come across these pages, they are more able to make sense of 
> what they have found.
>  
>On Sep 17, 2007, at 3:49 PM, Andrew Petro wrote:
>   
>I wonder if it would be clearer to re-name the entire current "uPortal 3" 
> space to something like "uPortal Sandbox"
>   
>  
>  I think this is confusing. I think we need to make it clear that no more 
> work is going into the codebase, and Sandbox seems ambiguous. I almost wonder 
> if we move the pages into an Archive section of the uPortal space, and then 
> delete the uPortal3 space.
>   
>  And then I wonder whether creating a new uPortal 3 wiki space is a good 
> idea, or if the uPortal 3 efforts should be undertaken in the existing 
> uPortal wiki space. The change the project has made in its approach to 
> uPortal 3 is to be more evolutionary. uPortal 3 *is* uPortal 2, cleaned up 
> quite a bit and with pointed improvements. So maybe, just as the existing 
> code evolves to become uPortal 3, the existing wiki space evolves to become a 
> wiki space that documents uPortal, inclusive of uPortal 3.  
>  +1 I think they key factor in our new strategy moving forward is that the 
> New uPortal 3 is uportal -- with a direct lineage to previous efforts. Given 
> that shift, I don't think a separate wiki space is really appropriate -- I'd 
> rather see a linear release progression.
>  
>  Likewise, I don't think it will be necessary to have an entirely new uPortal 
> manual, more a matter of growing and enh

[uportal-dev] uPortal & Maven

[Eric Dalquist]

I've completed some documentation of the Mavenized verison of uPortal 
currently in the 'working-maven' branch: 
http://www.ja-sig.org/wiki/display/UPC/Building+and+Deploying+uPortal+3

The build scripts have been tested and work on OS X, Linux, Unix and 
Windows. I would greatly appreciate it if folks could check out the 
updated codebase, take a look at the building and deploying document and 
give it a whirl. My plan is to merge this code back into the trunk on 
Monday so this environment is what we will be moving forward with. 
Please bring up any questions or deficiencies in the documentation, I'll 
be more than happy to address them and ensure there is complete 
documentation.

More documentation will be coming over the next few days, it will all be 
linked from the 
http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Development+Documentation 
page.

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Maven on the trunk

[Eric Dalquist]

I've completed merging the Maven 2 changes back to the trunk. If you are 
interested in living on the bleeding-edge of uPortal (or help with the 
uP3 development) check out the trunk and read the Building And Deploying 
uP3 document on the wiki: 
http://www.ja-sig.org/wiki/display/UPC/Building+and+Deploying+uPortal+3 
If you run into any problems please email the list and I'll make sure 
they get addressed.

The next step is consolidating the Spring configuration in the framework 
and those initial tasks are outlined here: 
http://www.ja-sig.org/issues/browse/UP-1789

-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Maven on the trunk

[Eric Dalquist]

In addition to the building and deploying documentation there is now 
documentation of the new project structure, dependency management and 
configuration file location available: 
http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Project+Structure

Eric Dalquist wrote:
> I've completed merging the Maven 2 changes back to the trunk. If you are 
> interested in living on the bleeding-edge of uPortal (or help with the 
> uP3 development) check out the trunk and read the Building And Deploying 
> uP3 document on the wiki: 
> http://www.ja-sig.org/wiki/display/UPC/Building+and+Deploying+uPortal+3 
> If you run into any problems please email the list and I'll make sure 
> they get addressed.
>
> The next step is consolidating the Spring configuration in the framework 
> and those initial tasks are outlined here: 
> http://www.ja-sig.org/issues/browse/UP-1789
>
> -Eric
>   


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Spring context consolidation

[Eric Dalquist]

I'm starting work on consolidating the Spring configuration files and 
switching to standard ways of loading and accessing the context XML.

My plan is to create a properties/contexts/ folder that all Spring 
context XML files reside in. The context files will be loaded by a 
ContextLoaderListener into a single WebApplicationContext. The 
WebApplicationContext is then accessible via the 
WebApplicationContextUtils class which requires a reference to the 
ServletContext object for loading.

The ContextLoaderListener and WebApplicationContextUtils classes are 
replacing a custom PortalApplicationContextFacade class which loads 
/properties/beanRefFactory.xml and provides static method accessors to 
the loaded BeanFactory.

The problem is in some places that the PortalApplicationContextFacade is 
used to access the BeanFactory there is no access to a ServletContext 
which the WebApplicationContextUtils needs to access the replacement 
WebApplicationContext.
The affected areas are:
CError - constructor, loads a IThrowableToElement implementation which 
defines ways to render certain exceptions
PersonDirectory - getPersonAttributeDao, loads the root 
IPersonAttributeDao for use by other parts of the framework. This method 
is called from: Authentication, PersonAttributeGroupStore, 
CPersonAttributes, and PersonDirNameFinder

I'm not sure what the best solution for this is. I'd like to avoid as 
much custom Spring related code as possible but we may still need a 
static accessor that doesn't require the ServletContext to access the 
WebApplicationContext object.


My one idea right now is to add a custom ServletContextListener that 
listens for start/stop events and holds a static reference to the 
ServletContext and internally uses WebApplicationContextUtils to service 
static request for the WebApplicationContext. This should still deal 
with the Spring context getting reloaded and the Servlet context getting 
reloaded. I would also like to make it deprecated from the get-go to 
discourage usage of this pattern.

-Eric




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] 2.6.1-GA release

[Eric Dalquist]

With the portlet session issue and the resolver issue the 2.6.1-GA got 
put on hold. What needs to happen now is either me or someone else needs 
to apply the portlet session patch to the 2.6-patches branch and cut a 
2.6.1-RC2 wait a week then call a vote for the GA. I'll do my best to 
start that process next week when I get back from the Fluid meeting, 
unless someone else gets to it before me.

-Eric

Brad Johnson wrote:
> Hello All,
>
> How's the 2.6.2 release going? I see UP-1819 was fixed.
>
> thanks,
> Brad Johnson
>
>   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Spring context consolidation

[Eric Dalquist]

Thats a good approach too, I might look into creating a utility bean to 
do that injection that also inject a null when the context is shutting 
down. Making sure the solution works nicely with spring context and 
servlet context reloads which cause problems right now. I'm thinking the 
injecting a null would work with this model to fit the reloads requirement.

-Eric

Drew Wills wrote:
> Eric Dalquist wrote:
>> ...
>>
>> The problem is in some places that the PortalApplicationContextFacade 
>> is used to access the BeanFactory there is no access to a 
>> ServletContext which the WebApplicationContextUtils needs to access 
>> the replacement WebApplicationContext.
>> The affected areas are:
>> CError - constructor, loads a IThrowableToElement implementation 
>> which defines ways to render certain exceptions
>> PersonDirectory - getPersonAttributeDao, loads the root 
>> IPersonAttributeDao for use by other parts of the framework. This 
>> method is called from: Authentication, PersonAttributeGroupStore, 
>> CPersonAttributes, and PersonDirNameFinder
>>
>> I'm not sure what the best solution for this is. I'd like to avoid as 
>> much custom Spring related code as possible but we may still need a 
>> static accessor that doesn't require the ServletContext to access the 
>> WebApplicationContext object.
>
> Eric,
>
> What about an approach like this (example from PersonDirectory)...
>
> *
>
> ++ Java:
>
> public class PersonDirectory {
>
>   private static IPersonAttributeDao impl;
>
>   public static Object setPersonAttributeDao(IPersonAttributeDao dao) {
> impl = dao;
> return PersonDirectory.class;  // shouldn't matter what's returned
>   }
>
>   ...
>
> }
>
> ++ BeansML:
>
> 
>   
> 
>   
> 
>
> *
>
> This should cause the bean container to inject the normal 
> 'personAttributeDao' into the staticly-accessed PersonDirectory 
> service to support legacy code.
>
> drew wills
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Spring context consolidation

[Eric Dalquist]

I ended up following the static locater pattern which is similar to 
Spring's WebApplicationContextUtils class but does not require a 
ServletContext to get at the WebApplicationContext. These changes are in 
SVN so now there is a single loaded WebApplicationContext that follows 
the web-application's life-cycle correctly. All .xml files in the 
properties/contexts/ directory are loaded into the 
WebApplicationContext. With this change reloading the uPortal context 
seems to work correctly which is another step forward.

On to the next task!

-Eric

Eric Dalquist wrote:
> Thats a good approach too, I might look into creating a utility bean to 
> do that injection that also inject a null when the context is shutting 
> down. Making sure the solution works nicely with spring context and 
> servlet context reloads which cause problems right now. I'm thinking the 
> injecting a null would work with this model to fit the reloads requirement.
>
> -Eric
>
> Drew Wills wrote:
>   
>> Eric Dalquist wrote:
>> 
>>> ...
>>>
>>> The problem is in some places that the PortalApplicationContextFacade 
>>> is used to access the BeanFactory there is no access to a 
>>> ServletContext which the WebApplicationContextUtils needs to access 
>>> the replacement WebApplicationContext.
>>> The affected areas are:
>>> CError - constructor, loads a IThrowableToElement implementation 
>>> which defines ways to render certain exceptions
>>> PersonDirectory - getPersonAttributeDao, loads the root 
>>> IPersonAttributeDao for use by other parts of the framework. This 
>>> method is called from: Authentication, PersonAttributeGroupStore, 
>>> CPersonAttributes, and PersonDirNameFinder
>>>
>>> I'm not sure what the best solution for this is. I'd like to avoid as 
>>> much custom Spring related code as possible but we may still need a 
>>> static accessor that doesn't require the ServletContext to access the 
>>> WebApplicationContext object.
>>>   
>> Eric,
>>
>> What about an approach like this (example from PersonDirectory)...
>>
>> *
>>
>> ++ Java:
>>
>> public class PersonDirectory {
>>
>>   private static IPersonAttributeDao impl;
>>
>>   public static Object setPersonAttributeDao(IPersonAttributeDao dao) {
>> impl = dao;
>> return PersonDirectory.class;  // shouldn't matter what's returned
>>   }
>>
>>   ...
>>
>> }
>>
>> ++ BeansML:
>>
>> 
>>   
>> 
>>   
>> 
>>
>> *
>>
>> This should cause the bean container to inject the normal 
>> 'personAttributeDao' into the staticly-accessed PersonDirectory 
>> service to support legacy code.
>>
>> drew wills
>>
>> 


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Deprecated code removal (IMultithreaded*)

[Eric Dalquist]

With the basic Spring re-org done the next task on the block is 
reviewing and removing deprecated code from the framework. There is a 
Jira issue http://www.ja-sig.org/issues/browse/UP-1832 of course and you 
can peak at the Fisheye tab to see what has been done so far.

One large set of files that is deprecated is everything related to 
multithreaded channels. I would like to get opinions of people on if 
this code should be out-right removed for a uPortal 3.0 release or is it 
ok to remain in the codebase but be deprecated?

Thank you,
-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Spring context consolidation

[Eric Dalquist]

In the default checkout all of the tools still works. What your email 
made me think of is doing chanpub work with PAGs configured since PAGs 
will need PersonDirectory which is configured in the application 
context. I'll give that a try later this week and see what solutions 
other applications have used for this problem.

As more bits of the framework get moved into a Spring context this 
problem starts to go away since any command line tool will need to 
bootstrap the application context to access the instance of the tool to run.

Can you think of other tools/configurations that should get a more 
in-depth look to make sure they work ok?

-Eric

Susan Bramhall wrote:
> Will we still run certain "tools" outside the web context?  If so, 
> will this approach handle that scenario too?  For example importing 
> and exporting objects, initializing the database.
> Susan
>
> Eric Dalquist wrote:
>> I ended up following the static locater pattern which is similar to 
>> Spring's WebApplicationContextUtils class but does not require a 
>> ServletContext to get at the WebApplicationContext. These changes are 
>> in SVN so now there is a single loaded WebApplicationContext that 
>> follows the web-application's life-cycle correctly. All .xml files in 
>> the properties/contexts/ directory are loaded into the 
>> WebApplicationContext. With this change reloading the uPortal context 
>> seems to work correctly which is another step forward.
>>
>> On to the next task!
>>
>> -Eric
>>
>> Eric Dalquist wrote:
>>  
>>> Thats a good approach too, I might look into creating a utility bean 
>>> to do that injection that also inject a null when the context is 
>>> shutting down. Making sure the solution works nicely with spring 
>>> context and servlet context reloads which cause problems right now. 
>>> I'm thinking the injecting a null would work with this model to fit 
>>> the reloads requirement.
>>>
>>> -Eric
>>>
>>> Drew Wills wrote:
>>>  
>>>> Eric Dalquist wrote:
>>>>  
>>>>> ...
>>>>>
>>>>> The problem is in some places that the 
>>>>> PortalApplicationContextFacade is used to access the BeanFactory 
>>>>> there is no access to a ServletContext which the 
>>>>> WebApplicationContextUtils needs to access the replacement 
>>>>> WebApplicationContext.
>>>>> The affected areas are:
>>>>> CError - constructor, loads a IThrowableToElement implementation 
>>>>> which defines ways to render certain exceptions
>>>>> PersonDirectory - getPersonAttributeDao, loads the root 
>>>>> IPersonAttributeDao for use by other parts of the framework. This 
>>>>> method is called from: Authentication, PersonAttributeGroupStore, 
>>>>> CPersonAttributes, and PersonDirNameFinder
>>>>>
>>>>> I'm not sure what the best solution for this is. I'd like to avoid 
>>>>> as much custom Spring related code as possible but we may still 
>>>>> need a static accessor that doesn't require the ServletContext to 
>>>>> access the WebApplicationContext object.
>>>>>   
>>>> Eric,
>>>>
>>>> What about an approach like this (example from PersonDirectory)...
>>>>
>>>> *
>>>>
>>>> ++ Java:
>>>>
>>>> public class PersonDirectory {
>>>>
>>>>   private static IPersonAttributeDao impl;
>>>>
>>>>   public static Object setPersonAttributeDao(IPersonAttributeDao 
>>>> dao) {
>>>> impl = dao;
>>>> return PersonDirectory.class;  // shouldn't matter what's returned
>>>>   }
>>>>
>>>>   ...
>>>>
>>>> }
>>>>
>>>> ++ BeansML:
>>>>
>>>> >>> factory-method="setPersonAttributeDao">
>>>>   
>>>> 
>>>>   
>>>> 
>>>>
>>>> *
>>>>
>>>> This should cause the bean container to inject the normal 
>>>> 'personAttributeDao' into the staticly-accessed PersonDirectory 
>>>> service to support legacy code.
>>>>
>>>> drew wills
>>>>
>>>>   
>


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] ALM support project

[Eric Dalquist]

In the code cleanup effort outlined for the uP3 community roadmap I've 
been removing chunks of deprecated code where prudent and doing other 
minor tweaking. Some that was talked about in-depth at the conference 
but not as much on this list is what to do with the ALM code. The plan I 
had worked out with several folks was to pull the ALM/integrated modes 
code out into a sandboxed project in SVN.

The goal of this is that we do not want new installs using ALM and we 
don't have plans to continue to maintain that code. That said moving the 
code into the sandbox allows someone else to step up at a later date and 
apply ALM patches and actually use the code in uPortal 3. The sandboxed 
project is designed to be an overlay of the uPortal 3 code, if there is 
interest in actually making sure that overlay is functional as we move 
forward I'm sure we could tweak the Maven build for the ALM project to 
automate that processes.

These changes have already been made but it doesn't me they can't be 
rolled back or have a different strategy taken.

-Eric

ALM Move: http://www.ja-sig.org/issues/browse/UP-1835
Code Cleanup: http://www.ja-sig.org/issues/browse/UP-1832


smime.p7s
Description: S/MIME Cryptographic Signature