It still seems like a simple issue to me.
Split your initialization of A into A1 and A2.
A2 is no longer part of immediate initialization for A.
Put your Scheduler launches, with their Data retrieve components, into
A2.
When A is started, it will only run A1.
When B is started, at the end of it's
ServletContextListener.contextinitialized(...),
it makes a call into A which causes A to run A2. Then when your
retrieval
components call into B, it is ready for them.
--Ken
On Dec 10, 2009, at 11:14 AM, Scot Hatt wrote:
That is valid point but in my case I have no control over A.
So I was hoping this was a commonly seen issue but I guess not so I
will
expand.
Context A contains a scheduling component that starts up a bunch of
data
retrieval components that go out and grab data with the first time
being
during said startup. So A calls Scheduler which then calls DR1,
DR2 ...
until they all finish, then A is deployed. I know, this is not good
but
workload currently foregoes refactoring.
Order of ops:
- "http://localhost:8080/A"; starts up
- Scheduler launches
- Data retrieval component 1 fires
- Data retrieval component 2 fires
- ...
- Data retrieval component n fires and calls
"http://localhost:8080/B/servlet/HereIsData";
- /A dies
Does this make more sense?
-Scot
-----Original Message-----
From: Ken Bowen [mailto:kbo...@als.com]
Sent: Thursday, December 10, 2009 10:47 AM
To: Tomcat Users List
Subject: Re: Context Chicken & Egg Problem
If I understand you correctly, your problem is that B needs to be
initialized before A.
(I don't understand what running locally as to do with it. ??)
If that is correct, why can't you organize the initialization of A
into a trivial initial segment,
and a more substantive final segment, which contains the call to B.
When A starts,
only the trivial initial segment runs. Then use an Application
Context Listener in B,
and at the end of contextInitialized(...), make a call into A which
runs the final A segment
(which contains the call to B).
--Ken
On Dec 10, 2009, at 10:32 AM, Scot Hatt wrote:
Thank you for the response.
I understand the limitation I am up against and it is not a
production level
issue that I have to get around. I have a local VM, as I stated,
that solves
the issue and as far as production, everything is separate.
I was curious if there is a specific reference on this problem that
I can
point to for my fellow devs that try to run everything on a single
Tomcat
instance.
-Scot
-----Original Message-----
From: Pid [mailto:p...@pidster.com]
Sent: Thursday, December 10, 2009 10:22 AM
To: users@tomcat.apache.org
Subject: Re: Context Chicken & Egg Problem
On 10/12/2009 15:15, Scot Hatt wrote:
Hello,
I have spent a great deal of time scouring the bug list and trying
to put
together the right set of terms to find resolution for this but
have been
unsuccessful.
I am dealing with a situation where webapp A is calling a servlet in
webapp
B during A's startup. I think I am dealing with a chicken and egg
situation
where Tomcat knows it has a B context but it can't provide access
yet
because it is still deploying A. The symptom is a complete halt of
A and
Tomcat just sits there not responding to any requests.
The reason for this configuration is the typical developer
workstation
situation where I need to run everything locally. It is not a show
stopper
and I have gotten around it by running a VM but that is a memory
hog. Is
there a reference to this scenario that explains why it is not
possible or
am I dealing with a known bug?
-Scot in VA
Web apps are intended to be independent. The startup sequence for
contexts is sequential AFAIK, but the order isn't specific or
specifiable.
You have have to consider an alternative method of achieving what
you want.
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
