tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rossen Stoyanchev <rstoyanc...@gopivotal.com>
Subject Re: Severe 7.0.47 startup performance regression
Date Thu, 05 Dec 2013 16:48:29 GMT
On Thu, Dec 5, 2013 at 10:57 AM, Mark Thomas <markt@apache.org> wrote:

> On 05/12/2013 14:22, Rossen Stoyanchev wrote:
> > On Thu, Dec 5, 2013 at 7:05 AM, Mark Thomas <markt@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message