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.

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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to