DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32453>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32453
------- Additional Comments From markt@apache.org 2004-12-02 00:02 -------
In summary, this is what I see happening:
1. The deployer adds the TestServlet2 context in StandardHostDeployer.addChild
()
2. StandardHost(ContainerBase).addChildInternal() starts the child (the
context) and then adds the child to StandardHost(ContainerBase).children once
it has started.
3. Starting the context calls the context listener(s) for the context. As part
of the context listener for TestServlet2, a cross-context call to getContext
("/TestServlet2") is made from the context for TestServlet1. Because this is
cross-context, a call is made to StandardHost.map() to determine the context.
This requires the context for TestServlet2 to exist in StandardHost
(ContainerBase).children.
And here we have the problem. When the call is made to StandardHost.map(), the
TestServlet2 context hasn't been added to StandardHost(ContainerBase).children
so it fails.
The spec requires that contentInitialized() is called once the context is
ready to process requests but the context can't actually serve any requests
until it is added to StandardHost(ContainerBase).children because until this
happens no request can be mapped to the context. The call to the context
listener is being made too soon.
I haven't given any thought about what (if anything) can be done to fix this.
Any ideas anyone? If we can identify a solution, I am happy to spend the time
implementing it.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
|