Announcement Announcement Module
Collapse
No announcement yet.
Error: Is AbstractJmsChannel an abstract class or not? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error: Is AbstractJmsChannel an abstract class or not?

    Hello

    I am doing a deeper analysis for the SI 2.1.1 API and I did realize the follow for the AbstractJmsChannel's API
    Where appear

    Code:
    public class AbstractJmsChannel extends AbstractMessageChannel
    If it is really an abstract class then should be

    Code:
    public abstract class AbstractJmsChannel extends AbstractMessageChannel
    If It is a bug (seems yes) let me know to create a JIRA issue

    Kind Regards

  • #2
    Yeah, this seems like leftover after refactoring. I would not call it a bug, since most likely it was left intentionally since changing class name would constitute a breking change and we try not to introduce breaking changes until the next major release.

    Comment


    • #3
      Oleg, do you have the diff handy that shows that refactoring? I don't think we ever made a change where the abstract base class was intended to be used as a concrete channel. In fact, I'm guessing that we never had the abstract keyword on this class, and that as Amol pointed out, it should be there.

      Comment


      • #4
        The last change I see is:

        commit 55d9366c4b42a2a2f8724f8ed4debc3cb17e0200
        Author: Mark Fisher <. . @. .com> 2010-09-23 04:49:39
        Committer: Mark Fisher <. . @. .com> 2010-09-23 04:49:39
        . . .

        And yes you are correct it seems to have always had "Abstract" in its name but was never 'abstract' class. So that's a bug, but I am wondering if we are stuck with it till 3.x since it would be a breaking change.

        Comment


        • #5
          It would only be a breaking change if someone is using AbstractJmsChannel directly as a concrete class, and I doubt that's the case. Our two JMS-based channels created by parsers definitely do not.

          Therefore, I'd say it's a case where bugginess outweighs any breaking change. I think we should target 2.2. It's basically harmless (just wrong), so it's probably okay to *not* backport this one to 2.1.

          Agree?
          -Mark

          Comment


          • #6
            Yep.

            Manuel, you can raise a JIRA

            Comment


            • #7
              Hello Oley and Mark

              Oleg:

              Manuel, you can raise a JIRA
              Done: https://jira.springsource.org/browse/INT-2540

              Mark:

              I think we should target 2.2. It's basically harmless (just wrong), so it's probably okay to *not* backport this one to 2.1.
              Is possible know when SI 2.2 would be available?

              I did realize SI 2.1 has support about AMQP within (MessageChannel) where I think It was not available in SI 2.0, my point is, I dont want in a good sense spend some time researching with SI 2.1 and later have strong changes about the API for 2.2.

              Kind Regards

              Comment

              Working...
              X