Community
Participate
Working Groups
Created attachment 80689 [details] exception The NullPointerException was logged in the error log during the execution of the Java EE smoke test scenario on WTP 2.0.2: http://wiki.eclipse.org/J2EE_Smoke_Test_%28WTP_2.0%29 Unfortunately, I cannot say when exactly the error was logged. I guess, it was on the step where I run the servlet or jsp on the server. I used JBoss v4.2 a server. The NPE happened only once and I haven't noticed any negative effect of it.
Yup, I think this is a known (dup) issue when the New Server wizard appears. AFAIK exception does not cause runtime problem.
*** Bug 210281 has been marked as a duplicate of this bug. ***
The NPE seems to be fixed in the latest 2.0.2 and 3.0 M5 drivers that I have just smoketested. Have you done any code changes, related to this?
Not fixed. We just hit this while testing 2.0.2 RC1? Any chance of a fix for 2.0.2?
When a server is created ServerWorkingCopy is initialized with a runtime if hasRuntime() returns true. Generic server assumes that there will always be a runtime. When a server is created through NewRuntimeComposite it conforms to the expected behavior. But there is a second path for Server creation ServerCreationCache and when a server is created through that ServerWorkingCopy is never initialized with its runtime and this is causing the NPE in some cases. Tim can you comment is there really a case where a server can be created without a runtime(if it requires one), or is this simply a mistake?
Found it. In this case it is creating the server first, then creating and setting the runtime and calling setDefaults() again. I can probably get the runtime created first and then create the server, but since I can't also create and import a configuration if it's needed, there's always going to be a case where something is set after the call to create() and setDefaults() needs to be called again. In short - I can improve this case, but setDefaults() should also handle cases where the server isn't complete yet, or where the runtime or configuration was invalid, etc. I think we should both fix this.
I am trying to improve it as well, as generic servers do not support configuration that will not be a problem. But the defaults depend on the runtime type.
I have just released a change that should create the runtime first, so it is set the first time setDefaults() is called. It'll still be called twice, but it should avoid the NPE. Gorkem - This change alone should fix it, but just putting in a null check would have worked (or will provide double protection) too.
*** Bug 217353 has been marked as a duplicate of this bug. ***
I am adding the null check that is easy but the impact can be quite large. GenericServer.getServerDefinition() is used throughout the generic server plugins and it is one of the basic APIs. Until now It was assumed that GenericServer can always determine the associated .serverdef file and therefore the API was assumed to always return a value. The lack of runtime of course makes creates the situation where GenericServer.getServerDefinition() can return null. The ideal is now to go over all the places where the API is used and try to adjust for this new behavior. Do you think it is safe to assume that only when called from setDefaults() runtime can be null.
Yes... except that of course any user could inadvertently delete their runtime, check a server out of source control without one, etc. We don't need to address it in this bug, but to be fully robust we should assume that anything could be invalid and handle nulls appropriately, where 'appropriate' might still be to throw an exception or log the problem.
I have made changes to detect the null and fall back. Released to the HEAD.
This is still a valid bug in 2.0.2 RC3. It seems that it is fixed only in the 3.0 stream. Was the intention to fix it in 2.0.2, too? If yes, then we should reopen the bug. Otherwise, retarget it to 3.0.
Re-opening, since it is unclear whether this fix was ever integrated into 2.0.2?
*** Bug 223498 has been marked as a duplicate of this bug. ***
My changes are in 3.0 stream only., Tim, If your changes will not go to 2.0.2 I will retarget this for 3.0.
My changes were in 3.0 stream only as well, so changing target to 3.0. Unless I'm missing something, there should be no need to backport either change to the 2.0 stream since this is just an unnecessary .log message that's been there since <2.0.
Closing bugs that have been fixed for several months without owner verification. Bugs that did not involve external user/adopter scenarios have been verified in WTP. We are about to release WTP 3.0, please feel free to reopen if you have any further problems.
New Gerrit change created: https://git.eclipse.org/r/108521
New Gerrit change created: https://git.eclipse.org/r/108536
