!build
(view Open Liberty Personal Build - ❌ completed with errors/failures.)
spawn.fullfat.buckets=com.ibm.ws.webserver.plugin.utility_fat

Note: Target locations of links might be accessible only to IBM employees.

Code analysis and actions

• 1 product code files were changed.
• Please describe in a separate comment how you tested your changes.

I encounter failures when I change private PluginInfo[] plugins variable to non-static.

A clue as to why this variable needs to be static is how the merge tool is used, via a singleton-ish pattern:

PluginMergeToolImpl toolInstance = new PluginMergeToolImpl(); within the merge(String argv[]) method. After toolInstance is created, plugins = new PluginInfo[fileList.length]; is made.

Another place to look at is where plugins = new PluginInfo[files.length - 1]; was initialized. Before it was in the loadData method, but now it's within merge method.

This plugins object would then be accessible by toolInstance since it's static. If it's not static, then you'll hit NPEs (Caused by: java.lang.NullPointerException: Cannot read the array length because "this.plugins" is null).

I have a branch here with some local changes for testing: https://github.com/volosied/open-liberty/tree/TS018131209-vlad

The 789a331 commit has all tests passing while the c9fc73d commit has only the testEndpointTest3 test failing.

I made a new commit to the PR. I reverted a lot of the static variables to instance state instead of resetting the state as a work around. When I say reverted I mean compared to what it was prior to PR #24627. There is only one variable that was left static sharedPlugins. If I modified it to non-static it would cause problems in one of the tests in com.ibm.ws.webserver.plugin.utility_fat, so had the potential to regress. But if I leave it as static it still causes problems for the customer’s issue because I would still get cached data. In order to get around this I had to add sharedPlugins = new ArrayList<PluginInfo>(); at the beginning of the merge function. Please take a look when you can and let me know if you want me to modify anything else.

@pnicolucci I made the requested code changes and cleaned up the commit you mentioned. In terms of the test do you recommend I add it to the testbucket com.ibm.ws.webserver.plugin.runtime_fat in closed liberty or creating a new one? It seems this test bucket already covers some test for pluginUtility cluster generate so wonder if I just add to it.

I did have a discussion with Eric this morning regarding the code changes and he seemed ok with them. I went ahead and created a testFix for the customer.

@pnicolucci I made the requested code changes and cleaned up the commit you mentioned. In terms of the test do you recommend I add it to the testbucket com.ibm.ws.webserver.plugin.runtime_fat in closed liberty or creating a new one? It seems this test bucket already covers some test for pluginUtility cluster generate so wonder if I just add to it.

If we have an existing bucket where it makes sense to add these tests then I have no objection to using that existing FAT project. Let me know if you have any other questions.

@pnicolucci as requested, I have added a cached plugin-cfg.xml regeneration test in https://github.ibm.com/websphere/WS-CD-Open/pull/34255

@pnicolucci The customer came back saying the testFix worked for them. Is there any remaining items that are necessary for the approval of this PR or can it be approved?

!build (view Open Liberty Personal Build - ❌ completed with errors/failures.)

Note: Target locations of links might be accessible only to IBM employees.

Code analysis and actions

• 1 product code files were changed.
• Please describe in a separate comment how you tested your changes.

!build (view Open Liberty Personal Build - ❌ completed with errors/failures.)

Note: Target locations of links might be accessible only to IBM employees.

Code analysis and actions

• 1 product code files were changed.
• Please describe in a separate comment how you tested your changes.

!build (view Open Liberty Personal Build - ❌ completed with errors/failures.)

Note: Target locations of links might be accessible only to IBM employees.

Code analysis and actions

• 1 product code files were changed.
• Please describe in a separate comment how you tested your changes.