On 16/09/2013 17:37, Nick Williams wrote: > On Sep 16, 2013, at 11:21 AM, Mark Thomas wrote:
>> It certainly looks at this point as if the order is "anything you like". >> Personally, I'd prefer something rather more deterministic. > > Agreed. That's why I filed [1]. I've added a comment on some additional complications and a proposal. > My understanding based on our previous conversations is that Tomcat > *currently* orders SCIs according to the web-fragment ordering. Looking > back on those conversations, what's not clear to me now is: > > 1) How does Tomcat *currently* order the groups of SCIs? Container > before application or application before container? I *think* the answer > is always application before container. It is. > 2) Does web-fragment ordering *currently* affect whether container SCIs > come before application or vice versa? I *think* the answer is it does not. It did. I'm not sure either after the recent(ish) refactoring. > It would be great if any > existing JCP members could bring [1] to their attention and maybe get > some people together for a discussion. Based on previous experience of how the Servlet EG works the only opinion that matters is what the EG lead decides and until that decision is in writing... Tomcat doesn't have the information it needs to correctly order the SCIs at the moment, regardless of what ordering scheme is eventually chosen. On reflection, I can see the need to at least partially address this issue prior to the EG making a final decision. Therefore I intend to do the following: 1. Refactoring 8.0.x and 7.0.x to make the information available to enable various ordering schemes to be implemented. 2. Ensure that application provided SCIs are still executed in web fragment order. (Up to this point this work should result in no functional changes unless other refactorings have introduced unintended changes) 3. Change the current order to execute container provided SCIs first. Implementing point 3 should address the immediate issue without generating too much nugatory work if the EG opts for a completely different scheme. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
