On Fri, Oct 23, 2015 at 11:23 PM, Sameera Jayasoma <[email protected]> wrote:
> > > On Thu, Oct 22, 2015 at 11:44 PM, Afkham Azeez <[email protected]> wrote: > >> >> >> On Thu, Oct 22, 2015 at 6:13 PM, Manuri Amaya Perera <[email protected]> >> wrote: >> >>> >>> >>> 1. >>> >>> Why the name CarbonTransport? we can use just Transport. the full >>> name is org.wso2.carbon.transport.CarbonTransport and it already has >>> "carbon" >>> >>> >> Just because the package has Carbon it doesn't mean you shouldn't use it >> in any of the classes. The code becomes unreadable when those libraries are >> used elsewhere when you do that. Good examples are, HazelcastInstance not >> Instance, AxisConfiguration not Configuration, AkkaControlMessage not >> ControlMessage. I can give you enough of examples. So CarbonTransport is >> the proper name to use and improves the code readability. I am -1 to >> renaming this to Transport. >> > > This is just a name. If you thinks CarbonTransport is better then +1 :) > > >> >> >>> And why is it an abstract class? >>> >> >> Because it manages the lifecycle of the transport. Ensures that the >> lifecycle transitions a properly handled. >> >> >>> Remove register/unregister public methods from TransportManager >>> >> >> -1 to this again. The TransportManagementSC will get notified when >> CarbonTransports get registered/unregistered, and call the respective >> methods in TransportManager. >> > > -1 on keeping this on the TransportManager interface. > > We have to register TransportManager as an OSGi service. This is required > for a startup finalizer component to start transports when all the other > dependencies are satisfied. > > We are using the OSGi white-board pattern to listen to Transport > implementations which means all the Transport implementations should > register themselves as OSGi services. *We do not allow anyone to invoke > TransportManager.registerTransport method to register a transport. This > will cause issues with startup order.*Therefore we should remove these > two APIs from the TransportManager interface. > > We've had similar issue in C4 world. I can give you enough examples where > we have given developer choices and things went so wrong due to all these > choices. > > IMHO, there is no point of keeping these methods in the TransportManager. > Why do you want to keep these methods anyway? If no one using and if these > methods can cause confusion we should remove those. > I don't understand what you are saying. Can you send a diff? In this case, TransportManager register/unregister methods are same as if we had used a DataHolder. It was not designed to be exposed as an OSGi service. It is a concrete class. If you want to do that & If you make the methods package protected, nobody from outside will be able to call those methods. > > Thanks, > Sameera. > > > > -- > Sameera Jayasoma, > Software Architect, > > WSO2, Inc. (http://wso2.com) > email: [email protected] > blog: http://blog.sameera.org > twitter: https://twitter.com/sameerajayasoma > flickr: http://www.flickr.com/photos/sameera-jayasoma/collections > Mobile: 0094776364456 > > Lean . Enterprise . Middleware > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919blog: **http://blog.afkham.org* <http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez* <http://twitter.com/afkham_azeez> *linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
