tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Steffan <>
Subject Re: Bug with contextInitialized using otherServletContext.getContext ?
Date Wed, 17 Nov 2004 09:23:22 GMT
Hallo Remy,

Remy Maucherat wrote:
> Andreas Steffan wrote:
>> Hallo Remy,
>> Remy Maucherat wrote:
>>>> What do you think ?
>>> Your event is sent at the end of the initialization of a context. 
>>> Your other context might not exist yet. This is not a bug.
>> Even though one might interpret the spec a little diffrent here
> There's nothing to interpret here, as the specification cannot specify 
> this. The only way to have this work is allow specifying startup order 
> for your applications, and Tomcat doesn't allow this (JBoss does, OTOH) 
> - nobody asked for that kind of feature.
> What the specification could eventually do is mandate that containers 
> provide a mechanism to specify startup order, but that's it.

I'm sorry for bothering you, but Vignette has a diffrent point of view
on this:

quoting a Vignette employee:


I want to comment on your thought that "we rely on a bug" to start up
portlet applications. This is very much not true. I think you may have
misinterpreted what the tomcat-dev developers where telling you on the
list. You were very much unclear in the explanation of the problem. To
revisit the issue, we get the contextInitialized event from an
application and store the contextPath in a registry. When the portal
initializes it reads from the registry trying to get the ServletContext
for each app that provided a contextInitialized event. The registry is
not persistent. It will not get a contextPath unless it has received and
event from a starting context. As you can see, ordering of app startup
is not an issue. The application is started, but portal is unable to do
a getContext for that path. This is a tomcat bug, no doubt about it. I
suggest you go back to the list (I am unable to comment in a public
forum) and explain the issue correctly before claiming this.

To be honest, it does not change my positition that the portal relies
on non spec compliant behaviour of a container to get things working.
According to what you've said, I would call this non spec compliant
behaviour a bug in the portal.

Would you please be so kind and make a final statement here ?
thank you

Andreas Steffan

T: +49.40.80 81 69-634
F: +49.40.80 81 69-808

SinnerSchrader Neue Informatik	
 >> Software. Design. Interfaces.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message