My memory is vague on security-ext but I think the purpose was to extend the security component for application-level functionality (as opposed to framework-level). For example the UserLogin.partyId field was added to the schema in this component because the framework wasn't supposed to have any concept of the Party model.
Regards Scott On 9/01/2018 7:14 AM, "Taher Alkhateeb" <slidingfilame...@gmail.com> wrote: > I stand corrected, Scott made a very good point regarding entityext > that I did not pay enough attention to. Perhaps the name is misleading > though, entityext means an enhancement or extension of the > capabilities of the entity component which does not make a lot of > sense. If it was called entity-service or entity-service-map or > something like might have been more direct and self explanatory. > > I think Jacopo's comment of moving away from components to jars as the > building blocks (at least for the framework) is a fantastic idea. It > might involve a heavy amount of work but is definitely doable if we > get focused. Meanwhile, back to the subject of ext components, perhaps > many of them need to be merged and or replaced. That might include: > - securityext: not sure why it exists > - commonext: that's a difficult one, lots of entanglements, but none > the less I'm not sure why does it exist and why does it depend on > other "application" components. > - exampleext: no idea why, but probably least useful. > > So following Pierre's suggestion perhaps we should generalize this > thread and consider removing all three? > > On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato > <jacopo.cappell...@hotwaxsystems.com> wrote: > > Scott is making a good point about entity-ext: in my opinion the design > is > > good (but can be improved). > > I suspect that commonext and exampleext have a less clean implementation > > and maybe they do not even implement that pattern, I see less value in > them. > > > > One comment on entity-ext: In my opinion we should (for this and for > > several other parts of the framework) continue the work to make the > > framework code more modular (with core independent modules and with > > extended modules that depend on them etc...) but I don't think that the > > building block should be the "OFBiz component" as it is now. It would be > > better to rely on jar files instead. > > For example: > > entity-core-api.jar > > entity-core-impl.jar > > service-core-api.jar > > service-core-impl.jar > > > > service-entity.jar that provides the integration of services with the > > entity engine and depends on entity-core-api.jar and service-core-api.jar > > > > We could define several granular modules that would allow to deploy > > different flavors of the framework, e.g.: > > 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to > > legacy applications (built from scratch) > > 2) service-core-api.jar + service-core-impl.jar: service engine available > > to legacy applications (built from scratch) > > 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity > engine > > available to legacy applications (built from scratch) > > etc... > > > > Jacopo > > > > On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <scott.g...@hotwaxsystems.com > > > > wrote: > > > >> I'm not familiar with commonext or exampleext, but the purpose of the > >> entity-ext component was to allow the entity engine to exist without the > >> service engine. That's why all the entity-related logic that relies on > the > >> service engine is implemented there (EECAs, EntitySync, DCC). The > >> alternative would be to have that stuff in the service engine, it can't > >> exist in the entity engine because you'd have a circular compile-time > >> dependency. > >> > >> It effectively exists as a "disentanglement" of the entity and service > >> engines. > >> > >> Regards > >> Scott > >> > >> > >> On 8 January 2018 at 09:18, Taher Alkhateeb <slidingfilame...@gmail.com > > > >> wrote: > >> > >> > I think all -ext components (entityext, commonext, exampleext) are > >> > redundant and do not add value. Any patches to fix this issue and > >> > merge these components would be great. > >> > > >> > > >> > > >> > On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <pierresm...@apache.org> > >> > wrote: > >> > > Hi all, > >> > > > >> > > The ExampleExt components provides functionality to extend widgets > >> across > >> > > components. In this solution, the ExampleExt component has form > widgets > >> > > extending similar widgets in the Example component. > >> > > > >> > > This kind of functionality (both within one component and across, > and > >> > with > >> > > more variants) already/also exists in other components in the > >> > > ofbiz-framework code base. > >> > > > >> > > So, do we still want to entertain/maintain a component that adds > little > >> > to > >> > > no unique value for our (potential) adopters, even though it is in > the > >> > > ofbiz-plugin code base? > >> > > > >> > > For what it is worth: the ExampleExt widgets can easily be > integrated > >> in > >> > > the Example component, and the existence of extended/extending > widgets > >> in > >> > > the ofbiz-framework code base also serves as examples of what can be > >> > > achieved by adopters/contributors. > >> > > > >> > > What are your thoughts? > >> > > > >> > > > >> > > Best regards, > >> > > > >> > > Pierre Smits > >> > > > >> > > V.P. Apache Trafodion > >> > > PMC Member Apache Directory > >> > > >> >
