On Thu, Dec 5, 2013 at 10:57 AM, Mark Thomas <ma...@apache.org> wrote:
> On 05/12/2013 14:22, Rossen Stoyanchev wrote: > > On Thu, Dec 5, 2013 at 7:05 AM, Mark Thomas <ma...@apache.org> wrote: > > > >> > >> There is also the programmatic interface to WebSockets so once there is > >> a way to disable the SCI, you can use the programmatic interface to set > >> everything up. > > > > > > Yes, the very existence of a programmatic interface alternative more or > > less implies there should be a way to disable the SCI and still be able > to > > use WebSocket. Is it not possible to use an <absolute-ordering> element > in > > web.xml? > > That provides a way to exclude JARs from scanning (which should be most > of the problem) but not classes. Okay, I wasn't aware of that. It would have been useful to somehow exclude the WAR itself too, so it's all one mechanism. > > I was under the impression that's the mechanism for applications > > to control which web fragments to include or exclude. My understanding > from > > the EG discussions was that SCI was chosen precisely because it is an > > existing mechanism that is understood, so I don't understand the reason > why > > a new mechanism is needed to control SCI scanning. > > I think there is still a use for being able to disable container > provided SCIs on a per context basis outside of what is available in the > spec. That said, if no-one agrees with me then I have plenty of other > things to be working on. > I agree there should be a way to disable container provided SCI. My surprise was that there isn't already a way to do that.
