Qpid
  1. Qpid
  2. QPID-2818

Make Transport mechanisms into OSGi plugins

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Later
    • Affects Version/s: None
    • Fix Version/s: JIRA Cleanup
    • Component/s: Java Broker, Java Client
    • Labels:
      None

      Description

      Make the transport mechanism pluggable using OSGi on both the broker and the client

        Activity

        Hide
        Robbie Gemmell added a comment -

        Closing issue out as part of JIRA cleanup. Issue may already be resolved, may be invalid, or may never be fixed. See QPID-3469 for further details.

        Show
        Robbie Gemmell added a comment - Closing issue out as part of JIRA cleanup. Issue may already be resolved, may be invalid, or may never be fixed. See QPID-3469 for further details.
        Hide
        Robbie Gemmell added a comment -

        Bumping to the 'future' version.

        Show
        Robbie Gemmell added a comment - Bumping to the 'future' version.
        Hide
        Andrew Kennedy added a comment -

        Move forward to 0.9

        Show
        Andrew Kennedy added a comment - Move forward to 0.9
        Hide
        Andrew Kennedy added a comment -

        Not explained very well. The modules that contain the pluggable transport would be usable as OSGi on the broker or just as plain JARs, loaded via a simple class.forName mechanism on the client. I'm not sure yet how to handle the possibile extra dependencies on the client when using an external transport layer, but as a default there should be no extra jars.

        Show
        Andrew Kennedy added a comment - Not explained very well. The modules that contain the pluggable transport would be usable as OSGi on the broker or just as plain JARs, loaded via a simple class.forName mechanism on the client. I'm not sure yet how to handle the possibile extra dependencies on the client when using an external transport layer, but as a default there should be no extra jars.
        Hide
        Rajith Attapattu added a comment -

        While I am not again making the transports pluggable using OSGi on the broker side, I am -1 on the client side.
        We don't need any more dependencies on the client than what we have today.
        I am actually hoping to get rid of mina deps from both common and client modules as soon as time permits.

        From a users perspective the client should be as light weight as possible without any dependencies forced on them.

        However if you can achieve the OSGi-fication of the transports without introducing any dependencies in the common and client module then I am fine with it.
        I am very keen on avoiding any compile time and runtime dependencies on the Java client (client and common modules) as much as possible.

        Show
        Rajith Attapattu added a comment - While I am not again making the transports pluggable using OSGi on the broker side, I am -1 on the client side. We don't need any more dependencies on the client than what we have today. I am actually hoping to get rid of mina deps from both common and client modules as soon as time permits. From a users perspective the client should be as light weight as possible without any dependencies forced on them. However if you can achieve the OSGi-fication of the transports without introducing any dependencies in the common and client module then I am fine with it. I am very keen on avoiding any compile time and runtime dependencies on the Java client (client and common modules) as much as possible.

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrew Kennedy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development