[Building Sakai] SAK-17578, et al.

[Jon Gorrono]

OK, thanks, Matt.

STRICT_QUOTE_ESCAPING may be more intense to test, but the
classloading issue should be relatively simple to test for
regressions.... I can't think of a reason to suspect that some classes
would be found under the static method and others not.... so, a few
traversals of the code should suffice, don't you think?  Anyway, I'll
move it forward a little with that assumption, since I brought it
up.... are all the projects above controlled by the maint team or do
we have to contact 'missing persons' for some of them? :)

On Tue, Feb 12, 2013 at 7:36 PM, Matthew Jones <matthew at longsight.com> wrote:
> The option -Dorg.apache.jasper.compiler.Parser.STRICT_WHITESPACE=false was
> cleaned up (SAK-21265) however Sakai still requires
>
> -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false (SAK-17938)
> and
> -Dsun.lang.ClassLoader.allowArraySyntax=true (SAK-17578)
>
> The amount of work to Fix AND QA in every tool where this was an issue
> (including the high profile contrib tools) was seen as too much effort for
> how simple the workaround was. Especially considering most of those tools
> are in maintenance mode as is with lots of other outstanding issues, and the
> workflow for QA isn't may not be obvious (regression possibility otherwise).
>
> The only downside to this workaround is knowing to use it (it's well
> documented) and the possibility that they might remove the workarounds
> entirely someday. (Probably more of a concern for the sun.lang option, since
> the other is trivial code)
>
> If you (or someone else) really wanted to create patches and verifiable test
> plans we'd for sure take them (since they work with and without the option),
> but I from what I remember that STRICT_QUOTE_ESCAPING was worse and still be
> required, and I'd still worry about my instance breaking in production on a
> contrib tool.
>
>
> On Tue, Feb 12, 2013 at 9:55 PM, Jon Gorrono <jpgorrono at ucdavis.edu> wrote:
>>
>> Maintenance team:
>>
>> I just ran across this and am curious... most the attention
>> surrounding these issues was on JSF, but there are other places in the
>> code for which this issue should still surface: still requiring the
>> use of the property setting
>>
>> -Dsun.lang.ClassLoader.allowArraySyntax=true
>>
>> .... if I understand what I am reading correctly.. the 'official' word
>> seems to be that these cases should be eliminated:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4976356
>> http://bugs.sun.com/view_bug.do?bug_id=6500212
>>
>>
>> It looks like most of the places where array syntax is used to
>> reflectively search for classes have been removed... but are the
>> projects where it appears to remain in trunk versions.
>>
>>
>> kernel
>> mailarchive
>> reflectutils
>> rsf
>> rwiki
>> search
>>
>> (see attached: the result of "grep -r 'loadClass\s*(' *|grep -v .svn")
>>
>> The fix seems (and in typical cases, is) trivial.... but if it helps I
>> can create the patches.... if you can tell me who should get them
>>
>> --
>> Jon Gorrono
>> PGP Key: 0x5434509D -
>> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
>> http{middleware.ucdavis.edu}
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>
>



--
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}