Bug 110613 - Both BaseServlet & BaseFilter run Startup#run causing the same session to be configured
Both BaseServlet & BaseFilter run Startup#run causing the same session to be ...
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Richard Li
Jon Orris
Depends On:
Blocks: 106481
  Show dependency treegraph
Reported: 2003-11-21 13:43 EST by Daniel Berrange
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-26 16:40:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Logs from startup sequence (25.14 KB, text/plain)
2004-01-07 12:53 EST, Daniel Berrange
no flags Details

  None (edit)
Description Daniel Berrange 2003-11-21 13:43:35 EST
Description of problem:
In static {} blocks of BaseServlet and BaseFilter, there is the
following code:

        if (!SessionManager.hasSession("default")) {
            new Startup().run();

The 'hasSession' method looks in the Map returned by getSessions(),
however. This entries in this map are created when SessionManager#open
is invoked. Unfortuntely, the Startup#run method only ever invokes
SessionManager#configure so the map is never populated.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run
        if (!SessionManager.hasSession("default")) {
            new Startup().run();
        if (!SessionManager.hasSession("default")) {
            new Startup().run();

Yes, twice in a row.

Actual results:
java.lang.ExceptionInInitializerError: java.lang.IllegalArgumentException:
already configured: startup
	at com.arsdigita.runtime.Startup.session(Startup.java:179)
	at com.arsdigita.runtime.Startup.addRuntimeInitializers(Startup.java:123)
	at com.arsdigita.runtime.Startup.run(Startup.java:226)
	at com.arsdigita.web.BaseFilter.<clinit>(BaseFilter.java:57)
	at java.lang.Class.newInstance0(Native Method)
	at java.lang.Class.newInstance(Class.java(Compiled Code))
	at com.caucho.server.http.Invocation.service(Invocation.java:313)
	at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:246)
	at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
	at java.lang.Thread.run(Thread.java:513)

Expected results:

The second call to Startup#run is never done, since SessionManager
already has the default session configured.

Additional info:
Comment 1 Daniel Berrange 2003-11-27 13:32:51 EST
I've had to temporarily disable the 'static' initializer in BaseFilter
(p4 38355) untill this is resolve, since it is blocking successful
Comment 2 Vadim Nasardinov 2003-12-09 15:50:51 EST
Note for Jon if/when he gets around to testing this:

BaseFilter has zero (0) afferent dependencies in Core+CMS.
See bug 99096, comment #3.
Comment 3 Daniel Berrange 2003-12-10 04:54:03 EST
BaseFilter is used by PS code. Its purpose is similar to BaseServlet,
in that it ensures that persistence session is initialized before the
body of the filter is run.
Comment 4 Richard Li 2004-01-06 13:55:48 EST
fixed @39141
Comment 5 Daniel Berrange 2004-01-07 12:53:23 EST
This has broken the CCM load command. The problem is that 's_hasRun'
is set at the end of the run method, however, one of the initializers
for CMS causes ContentItem class to be loaded, which in turn loads the
BaseServlet classs, which in turn checks the s_hasRun attribute -
which is still false & so it calls run again - recursively.

This is trivally fixed by moving 's_hasRun = true' to the start of the
Comment 6 Daniel Berrange 2004-01-07 12:53:40 EST
Created attachment 96808 [details]
Logs from startup sequence
Comment 7 Richard Li 2004-01-08 11:47:05 EST
Ah, fixed @39202.

Note You need to log in before you can comment on or make changes to this bug.