Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: 3.2
    • Labels:
      None

      Description

      The thesis is to eliminate the Connector-specfic JavaBean which is currently the heart of the MDB/Connector model. The @ActivationConfigProperty is just a reflection of that Connector JavaBean.

      There are several disadvantages to the JavaBean approach and current Connector style:

      • Metadata is loosely typed in the bean code
      • Only class-level metadata is allowed, not method-level
      • Requiring an interface can limit API expressiveness

      For those that aren't intimately familiar with the Connector and MDB relationship, see the blog post EJB.next Connector and Bean API for explanation and this github project, MDB Improvements: Telnet Connector for an actual functioning connector.

      The core proposal

      The short version of the proposal is as follows:

      • Allow the ResourceAdapter to obtain the bean class through the ActivationSpec
      • Allow the ResourceAdapter to obtain a no-interface view of the bean

      This can be done with text and no new API classes or signatures are required. The contract would be simple.

      • The Connector Provider can request the MDB implementation class (ejb class) via the ActivationSpec
      • If the ActivationSpec has an 'ejbClass' property the MDB Container would be required to:
        • set a reference to the ejb class of the MDB when creating the ActivationSpec instance
        • return a no-interface view of the MDB from the MessageEndpointFactory.createEndpoint method

      Of course the "no-interface" view would still implement MessageEndpoint and the message listener interface.

      Optional no-interface MDB contract

      Instead of requiring Connectors to supply a regular interface such as 'public interface Foo' as the <messagelistener-type>, allow the Connector to supply a an annotation such as public @interface Foo as the message listener interface. The MDB use that on the bean class.

      Modernized MDB Examples

      Some of the possibilities this would open up:

      @MessageDriven
      @EmailAccountInfo(address = "dblevins@apache.org")
      public class EmailBean {
      
          @PostConstruct
          public void init() {
          }
      
          @Deliver @Header("Subject: {subject}")
          public void receiveEmail(@HeaderParam("subject") String subject, @Body String body) {
              // do your thing!
          }
      }
      

      EmailAccountInfo, Header, Deliver, HeaderParam, and Body are all annotations supplied by the Connector demonstrating the "JAX-RS" like APIs that could be written and standardly used via custom connector. The APIs themselves could of course become standard, but that would not be necessary – the connector itself could be run in any compliant server.

      Another example of an MDB that accepts commands issued in a telnet console:

      package org.developer.application;
      
      import com.superconnectors.telnet.api.Command;
      import com.superconnectors.telnet.api.Option;
      import com.superconnectors.telnet.api.TelnetListener;
      
      import javax.ejb.ActivationConfigProperty;
      import javax.ejb.MessageDriven;
      import java.text.SimpleDateFormat;
      import java.util.Date;
      import java.util.Map;
      import java.util.Properties;
      import java.util.regex.Pattern;
      
      @MessageDriven
      @TelnetListener
      public class MyMdb {
      
          private final Properties properties = new Properties();
      
          @Command("get")
          public String doGet(@Option("key") String key) {
              return properties.getProperty(key);
          }
      
          @Command("set")
          public String doSet(@Option("key") String key, @Option("value") String value) {
      
              final Object old = properties.setProperty(key, value);
              final StringBuilder sb = new StringBuilder();
              sb.append("set ").append(key).append(" to ").append(value);
              sb.append("\n");
              if (old != null) {
                  sb.append("old value: ").append(old);
                  sb.append("\n");
              }
              return sb.toString();
          }
      
          @Command("list")
          public String doList(@Option("pattern") Pattern pattern) {
      
              if (pattern == null) pattern = Pattern.compile(".*");
              final StringBuilder sb = new StringBuilder();
              for (Map.Entry<Object, Object> entry : properties.entrySet()) {
                  final String key = entry.getKey().toString();
                  if (pattern.matcher(key).matches()) {
                      sb.append(key).append(" = ").append(entry.getValue()).append("\n");
                  }
              }
              return sb.toString();
          }
      }
      

        Issue Links

          Activity

          Hide
          marina vatkina added a comment -

          David,

          Will it be the EJB or the JCA container responsible for parsing the Connector defined annotations?

          Show
          marina vatkina added a comment - David, Will it be the EJB or the JCA container responsible for parsing the Connector defined annotations?
          Hide
          marina vatkina added a comment -
          Show
          marina vatkina added a comment - The latest proposal: https://github.com/dblevins/mdb-improvements
          Hide
          Darious3 added a comment -

          +100 for this proposal.

          JCA and the EJB interaction has been a black art technology for so long now. The overwhelming majority of Java EE/EJB books doesn't even mention the topic. A big shame, since with the changes proposed by David we could turn this into a technology people other than some vendor programmers actually use.

          Show
          Darious3 added a comment - +100 for this proposal. JCA and the EJB interaction has been a black art technology for so long now. The overwhelming majority of Java EE/EJB books doesn't even mention the topic. A big shame, since with the changes proposed by David we could turn this into a technology people other than some vendor programmers actually use.
          Hide
          marina vatkina added a comment -

          Which proposal are you voting for? The original proposal is not possible without major changes to the JCA spec, which will have only an MR update in EE 7.

          Show
          marina vatkina added a comment - Which proposal are you voting for? The original proposal is not possible without major changes to the JCA spec, which will have only an MR update in EE 7.
          Hide
          Darious3 added a comment -

          Sorry, what are the two proposals you are referring to exactly?

          Do you mean the choice between the core proposal and the optional contract? If that's the case both actually, but of course at least the core proposal ("Allow the ResourceAdapter to obtain the bean class through the ActivationSpec").

          Show
          Darious3 added a comment - Sorry, what are the two proposals you are referring to exactly? Do you mean the choice between the core proposal and the optional contract? If that's the case both actually, but of course at least the core proposal ("Allow the ResourceAdapter to obtain the bean class through the ActivationSpec").
          Hide
          marina vatkina added a comment -

          The 1st proposal is in the description on the top of this RFE. That one requires major changes in the JCA spec.

          The latest version is here: https://github.com/dblevins/mdb-improvements and while still a substantial change, requires less changes in the corresponding specs.

          Show
          marina vatkina added a comment - The 1st proposal is in the description on the top of this RFE. That one requires major changes in the JCA spec. The latest version is here: https://github.com/dblevins/mdb-improvements and while still a substantial change, requires less changes in the corresponding specs.
          Hide
          Carlo de Wolf added a comment -

          The latest proposal eliminates all usage of activation config. For the administrative role it is essential that configuration items are externalized somehow. This would not be left to the whim of a resource adapter developer.

          For example an admin might wish to override to port number used, which is coded into the MDB.

          @Port(2020)
          

          https://github.com/dblevins/mdb-improvements/blob/ed714ecc1daa03ad4302647b068a9cf344438aec/mdb-tomorrow/src/main/java/org/developer/application/MyMdb.java#L33

          But the activation spec might not have any means of reading external config, just the annotation itself.

          final Port port = (Port) beanClass.getAnnotation(Port.class);
          

          https://github.com/dblevins/mdb-improvements/blob/ed714ecc1daa03ad4302647b068a9cf344438aec/mdb-tomorrow/src/main/java/com/superconnectors/telnet/adapter/TelnetActivationSpec.java#L71

          To really ensure this feature is fully usable it must contain means for an administrator to intervene on such configuration items.

          Show
          Carlo de Wolf added a comment - The latest proposal eliminates all usage of activation config. For the administrative role it is essential that configuration items are externalized somehow. This would not be left to the whim of a resource adapter developer. For example an admin might wish to override to port number used, which is coded into the MDB. @Port(2020) https://github.com/dblevins/mdb-improvements/blob/ed714ecc1daa03ad4302647b068a9cf344438aec/mdb-tomorrow/src/main/java/org/developer/application/MyMdb.java#L33 But the activation spec might not have any means of reading external config, just the annotation itself. final Port port = (Port) beanClass.getAnnotation(Port.class); https://github.com/dblevins/mdb-improvements/blob/ed714ecc1daa03ad4302647b068a9cf344438aec/mdb-tomorrow/src/main/java/com/superconnectors/telnet/adapter/TelnetActivationSpec.java#L71 To really ensure this feature is fully usable it must contain means for an administrator to intervene on such configuration items.
          Hide
          marina vatkina added a comment -

          Deferring...

          Show
          marina vatkina added a comment - Deferring...
          Hide
          dblevins added a comment -

          Seems like there was opposition to this that wasn't coming forward. Raised that discussion publicly here so people can follow:

          http://java.net/projects/connector-spec/lists/users/archive/2013-02/message/4

          Show
          dblevins added a comment - Seems like there was opposition to this that wasn't coming forward. Raised that discussion publicly here so people can follow: http://java.net/projects/connector-spec/lists/users/archive/2013-02/message/4
          Hide
          arjan tijms added a comment -

          It would be a shame to delay this even further if there's the opportunity to include it now. As is mentioned above, the contract between the MDB and RA has been too inflexible in the past and as a result not a lot of people have been using this.

          So, if this contract can be made more flexible, please do so, and please don't let it wait for another x years

          Show
          arjan tijms added a comment - It would be a shame to delay this even further if there's the opportunity to include it now. As is mentioned above, the contract between the MDB and RA has been too inflexible in the past and as a result not a lot of people have been using this. So, if this contract can be made more flexible, please do so, and please don't let it wait for another x years
          Hide
          Piotr Nowicki added a comment -

          Definitely +1 from me.

          From what I can observe in companies: the connection between MDB, JCA, RA is still treated like a black-magic.
          It's like you feel the power but you're a bit too constrained to use it, therefore, every chance to make it more flexible is definitely worth the price!

          If we would need to wait for it like 3 or 6 months that would be fine but postponing it and waiting next 4 years or so is just too much.

          So, once again - bit fat +1!

          Show
          Piotr Nowicki added a comment - Definitely +1 from me. From what I can observe in companies: the connection between MDB, JCA, RA is still treated like a black-magic. It's like you feel the power but you're a bit too constrained to use it, therefore, every chance to make it more flexible is definitely worth the price! If we would need to wait for it like 3 or 6 months that would be fine but postponing it and waiting next 4 years or so is just too much. So, once again - bit fat +1!
          Hide
          ljnelson added a comment -

          Please please please get this in sooner rather than later!

          Show
          ljnelson added a comment - Please please please get this in sooner rather than later!
          Hide
          marina vatkina added a comment -

          If we are to add it to the EJB 3.2, would it be an option to require an activation-config property "beanClass" be specified for the MDB that exposes its no-interface view? We can make it optional in the next version of the spec.

          Show
          marina vatkina added a comment - If we are to add it to the EJB 3.2, would it be an option to require an activation-config property "beanClass" be specified for the MDB that exposes its no-interface view? We can make it optional in the next version of the spec.
          Hide
          marina vatkina added a comment -

          We are discussing the options...

          Show
          marina vatkina added a comment - We are discussing the options...
          Show
          marina vatkina added a comment - See http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/2
          Hide
          rherschke added a comment -

          For me the inbound ra spec and mdb binding should be reworked soon. Davids proposals as mentioned in the beginning of this issue is a huge step forward to get JCA on the mainstream again.

          I understand, that these changes will have a large impact and thatswhy I can go with Bill's compromise for now. The getEndpointClass() is at least a good idea to let the RA's developer parse the metadata by itself and do the right thing.

          Also an empty Message Listener Interface to tag those classes is fine for EE 7.

          Nonetheless, I definetely prefere to see the whole improvement package in EE 8 besides some changes for outbound connectors too (e.g. get rid of those "GenericManagedConnection/Factory" classes by having some declarative "ManagedConnection" annotations for the real connection impls).

          So +1 for Bill's compromise, but also +100 for the next steps in David's proposals.

          (as well as +999 for a complete JCA rework allthough this is the wrong place to vote for that)

          Regards,
          Robert

          Show
          rherschke added a comment - For me the inbound ra spec and mdb binding should be reworked soon. Davids proposals as mentioned in the beginning of this issue is a huge step forward to get JCA on the mainstream again. I understand, that these changes will have a large impact and thatswhy I can go with Bill's compromise for now. The getEndpointClass() is at least a good idea to let the RA's developer parse the metadata by itself and do the right thing. Also an empty Message Listener Interface to tag those classes is fine for EE 7. Nonetheless, I definetely prefere to see the whole improvement package in EE 8 besides some changes for outbound connectors too (e.g. get rid of those "GenericManagedConnection/Factory" classes by having some declarative "ManagedConnection" annotations for the real connection impls). So +1 for Bill's compromise, but also +100 for the next steps in David's proposals. (as well as +999 for a complete JCA rework allthough this is the wrong place to vote for that) Regards, Robert
          Hide
          marina vatkina added a comment -

          And the simplified version with a marker message-listener interface is in!

          David, please create another issue for using annotations directly and mark it for the future version.

          Show
          marina vatkina added a comment - And the simplified version with a marker message-listener interface is in! David, please create another issue for using annotations directly and mark it for the future version.

            People

            • Assignee:
              marina vatkina
              Reporter:
              dblevins
            • Votes:
              25 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: