Strange ejb-jar.xml env-entry behavior with simple MDB

[Will Hartung]

I have a simple MDB:

@MessageDriven(mappedName = "jms/TestQueue", activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class NewMessageBean implements MessageListener {
    
    @Resource(name = "testProperty")
    String prop;
    
    public NewMessageBean() {
    }
    
    @Override
    public void onMessage(Message message) {
        TextMessage tm = (TextMessage) message;
        try {
            System.out.println("MDB says " + tm.getText() + " - " + prop);
        } catch (JMSException ex) {
            Logger.getLogger(NewMessageBean.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
    
}

jms/TestQueue exists in the server, and it's Physical Destination Name is TestQueue.

I have the following ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee"
         version = "3.1"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
         metadata-complete="false">
    <enterprise-beans>
        <message-driven>
            <ejb-name>NewMessageBean</ejb-name>
            <env-entry>
                <env-entry-name>testProperty</env-entry-name>
                <env-entry-type>java.lang.String</env-entry-type>
                <env-entry-value>property value</env-entry-value>
            </env-entry>
        </message-driven>
    </enterprise-beans>
</ejb-jar>

If I comment out the @Resource, and remove the ejb-jar.xml, the MDB works just fine.

If I add in the ejb-jar.xml, and the @Resource, an odd thing happens.

Specifically, my jms/TestQueue Physical Destination Name is changed to "PhysicalQueue". At this point, the MDB "fails" as it's no longer listening to the proper queue. The JMS server, indeed, has a "PhysicalQueue".

The @Resource at this point is a red herring since the MDB is not being invoked (since I'm posting to the wrong queue).

I have the "metadata-complete" set to false, though that should be the default anyway. It doesn't seem right that the ejb-jar.xml should be stomping on the destination configured in the server.

This is Payara Server 5.192 #badassfish (build 115).

Regards,

Will Hartung

[Rudy De Busscher]

Hi,

When you define the annotation and the EJB-JAR file, 2 different instances will be created.  So the proper way in your case, is to define the Message Driven bean entirely in the ejb.jar file and and don't use the @MessageDriven.

When setting "metadata-complete" to true, the annotations are ignored for the entire application.

Hopes this helps

Best regards

Rudy

[Will Hartung]

On Mon, Feb 1, 2021 at 11:31 AM Rudy De Busscher <rdebu...@gmail.com> wrote:

Hi,

When you define the annotation and the EJB-JAR file, 2 different instances will be created.  So the proper way in your case, is to define the Message Driven bean entirely in the ejb.jar file and and don't use the @MessageDriven.

When setting "metadata-complete" to true, the annotations are ignored for the entire application.

Hopes this helps

But the point of the "metadata-complete" being false is to specify that the ejb-jar.xml data is MERGED with the annotations, rather than stomping on them entirely. The hierarchy for meta-data is container-ejb-jar.xml overrides ejb-jar.xml which can override the annotations. But you should be allowed to incrementally update information, rather than have to completely respecify it each time.

"If metadata-complete is not specified or is set to "false", the deployment tool must examine the class files of the application for annotations, as specified by the specifications."

This works correctly in Payara 4, and Glassfish 5. It fails in Glassfish 6 (for a different reason).

Thank you for the response, however.

Regards,

Will Hartung

[Rudy De Busscher]

Hi Will,

There is some ambiguity around "metadata-complete" false in the specification. As you can see on https://download.oracle.com/javaee-archive/ejb-spec.java.net/users/att-0792/metadata-complete-ejb there is no mention of what needs to be happening when 'the same' EJB definition is found and how it can be determined if it is the same or another EJB based on what is in <ejb-name>. 

If the logic changed between Payara 4 and 5, please open a Github issue https://github.com/payara/Payara/issues, attach a reproducer and describe the different behaviour in Payara 4 and 5.

Best Regards

Rudy

[Will Hartung]

On Mon, Feb 1, 2021 at 11:04 PM Rudy De Busscher <rdebu...@gmail.com> wrote:

Hi Will,

There is some ambiguity around "metadata-complete" false in the specification. As you can see on https://download.oracle.com/javaee-archive/ejb-spec.java.net/users/att-0792/metadata-complete-ejb there is no mention of what needs to be happening when 'the same' EJB definition is found and how it can be determined if it is the same or another EJB based on what is in <ejb-name>. 

Yes, I've read this.

And I see your point about how the ejb-jar and the annotated class can be viewed as creating two EJBs. You can have an ejb-jar.xml and a simple POJO, and turn it in to an EJB. Similarly you can create several EJBs from the same class file with enough different ejb-jar entries.

But it's also clear that the ejb-jar.xml is meant to augment or override the annotations in the class. The spec clearly says that the annotations should be processed along with the XML file. The question becomes how does one discriminate between the creation of a new EJB, and the supplementation of an existing one.

Muddy waters indeed. But this has to be a common use case. I don't see the XML descriptor and the annotations as exclusive to each other, and there are a myriad of routine reasons, even today, to use an XML file to update the metadata of an EJB. Minimally to match resource descriptors and what not. It seems to me that the EJB name and class uniquely identify an EJB in a scope, and both are required within the ejb-jar descriptor. This should be enough to discern whether a new EJB is to be created.

One of the issues specifically in this case is that in an MDB, you're able to specify everything about the MDB, much of which is normally deferred to the container. Typically you define the connection factory and destination in the server configuration, and then refer to them in the MDB.

But the MDB can specify all of those properties within itself. It seems to me in this case, it's defaulting the physical queue name, to PhysicalQueue, at some point during the XML ejb-jar processing. Since it's not specified at all in the annotations, or the ejb-jar. The container then proceeds to create the destination on the fly, stomping on the one that is there already. I mean, that's just a guess.

I appreciate how the ejb meta data can be complicated to process.

 

If the logic changed between Payara 4 and 5, please open a Github issue https://github.com/payara/Payara/issues, attach a reproducer and describe the different behaviour in Payara 4 and 5.

I'll file an issue. Thanks.

Regards,

Will Hartung

[Will Hartung]

Well, as I was preparing my project for the issue submission, I stumbled upon a sun-resources.xml that was recreating the Queue with a name PhysicalQueue. This likely got snuck in by the IDE. Once I removed that file, it worked as expected.

Thanks!

Regards,

Will Hartung

[Eduard Drenth]

Which IDE?

--
You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/CAKMEDdxV-bThd%3DaAK45WYnUELUD5enEtqeF_eCzmxS%3D8OPg6aQ%40mail.gmail.com.

[Will Hartung]

On Wed, Feb 3, 2021 at 6:12 AM Eduard Drenth <eduard...@gmail.com> wrote:

Which IDE?

Netbeans. It's always done stuff like that. It's a feature.

Mind, what's odd is that it DID work under Payara 4, which decided to NOT process the sun-resources.xml (or, since the destination already existed, it simply skipped it).

It also worked under GF5.

Regards,

Will Hartung