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. 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
