[WG: Sakai QA] [QA Admins] qa1-za rebuilt - problems

Berg, A.M. A.M.Berg at uva.nl
Mon Dec 14 10:03:29 PST 2009

Hi Matthew,

I like your summary. I think the risk is that each fix requires too much effort for an immediate fix and the fixes keep being put off. The virtual stop impacts on long term quality. For example the Java 1.6 full compatability by 2.8. When is 2.8 anyway or is tha equivalent to > /dev/null ? I also suspect that there is a large queue of bite sized Jira's also needed to be cleared by the maintenance team. The maintenance team should correct me if I am wrong, but the load would have to be shared more evenly in the community.


Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam


-----Original Message-----
From: jonespm at gmail.com on behalf of Matthew Jones
Sent: Mon 12/14/2009 18:25
To: Jean-Francois Leveque
Cc: Berg, A.M.; sakai-qa; qa-admins at collab.sakaiproject.org
Subject: Re: [WG: Sakai QA] [QA Admins] qa1-za rebuilt - problems
I don't believe this (allowArraySyntax) was an issue that was going to be
fixed for 2.6. We were just going to go with the workaround for now.

I was thinking about it this morning and there are a number of reoccurring
issues that keep coming up on the mailing lists and discussions. These would
be good tasks for a maintenance team because they cross multiple project
boundaries and would some time to fix and test. They also have undetermined
amounts of work (time) involved, typically have current workarounds, or are
not critical issues, but are bothersome.

Here is a summary of the 5 that I keep thinking of. These are not ranked in
any priority or estimates of work involved:
1) Running Sakai under java 1.6. *

Sakai currently requires the option tomcat option
"-Dsun.lang.ClassLoader.allowArraySyntax=true" when running under java 1.6.

This was captured on the mailing list many times
on multiple jiras [2]
SAK-16745 <http://bugs.sakaiproject.org/browse/SAK-16745> [3]
SAK-15874<http://bugs.sakaiproject.org/browse/SAK-15874> [4]
SAK-17578 <http://bugs.sakaiproject.org/browse/SAK-17578>.
Stephen Marquard commented on SAK-17578:
"I think the above are all JSF dependencies (certain T&Q and Chat). Given
the potential impact of upgrading JSF versions (especially for T&Q), I think
this is inappropriate for 2.7 and should target 2.8. "

The more specific line from the sun bug report is at

"It is purely accidental that array syntax ever worked. There was never any
design intent for it to succeed and we haven't seen any scenario where it
makes sense though we've recieved many reports of cases where users have
come to expect it to succeed." - Bug 6500212
More discussion on the fix is on the this link.

The current recommended plan that I've heard on the release calls is that
we'll just document the workaround flag for people using java 1.6 and
attempt to fix it for 2.8.
2) Running Sakai under Tomcat versions greater than 5.5.27*

Sakai currently requires the tomcat option
"-Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false" when
running under any tomcat greater than 5.5.27. This is documented in the
install guide [6].<http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Source+Install+%282.6%29>It
is related to a change in jsp quote enforcement
[7] <https://issues.apache.org/bugzilla/show_bug.cgi?id=45015>. There is a
regular expression attacted to the [7] issue that can be used to search for
this problem in code. There are jiras related to this at [8] SAK-15736
<http://jira.sakaiproject.org/browse/SAK-15736> and [9]
SAK-17425.<http://jira.sakaiproject.org/browse/SAK-17425>I remember
this being immediately visible on osp tools, and appears to be
fixed in 2.7 based on the jiras, but I haven't verified (or heard of
verification) running with the option off. There may be other tools that
needed the option and it is currently in the demo build for 2.7.
*3) Upgrade James (mail server) to a newer version*

Sakai is currently running James 2.1.3 in the mailarchive. The currently
(and recommended) release is 2.3.2. There are a number of security and
performance improvements that have been made over the years since we've
changed versions of this. We have some jira's tracking local problems, some
that have been around for many years [10]
[11] SAK-17156 <http://bugs.sakaiproject.org/browse/SAK-17156> I don't know
how this was originally packaged and made available. It would be good to get
this brought up to date.

*4) Upgrade jquery in the portal to a newer version*

Sakai uses an old jquery 1.1.4. There are a number of jiras, current one
marked unresolved [12]
SAK-16960<http://jira.sakaiproject.org/browse/SAK-16960>that ask for
this. This has also been mentioned a few times on the mailing
lists [13]<http://collab.sakaiproject.org/pipermail/sakai-dev/2009-July/002449.html>.
At Michigan we have some new user interface ideas for site-manage and realms
that we'd like to work out (for 2.8) that will require a newer versions of
jquery. I believe my post on this thread at
good suggestions for migration that we would look toward. "Every time
that I notice that the Portal is using jQuery 1.1.4, I* *cringe*. " - **Eli
5) Getting either TinyMCE or CKEditor in as a replacement for fckeditor*

Sakai currently uses fckeditor, which is no longer supported. It's obvious
successor CKEditor has a slightly different plugin system and has different
layout and functionality. however it might be worth switching to TinyMCE..
Much of this is for accessibility issues [15]
SAK-11783<http://jira.sakaiproject.org/browse/SAK-11783>which both of
the newer 2 editors claim to fix, as well as pasting from word
problems, which persist. Sakai 3 is also currently using TinyMCE.
editors are switchable via property, so a new editor should be easy to
drop in, however plugins would need to be written for the resources and
citations viewer, and the button layout(s) would need to be decided upon.

There are other issues (minor or harder?) that float around such as:
- Replacing html/text processing with some external service (KNL-66). Our
homebrew attempts have problems. I would do a drop-in replacement on the
entire processor with something like OWASP

- Various enhancements for rwiki (admin SAK-5496, wysiwyg SAK-8535 and
- Enhancing the properties system, and possibly extending the configuration
editor project so the admin section can be improved.
. . .

[2] http://jira.sakaiproject.org/browse/SAK-16745
[3] http://bugs.sakaiproject.org/browse/SAK-15874
[4] http://bugs.sakaiproject.org/browse/SAK-17578
[5] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212
[7] https://issues.apache.org/bugzilla/show_bug.cgi?id=45015
[8] http://jira.sakaiproject.org/browse/SAK-15736
[9] http://jira.sakaiproject.org/browse/SAK-17425
[10] http://bugs.sakaiproject.org/browse/SAK-5761
[11] http://bugs.sakaiproject.org/browse/SAK-17156
[12] http://jira.sakaiproject.org/browse/SAK-16960
[15] http://jira.sakaiproject.org/browse/SAK-11783

On Mon, Dec 14, 2009 at 8:30 AM, Jean-Francois Leveque <
jean-francois.leveque at upmc.fr> wrote:

> Hi Alan and all,
> Does this mean the maintenance team will work on this between M2 and M3?
> J-F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20091214/c7b0714f/attachment.html 

More information about the sakai-qa mailing list