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

          dblevins created issue -
          dblevins made changes -
          Field Original Value New Value
          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/MDB relationship, see the blog post [EJB.next Connector/Bean API : JAX-RS and beyond
          |http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html] for explanation and this github project, [MDB Improvements: Telnet Connector|https://github.com/dblevins/mdb-improvements] for an actual functioning connector.

          h1. 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.

          h2. 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.

          h1. Modernized MDB Examples

          Some of the possibilities this would open up:

          {code}
          @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!
              }
          }
          {code}

          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:

          {code}
          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();
              }
          }
          {code}
          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/MDB relationship, see the blog post [EJB.next Connector and Bean API: JAX-RS and beyond
          |http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html] for explanation and this github project, [MDB Improvements: Telnet Connector|https://github.com/dblevins/mdb-improvements] for an actual functioning connector.

          h1. 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.

          h2. 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.

          h2. Modernized MDB Examples

          Some of the possibilities this would open up:

          {code}
          @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!
              }
          }
          {code}

          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:

          {code}
          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();
              }
          }
          {code}
          dblevins made changes -
          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/MDB relationship, see the blog post [EJB.next Connector and Bean API: JAX-RS and beyond
          |http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html] for explanation and this github project, [MDB Improvements: Telnet Connector|https://github.com/dblevins/mdb-improvements] for an actual functioning connector.

          h1. 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.

          h2. 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.

          h2. Modernized MDB Examples

          Some of the possibilities this would open up:

          {code}
          @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!
              }
          }
          {code}

          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:

          {code}
          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();
              }
          }
          {code}
          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|http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html] for explanation and this github project, [MDB Improvements: Telnet Connector|https://github.com/dblevins/mdb-improvements] for an actual functioning connector.

          h1. 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.

          h2. 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.

          h2. Modernized MDB Examples

          Some of the possibilities this would open up:

          {code}
          @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!
              }
          }
          {code}

          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:

          {code}
          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();
              }
          }
          {code}
          marina vatkina made changes -
          Fix Version/s Future version [ 15771 ]
          Affects Version/s 3.2 [ 14833 ]
          marina vatkina made changes -
          Fix Version/s 3.2 [ 14833 ]
          Fix Version/s Future version [ 15771 ]
          marina vatkina made changes -
          Assignee marina vatkina [ mvatkina ]
          marina vatkina made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          John D. Ament made changes -
          Link This issue blocks JMS_SPEC-100 [ JMS_SPEC-100 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: