Management bean MEJB (JSR-77) incompletely removed at payara 6 causing list("java:global") failure / FISH-7709

[Blavo]

Brief Summary

Management bean MEJB (JSR-77) was to be removed at JEE 9. It is still partially present in payara 6 (JEE 10) and its (partial) presence causes naming context list() calls against java:global to fail. Specifically the MEJB jar (mejb.jar) has been removed from /glassfish/lib/install/applications at payara 6 but the bean is still listed in the java:global naming context. list() calls against that context fail because of the MEJB entry and lookup() calls against the MEJB context entry also fail (with a FileNotFoundException) because of the removal of the JAR.

Expected Outcome

list() calls against java:global should either fail with a NonSerializableException against another naming proxy (because of the problem reported in #6330) or should return with the list of sub contexts of java:global (as per contract).

lookup() calls against the MEJB bean should fail with a name not found exception.

Current Outcome

list() calls against naming context java:global fail with a NonSerializableException naming org.glassfish.kernel.jakartaee.MEJBNamingObjectProxy (see #6330) as the result of the unremoved MEJB context entry.

The MEJB context entry should not be present for two reasons:

• the JAR, containing the MEJB management bean, that is referenced by the MEJB context entry was removed from payara 6; so there is no need for the entry
• the entry points nowhere; lookup() of the MEJB context entry (java:global/mejb/MEJBBean!org.glassfish.admin.mejb.MEJBHome) returns a FileNotFoundException naming the location (<payara 6 install root>/glassfish/lib/install/applications/mejb.jar), in earlier payara versions, of the JAR containing the MEJB class

The code that adds the MEJB entry to the java:global context should be removed. (list() calls against java:global will still fail, but for a different reason - see #6330).

There is a work around: code that wishes to do a list() of java:global can, in payara 6, safely do a destroySubcontext() against the java:global/mejb sub context without loss of functionality (since there isn't any). However the destroySubcontext() call needs to be made conditional on the presence of the sub context, since the destroySubcontext() call itself will fail if the sub context has been removed by an earlier call and the java:global context has not been reinitialised (by restarting the server that created it). (The subsequent list() call against java:global will still fail, but not because of MEJB - see #6330)

Reproducer

Compile the attached reproducer with the JARs nominated in the comments in the library set.

Run the compiled reproducer in an environment in which there a payara 6 (6.2023.6) instance running and from which the mejb sub context of java:global has not been removed.

Restart the instance between runs of the reproducer as the error changes if this is not done.

PayaraMEJBStillPresentReproducer.txt

Operating System

MacOS 12.4 (Monterey)

JDK Version

java version "17.0.7" 2023-04-18 LTS Java(TM) SE Runtime Environment (build 17.0.7+8-LTS-224) Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing)

Payara Distribution

Payara Server Full Profile

[Elifzeynepedman]

Greetings @Blavo,

I have escalated this to the platform development team as FISH-7709.

Thank you,
Elif

[Blavo]

G’day, There are a couple of possible outcomes here as this issue masks another. The obvious thing for the development team to do is to complete the removal of MEJB. This will ‘fix’ this issue in the sense that MEJB won’t cause failure of the list() call any more. However the list() call will almost certainly then fail on attempted serialisation of a different naming proxy (see Expected Outcome above) assuming there is a remote EJB in the server. You can test this if you are so minded by adding a destroySubContext(“java:global/mejb”) call into the reproducer, ahead of the list() call. This will remove MEJB from the context, prevent it interfering with the list() call, and show you what will happen when the development team remove MEJB. Effectively removing MEJB will turn this issue into #6330.

…

On 7 Aug 2023, at 22:11, Elifzeynepedman ***@***.***> wrote: Greetings @Blavo <https://github.com/Blavo>, I have escalated this to the platform development team as FISH-7709. Thank you, Elif — Reply to this email directly, view it on GitHub <#6333 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKL4EM7U7LLXDBY772PP63XUDLQJANCNFSM6AAAAAA2DHKZKQ>. You are receiving this because you were mentioned.

[Elifzeynepedman]

Hi @Blavo,

Many thanks for your input, I will inform the platform development team with your findings.

Best Regards,
Elif