On Mon, Aug 9, 2010 at 11:40 AM, Afkham Azeez <[email protected]> wrote:
> > > On Mon, Aug 9, 2010 at 11:37 AM, Amila Suriarachchi <[email protected]>wrote: > >> >> >> On Mon, Aug 9, 2010 at 11:25 AM, Danushka Menikkumbura <[email protected] >> > wrote: >> >>> Amila, >>> >>> I don't think it is "nice" to name your exportable packages "external". >>> It is just enough to keep your private stuff internal. >>> >> >> Ok. then you can start writting the component as under internal package >> and move things need to expose into top level. then make internal as >> private. >> >> What I try to tell is always a component should have more internal classes >> than external classes. So always better to extract external out rather than >> thinking other way. >> > > Yes. We can start having most classes under internal. Only a very few > classes need to be seen outside the bundle. > But for current carbon components only a few packages under internal. This is because we have moved internal as internal starting everything as external. We need to do it other way round to make code clear and secure. > Yet, we cannot put external classes under a package called external. > Agreed. thanks, Amila. > > >> >> thanks, >> Amila. >> >>> >>> Danushka >>> >>> >>> On Mon, Aug 9, 2010 at 11:14 AM, Amila Suriarachchi <[email protected]>wrote: >>> >>>> >>>> >>>> On Mon, Aug 9, 2010 at 10:33 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> This is more about good encapsulation at the component level. The >>>>> component author should consciously decide which classes are bundle-local >>>>> & >>>>> which should be part of the API provided by the bundle. Having said that, >>>>> I've seen a lot of code where attributes that should have private scope, >>>>> have been declared in package-local scope! As best practice, it is always >>>>> good to start with typing in the scope of the attribute, and then the >>>>> class >>>>> name. I have created autocompletion shortcuts such as pvt (private) & pub >>>>> (public) which lets me define the scope in less than a second. >>>> >>>> >>>> If we do this correctly we need to move the internal/external after top >>>> level package name. >>>> >>>> eg. >>>> org.wso2.carbon.event.cep.core.internal >>>> org.wso2.carbon.event.cep.core.external >>>> >>>> and all the other package structures should go under it. >>>> >>>> But I think better it is enough to move the externally accessible >>>> classes into external package. And use others as it is. This may improve >>>> the >>>> readability of the code since any one accessing a particular component only >>>> has to look in to external package classes. >>>> >>>> At least in theory components should be decoupled and should be >>>> cohesive. Therefore a component should only have a small set of interfaces >>>> which it use to communicate with others and implementation classes should >>>> be >>>> local to that component. >>>> >>>> thanks, >>>> Amila. >>>> >>>> >>>> >>>>> >>>>> Azeez >>>>> >>>>> >>>>> On Mon, Aug 9, 2010 at 12:15 AM, Sumedha Rubasinghe >>>>> <[email protected]>wrote: >>>>> >>>>>> I think we need to have this type of security checks in the unit tests >>>>>> that use CarbonContext. This is one place where malicious code can get >>>>>> into >>>>>> a running system. >>>>>> >>>>>> /sumedha >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Aug 8, 2010 at 5:59 PM, Sameera Jayasoma <[email protected]>wrote: >>>>>> >>>>>>> +1. We've faced many security issues, due this exposure of internal >>>>>>> packages. One such good example is, never expose your BundleActivator. >>>>>>> It >>>>>>> might be keeping references to your BundleContext and the BundleContext >>>>>>> should never be shared with any other bundle. >>>>>>> >>>>>>> Sameera >>>>>>> >>>>>>> On Fri, Aug 6, 2010 at 8:53 AM, Afkham Azeez <[email protected]> wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> We haven't been paying proper attention to bundle internal vs. >>>>>>>> external classes. This is evident by the fact that most of our internal >>>>>>>> packages contain only a few classes. Most of the classes are related >>>>>>>> to the >>>>>>>> bundles internal implementation and hence should not be exposed to >>>>>>>> outside >>>>>>>> bundles. In the future, please make it a point to place your bundle >>>>>>>> private >>>>>>>> classes within subpackages of the internal subpackage as shown in the >>>>>>>> example below. >>>>>>>> >>>>>>>> >>>>>>>> e.g. >>>>>>>> org.wso2.stratos.permission.update.internal.task.PermissionUpdaterTask >>>>>>>> >>>>>>>> If you look at most of our components, you will notice that a >>>>>>>> significant number of them should have only internal package. Please >>>>>>>> follow >>>>>>>> this when developing bundles in the future & also feel free to fix >>>>>>>> this in >>>>>>>> existing bundles. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -- >>>>>>>> Afkham Azeez >>>>>>>> Senior Software Architect & Senior Manager; WSO2, Inc.; >>>>>>>> http://wso2.com, Lean . Enterprise . Middleware >>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>> email: [email protected] cell: +94 77 3320919 >>>>>>>> blog: http://blog.afkham.org >>>>>>>> twitter: http://twitter.com/afkham_azeez >>>>>>>> linked-in: http://lk.linkedin.com/in/afkhamazeez >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Carbon-dev mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sameera Jayasoma >>>>>>> Technical Lead >>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>> email: [email protected] >>>>>>> blog: http://tech.jayasoma.org >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Carbon-dev mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Carbon-dev mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Afkham Azeez >>>>> Senior Software Architect & Senior Manager; WSO2, Inc.; >>>>> http://wso2.com, Lean . Enterprise . Middleware >>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>> email: [email protected] cell: +94 77 3320919 >>>>> blog: http://blog.afkham.org >>>>> twitter: http://twitter.com/afkham_azeez >>>>> linked-in: http://lk.linkedin.com/in/afkhamazeez >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > Afkham Azeez > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, > Lean . Enterprise . Middleware > Member; Apache Software Foundation; http://www.apache.org/ > email: [email protected] cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
