Community
Participate
Working Groups
I'm not sure I have the right component, but this is my best guess. The symptom is that the "agent selection" dialog doesn't appear when starting servers, such as Tomcat, in profile mode if the server already exists when the Eclipse session is started. Here are the steps to reproduce (I used Eclipse 3.2.2, WTP 1.5.3 and tptp.sdk-TPTP-4.3.1-200702191217.zip on WinXP): 1. Create a Tomcat runtime (I used Tomcat 5.5.20) 2. Create a Tomcat server for the runtime. 3. Double-click the server in the Servers view to open server editor. 4. In server editor, click Open launch configuration 5. Select the Environment tab and add a PATH environment variable that points to the org.eclipse.hyades.execution plug-in directory for the OS in use (I used ...\plugins\org.eclipse.hyades.execution.win32.x86_4.3.0.v200611140100) 6. Exit the launch configuration dialog 7. Start the server in profiling mode and no dialog appears to ask for agent, etc. If you delete the server and repeat the above from step 2 without restarting Eclipse, the dialog will appear. If you restart Eclipse, it stops appearing for this existing server. The problem occurs due to changes for Bug 172382 that appear in WTP 1.5.3. The ApplicationServerListener now gets called at the beginning of ServerCore initialization such that the ServerCore.getServers() call in the startup() method will return a zero length array. As a result, the listener is not added to existing servers. For fun, I modified startup() to enclose the existing code in a Job and scheduled it. This seems to delay execution of this code to a time when ServerCore.getServers() will successfully return the existing servers.
Unfortunately, this probably needs to be fixed in TPTP. Here's some background: * The server startup extension point is called during the initialization of the server core framework - the first time someone tries to use server API, not server plugin startup(). * In this case it is trying to get access to the servers while that API is loading. Since there is no ordering on the extension point, it is ambiguous whether any servers have been loaded or will be created by the other extensions. * The worst bit is that this behaviour can cause plugin loading deadlock if anyone triggers this code path from within their plugin's startup(). For this reason we were forced to fix bug 172382 and block out this behaviour. The easiest fix is to put the code into a Job so that it doesn't touch the API while in the startup method.
Maybe I spoke too soon - I just took a look at the fix in 2.0, and it did go too far avoiding deadlock on bad API usage and caused valid calls to fail as well. However, I've started looking through 1.5.3 and I don't see the same problem yet. I'll keep looking tomorrow, but I don't see a path where getServers() could return before ResourceManager loadRuntimesList() and loadServersList() are called.
I tried this myself (with my own sample, not TPTP), and I could not reproduce - getServers() returned the correct list. I'll grab TPTP and try again. Larry - were you able to determine the codepath that caused this? I couldn't find a path in 1.5.3 where ResourceManager could be initialized without the server and runtimes list getting loaded.
Created attachment 59503 [details] Stacktrace for breakpoint at getServers() call in ApplicationServerListener
Ok, that's screwy. The startup is being called during plugin startup and initialization when other servers aren't loaded yet, so the result of getServers() is correct. However, since it is in the middle of startup it'll fail to get events when the existing servers are loaded. We should fix this in WTP 1.5.4 so that it is impossible to get the startup launched during this period, or so that the events at least get fired.
Should we still recommend that ApplicationServerListener use a Job so it will work with WTP 1.5.3? It's a rather noticable regression for those using WTP 1.5.3.
Based on comments, I'm targeting to 1.5.4. Please re-target if I am incorrect.
David - Yes, that's correct. I could have sworn there was no 1.5.4 target when I moved the bug last. ;) Larry - AFAIK all other Eclipse projects stopped their Eclipse 3.2 service streams after 3.2.2 a couple weeks ago. WTP is starting to plan a 1.5.4 so I can fix this, but I'm not aware of any TPTP service planned on this stream. Eugene - Does TPTP still have a service release on this stream, so that you could also switch to using a Job?
(In reply to comment #8) Tim, there is no plan of TPTP on any more service release in the 3.2.2 stream as I know. TPTP has just got its 4.3.1 and 4.2.1.1 out which is built on 3.2.2 stream.
Ok, we'll fix in WTP as soon as 1.5.4 builds start.
Just a note that a similar problem exists in WTP 2.0 as well. The InitializeJob calls getServers(), which indirectly calls ResourceManager.executeStartups(), which indirectly calls getServers() recursively via ApplicationServerListener.startup(). Currently a NPE gets thrown because executeStartups() is called before the ResourceManager.servers field is initialized. Tim, let me know if you would like a separate bug for tracking WTP 2.0 changes.
The 2.0 problem should already be fixed in M6 via bug 174886.
Yep, that's what I saw using WTP 2.0M5. Thanks.
Created attachment 60405 [details] Patch for startup initialization
Raising for PMC approval for 1.5.4 since this is a regression in behaviour that breaks TPTP. Patch attached - Larry (or Eugene), any chance you can try it as well? I believe the safest fix is just to initialize the resource manager first (which will load existing servers before calling the startups), which is equivalent to the behaviour in 1.5.2 or 2.0.
Unfortunately, this doesn't help. :( Per the attached stacktrace, ApplicationServerListener.startup() is being executed within the context of initializing the ResourceManager. The added getResourceManager() call simply returns the already set, but still initializing, instance.
-1 Given Larry's comment or test, I'm assuming this one needs more work and needs to be resubmitted? (Thanks Larry).
Sorry, I didn't take a close enough look at the stack trace. I'll submit a new patch soon, and in the meantime I'll retract from PMC voting.
Created attachment 61612 [details] Patch for startup initialization 2 Second patch, replaces the first.
Corrected patch ready, raising for PMC approval again.
+1 And looking forward to Larry's technical assessment/test :)
I've tested the second patch and it works for me too. The patch reorders the execution of things so that ApplicationServerListener sees the existing servers. The startup for the wst.server.ui plug-in is still a bit "heavy", but it's probably not practical to address that in WTP 1.5.4.
*** Bug 176180 has been marked as a duplicate of this bug. ***
+1 Assumes adequate testing to ensure no regressions occur as a result of this fix.
Patch released to 1.5.4.
Verified that the "agent selection" dialog now appears for existing Tomcat servers using wtp-sdk-M-1.5.4-200704012359.zip.
Closing as verified.
