On Fri, Apr 6, 2012 at 12:02 PM, Marius Dumitru Florea <[email protected]> wrote: > On Fri, Apr 6, 2012 at 12:43 PM, Anca Luca <[email protected]> wrote: >> I On 04/06/2012 09:35 AM, Vincent Massol wrote: >>> >>> Hi Sergiu, >>> >>> Note that below I'm going to play the devil's advocate since I think it's >>> important we really think hard before changing anything and verify if our >>> current implementation is not enough. >>> >>> See below. >>> >>> On Apr 5, 2012, at 8:44 PM, Sergiu Dumitriu wrote: >>> >>>> On 04/05/2012 12:51 PM, Anca Luca wrote: >>>>> >>>>> On 04/05/2012 06:42 PM, Vincent Massol wrote: >>>>>> >>>>>> Hi Sergiu, >>>>>> >>>>>> On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote: >>>>>> >>>>>>> Hi devs, >>>>>>> >>>>>>> Currently, requesting a component instance without a hint will look >>>>>>> for the implementation that uses the "default" hint, which makes it >>>>>>> difficult to change the implementation in an XWiki instance. Sure, it >>>>>>> is easy as long as all the implementations use the "default" hint, >>>>>>> but choosing the default between alternative implementations that >>>>>>> should all still be usable by themselves is not possible. >>>>>>> >>>>>>> Also, "default" is not really a good hint, since it describes the >>>>>>> state of the implementation, not the technology, the aspect that >>>>>>> makes it different from the others. It would be better to name each >>>>>>> implementation with a proper hint. >>>>>>> >>>>>>> I propose to define a mapping that can specify which hint is the >>>>>>> default for a component. In a text file, >>>>>>> META-INF/component-defaults.txt, we'll keep >>>>>>> componentinterface=defaulthint mappings. For example: >>>>>>> >>>>>>> com.xpn.xwiki.store.XWikiStoreInterface=hibernate >>>>>>> com.xpn.xwiki.store.migration.DataMigrationManager=hibernate >>>>>>> >>>>>>> And then, when we lookup the current storage implementation, we don't >>>>>>> need to check what is the configured hint in xwiki.cfg (or >>>>>>> xwiki.properties), we can just request the default implementation. >>>>>>> >>>>>>> If there's no mapping for a component, we'll continue to use the >>>>>>> "default" hint. >>>>>>> >>>>>>> I'm not sure where exactly to keep such files. We bundle a >>>>>>> components.txt file in each jar containing component implementations. >>>>>>> We could do the same for the components we consider the platform >>>>>>> defaults, and allow overrides in the >>>>>>> WEB-INF/classes/META-INF/component-defaults.txt file. Still, this >>>>>>> means that whenever platform defaults change, we need to keep another >>>>>>> special section in the release notes, to let users know about these >>>>>>> changes, so that they can manually revert to the old default if they >>>>>>> need to. >>>>>>> >>>>>>> In the future we could change existing components to give proper >>>>>>> hints instead of "default", where such a change is applicable. >>>>>>> >>>>>>> Another idea is to not use "default" at all, and instead go for a >>>>>>> generic "xwiki", "xe", "xwiki-platform" or something like that >>>>>>> whenever there's just one implementation for a component and we can't >>>>>>> find another hint to describe it. >>>>>>> >>>>>>> WDYT? >>>>>> >>>>>> This is not really how it's been designed ATM. Whenever you wish to >>>>>> use a different implementation of a component you use a component >>>>>> implementation with the same role and same hint. You then make it >>>>>> available in your classpath. (Of course you can also do this at >>>>>> runtime simply by registering a new implementation over the old one). >>>>>> >>>>>> To decide which implementation is used you use a priority order, as >>>>>> described on: >>>>>> >>>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides >>>>>> >>>>>> >>>>>> I'd be curious to know your exact use case and understand why the >>>>>> current mechanism doesn't work for it. >>>> >>>> "...choosing the default between alternative implementations that should >>>> all **still be usable by themselves** is not possible" >>>> >>>> The overrides mechanism allows to change which component will be returned >>>> for the "default" hint, but all the others will be invisible. >>>> >>>>> One usecase I see is that you have multiple implementations and you want >>>>> to change the default one for a specific running instance of xwiki. >>>>> >>>>> Overwrite mechanism only allows you to say which impl should be used >>>>> from the _components with the same hint_. However, you cannot change the >>>>> hint of a component at configuration time, so if you have a standard >>>>> distr of xwiki and you want to use ldap authentication, let's say (if >>>>> only auth was impl with components), unless you do some java to add the >>>>> default hint to the ldap implementation and then to specify that this >>>>> one has priority over all the default ones, I don't see how you can >>>>> re-wire the default. >>>> >>>> Exactly. For most of the "services" the XWiki platform currently has >>>> (storage, cache), we don't have a "default" implementation, but we rely on >>>> a >>>> kind of factory to lookup the configured default. That is an actual factory >>>> class in the case of the cache service, but just more code in the old >>>> XWiki.java class for the storage initialization. >>> >>> Yep that's how it works. >>> >>>> A standard way of selecting the default means that we'll need less >>>> factories, and less code is always a good thing. >>> >>> Yes but it has more limitation to what we have since with a proper Factory >>> you can imagine all kind of logic to decide which implementation to use >>> (hour of the day, whether the user is a premium user or not, etc). >>> >>> BTW we do support Providers and the goal of the Provider is to be a >>> factory for a given Role. So from now on, there should be no need to >>> implement a Factory proper. Implementing a Provider is the new best practice >>> for this. >>> >>>> Now, suppose one of the older components that had only one >>>> implementation, "default", gets alternative implementations, and we want to >>>> be able to allow more than one to be active in a wiki, and let the >>>> administrator decide which one should be considered the default. How can we >>>> approach this? The only way is indeed to have multiple hints, but last time >>>> I checked this resulted in more than one instance, even for @Singleton >>>> implementations. >>> >>> Correct, ATM we support only one hint per implementation. >> >> > >> ? I think Marius needed that for some wysiwyg stuff and we actually support >> multiple hints per implementation. It's just gonna give you a new instance >> for each hint, which in my view is a bug, not a missing feature. > > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/filter/http/MutableHttpServletRequestFactory.java > > but it's the old way to specify the hint. I don't think you can put > two @Named or a list of names as the value of @Named.
Well you can put several time an annotation but I don't think we take all of then into account (but that's just a choice, we could decide to take all of them). > > Thanks, > Marius > >> >> >>> >>>> Another approach is to deprecate the direct dependency declaration and >>>> instead introduce a factory that is responsible for selecting the default, >>>> but this breaks backwards compatibility. >>> >>> Not completely true. Imagine you have (Role, "default") as your current >>> component and you wish to be able to choose various implementation from now >>> on. What you could do is this: >>> >>> * Write a new component, a Factory, that overrides the current component, >>> i.e. by using the same (Role, "default"). This factory will then delegate to >>> whatever other implementation it wishes. >> >> >> That's only possible if the public API of the CM allows you to grab >> overriden components (non-default defaults :) ) >> >> >>> >>> From the user of (Role, "default")'s POV he won't see a single change. >>> >>>> The "I don't care, just give me the default" strategy works as long as >>>> the component implementation is self-contained and doesn't involve data >>>> communication. Let's take an example, PDF export. >>>> >>>> Currently the PDF export is only possible via FOP. If we were to convert >>>> the current interface + implementation class into a proper component, we'd >>>> name it "default", since it's the only one and who needs a factory for only >>>> one implementation. >>> >>> Yes but we could also be thorough and instead implement a >>> Provider<PDFExporter> instead. >>> >>>> People use it and they're happy because it just works. But we might soon >>>> add support for export via an office server. Suppose we want either FOP or >>>> Office to be usable as the default PDF export implementation. And suppose >>>> we'll want to keep both types of export active, so that we can use either >>>> one as the implementation for the default export of documents, the FOP >>>> implementation for exporting some kinds of documents like scientific >>>> articles, and the office connector for generating PDFs for presentations. >>>> Using the overrides mechanism we can only have one active at the same time, >>>> unless we introduce yet another factory which we can bypass using manual >>>> component lookup. >>> >>> Based on your use case you'll need a UI to ask the user what he wants to >>> export, i.e. either a "scientific article" or a "presentation" and from his >>> choice you'll pick the right implementation. You could also try to guess >>> that dynamically by looking at what is being exported but that'll require a >>> Factory to hold that logic. >>> >>> I know what you mean though: for some reason you don't want that to be >>> dynamic and you wish it to be static. >>> >>> There's a problem with dynamicity though. Imagine an extension that wants >>> to replace an implementation. With your proposal the best practice would be >>> to introduce a new Hint since the "default" is chosen statically at >>> configuration time. So that wouldn't work. After you install extensions >>> you'd need to stop the wiki, change the binding to the new implementation >>> from the extension and restart it. Of course you'd need to read the >>> documentation of the extension to know you have to use it in replacement. >>> Basically it would mean that extensions cannot override behaviors. They >>> would just be able to add new components (like new Macros) but not modify >>> behaviors at runtime. >> >> >> But this only means we need to be able to change configuration without >> stopping the wiki and make it reload configs (might prove useful for other >> things as well), it doesn't mean we cannot do it "static". >> >> >>> >>>> If at some point we decide that the office implementation works better, >>>> we might consider changing the default implementation for the pdf >>>> component. >>>> This means that we'll change the hint of the FOP implementation from >>>> "default" to "fop", change the hint of the Office implementation from >>>> "office" to "default", and our new version of XE works great if people read >>>> the installation guide and properly configure the office connector. >>> >>> In practice we would have 2 choices with our current component impl.: >>> >>> Choice 1: >>> * Add 2 new implementations with hint1 and hint2 (hint1 being what was >>> "default" before) >>> * Keep the implementation with "default" hint but deprecate it and move it >>> to legacy. Refactor it so that it delegates yo hint1 >>> * Add a Provider to decide which impl to use based on whatever conditions >>> we want >>> >>> Choice 2: >>> * Move "default" impl to "hint1" >>> * Add "hint2" >>> * Change "default" implementation to be a Composite that delegates to >>> hint1 or hint2 >>> >>>> But what about those that want to upgrade, but are happy with the older >>>> FOP implementation and don't want to add support for the office connector? >>> >>> Yes, in this case this is transparent for them (and it's a good thing in >>> most caes!). This means they get autoupgrade to something better. >> >> >> No, it means that for some reason we decided to change the underlying >> technology (e.g. change of licence), it doesn't mean that everybody is happy >> with the change. >> >>> >>>> They'll have to use patched versions of the two component implementations >>>> where their hints are reverted back to the old values. Easy? No. And even >>>> though "default" means "I don't care what the implementation does" >>> >>> It doesn't really mean this. We use "default" only when there's a single >>> implementation. When there are more than 1 each one has a hint that is a >>> qualifier to the implementation since there's no reason one is more default >>> than the other. >>> >>>> , here it does matter a lot which implementation you're using. They have >>>> different requirements, and it's important to know if the implementation >>>> will require an office instance or not. >>>> >>>> Saying that this won't happen since we're all really careful when >>>> designing our components is wishful thinking. We've refactored other more >>>> critical pieces of code than providing alternative implementations for a >>>> component, so we will find ourselves in situations where we'll have to >>>> switch from only one "default" implementation to several. >>> >>> I agree that we've refactored. And it has worked so far right? ;) >>> >>>> Designing our component manager to make it easy to transition is the >>>> right thing to do. >>>> >>>> Still, my major problem is not about overrides, but about the semantics >>>> of "default" (or lack of it). This says nothing about the actual mechanisms >>>> behind the implementation, it just reflects the state of that particular >>>> component implementation: it's the default at the moment. Not caring what >>>> the implementation actually does works only when there is indeed just one >>>> possible implementation that is straight-forward. But in most cases, we do >>>> rely on another library that does the work for us, and libraries die, >>>> better >>>> alternatives come along, and changing that internal aspect of the >>>> implementation will sometimes be backwards incompatible, or have a >>>> different >>>> behavior. Sure, it does the same job, but it does it so differently that >>>> some will prefer to use the other approach. We have to let users decide >>>> which is their "default", and having multiple implementations with the >>>> "default" hint but different priorities is not very intuitive. Why not make >>>> everything default and remove hints completely if we don't really put any >>>> meaning into the hint? >> >> >> This also means that we should only have components where there is a chance >> that another implementation might exist, because to the limit you can >> separate the interface from the implementation for any little piece of code >> that you write. >> >> I sort of feel you for this default thing, but at the same time, it's also a >> matter of education of the developer, which needs to make sure that they put >> a technology hint to the component, besides the default hint. The pb is >> that, as long as there is only one implementation, regardless of the >> technology it's based on, you also need to put the default hint since >> otherwise you'll have to hardcode the reference to the technology everywhere >> if you wanna use that service. so in this case default would mean 'this is >> the one that should be used because there's no other, you dumb CM that is >> not capable of seeing that'. >> >> This brings back some memories, but I don't know from what, about a system >> that was giving the available implementation regardless of its name. For >> example, we could make the CM return the only implementation, if only one >> exists, when asking for a component, regardless of its hint, so we don't >> have to put default everywhere. But then we need a strategy for the case >> when there are more. >> >> >>>> >>>> And "default" adds another assumption: XWiki Enterprise is the ultimate >>>> target. Our defaults are the only ones that matter. As an example, all the >>>> *Configuration components have just one "default" implementation, which >>>> relies on xwiki.properties, XWiki.XWikiPreferences etc. Doesn't that tie >>>> the >>>> platform to the XWiki Enterprise wiki? >>> >>> This not true in xwiki commons and rendering because I've made sure that >>> we could use them outside of the XWiki Platform. They have default >>> implementation that don't use XWiki Configuration module. >>> >>>> It's not a direct dependency visible at compilation time, it's worse, and >>>> invisible assumption about the final runtime. It's certainly not the >>>> default >>>> for other types of users that want to embed xwiki-commons or xwiki-platform >>>> components in a different type of end product. To me this isn't the default >>>> configuration, this is the default configuration used by XWiki Enterprise, >>>> thus my proposal of using something else as the generic component hint >>>> instead of "default". >>> >>> Ok thanks for the explanations. I understand better now what you mean. >>> >>> Actually what you suggest could already be implemented using a best >>> practice of always using Providers when you want a Component injected. In >>> this manner by default you'll get the Generic Provider but anyone could >>> implement a specific Provider implementation for it that would choose >>> between various implementation based on whatever (a value in a >>> META-INF/role-bindings.txt file, data from DB, etc). >>> >>> <side note>Only issue with having Providers everywhere is that you get >>> late verification of your system coherence since dependencies will be >>> resolved only when they're used. OTOH this is a necessity in a fully-dynamic >>> system ;)</side note> >>> >>> Also, the notion of default doesn't always have a meaning. There are lots >>> of cases when there are NO default. For example Macros or Transformations >>> or… >>> >>> Let's continue the discussion it's interesting :) >>> >>> I'd like to review a bit the other Component system out there again to see >>> what they do for this. It's important that they have support for this since >>> we want to be able to switch to them one day. The 3 that I would review are: >>> * Guice >>> * CDI >>> * OSGi >> >> >> yes, we should learn from others. Maybe even use one? >> >> Thanks, >> Anca >> >> >>> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
