IRC Archive for channel #xwiki on 15 July 2015
Last modified by Vincent Massol on 2015/07/15 23:55
<abusenius> has quit
01:38 <ansuz> has quit
01:38 <ansuz> has joined #xwiki
02:59 <sdumitriu> has quit
03:14 <sdumitriu> has joined #xwiki
06:02 <Denis> has joined #xwiki
06:03 <Denis1> has quit
06:43 <mflorea> has joined #xwiki
08:05 <vmassol> has joined #xwiki
08:07 <Ramona2> has joined #xwiki
08:12 <cjd> has quit
08:27 <abusenius> has joined #xwiki
08:40 <msmeria> has joined #xwiki
08:45 <KermitTheFragger> has joined #xwiki
08:49 <Pbas> has joined #xwiki
08:52 <mflorea> has quit
08:53 <lucaa> has joined #xwiki
08:54 <cjd> has joined #xwiki
09:04 <lucaa> has quit
09:04 <lucaa1> has joined #xwiki
09:23 <gsmeria> has joined #xwiki
09:24 <gsmeria1> has joined #xwiki
09:24 <gsmeria> has quit
09:29 <mflorea> has joined #xwiki
09:31 <gdelhumeau> has joined #xwiki
09:37 <Slashman> has joined #xwiki
09:38 <vmassol> mflorea: do you know why line ednings have changed in http://www.xwiki.org/xwiki/bin/view/Main/Support?viewer=changes&rev1=30.1&rev2=30.4 ?
09:38 <vmassol> doesn't look right
09:38 <mflorea> let me see
09:39 <mflorea> vmassol: probably because Windows vs. Linux editing
09:39 <vmassol> yes but that doesn't look noemal
09:39 <vmassol> *normal
09:40 <vmassol> that would mean we don't normalize the content and all xobjects are saved again when yiu save
09:40 <vmassol> *you
09:40 <mflorea> I don't think we do this
09:40 <vmassol> only the modified xobject should we modified in the DB
09:40 <vmassol> not all comments
09:40 <vmassol> s/should we/should be
09:41 <mflorea> I think that in object editor all the objects are updated
09:41 <vmassol> ok I'm opening a jira issue, we probably already have one though
09:41 <mflorea> when you save, because the entire HTML form (with all the fields for each object) is submitted
09:41 <Trefex> has joined #xwiki
09:42 <mflorea> but from the diff it looks like the user only added some comments, so I doubt it was from object editor
09:42 <vmassol> hmm
09:42 <vmassol> I added 2 comments
09:42 <mflorea> and the add comment form shouldn't affect existing comments
09:42 <vmassol> and the link I gave you now doesn't show the issue anymore
09:43 <vmassol> why is even more weird
09:44 <vmassol> do you still have it open in ordder to take a screenshot for thr issue?
09:44 <vmassol> :)
09:44 <mflorea> yes
09:44 <vmassol> cool
09:44 <vmassol> starting issue creation
09:44 <vmassol> and you can add it once I'm done
09:46 <mflorea> yes, just give me the link
09:50 <vmassol> mflorea: http://jira.xwiki.org/browse/XWIKI-12307# could you name your file diff1.png?
09:50 <mflorea> sure
09:51 <mflorea> done
09:51 <vmassol> thx
09:53 <vmassol> mflorea: 18 test failures at http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/testReport/ For example http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/EditObjectsTest/testPropertyDisplayersForNewObjects/ doesn't seem related to the new script permissions, is it?
09:59 <gsmeria1> has quit
10:00 <gsmeria> has joined #xwiki
10:00 <mflorea> vmassol: checking
10:55 <Trefex> has quit
11:13 <gsmeria> has quit
11:16 <ClemensR> has joined #xwiki
11:30 <Enygma`> has joined #xwiki
11:35 <spawn57> has joined #xwiki
11:36 <spawn57> Hi, For the share page by email feature. Is it possible to customise the email template?
11:39 <vmassol> spawn57: yes
11:39 <vmassol> it's located in XWiki.SharePage AFAIR
11:39 <vmassol> yep that's it (just checked)
11:40 <vmassol> so you edit that page using the object editor and you can customize the template
11:40 <spawn57> thanks!
11:41 <vmassol> added quickly here FYI: http://extensions.xwiki.org/xwiki/bin/view/Extension/Share+Page+Application#HConfiguretheMailTemplate
11:47 <Trefex> has joined #xwiki
11:59 <evalica> has joined #xwiki
12:03 <woshilapin> Hi here, I will probably ask a dumb question but I'd like to understand anyway...
12:03 <woshilapin> To Inject a component, I have 3 ways:
12:03 <woshilapin> - @Inject
12:03 <woshilapin> - Utils.getComponent
12:03 <woshilapin> - Creating a provider
12:03 <woshilapin> Right?
12:04 <woshilapin> If yes, I'd like to understand the difference between the last 2
12:05 <woshilapin> (because second is one-line, and for the third, you have to inject a provider, and then use it, so it's more 2 lines (3 with the @Inject))
12:10 <vmassol> no
12:10 <vmassol> well
12:10 <vmassol> :)
12:10 <woshilapin> :-)
12:10 <vmassol> Utils is a hack
12:10 <vmassol> to access components from a non component world
12:11 <woshilapin> OK, so the nice way is the provider...
12:11 <vmassol> provider is for factories
12:11 <woshilapin> Yes, but I guess that if @Singleton...
12:11 <vmassol> to inject a component there's only a single way
12:11 <vmassol> @Inject
12:11 <woshilapin> OK, let me explain my problem with @Inject
12:12 <vmassol> actually there are 2 ways
12:12 <woshilapin> (and be sure that architecture is probably not perfect)
12:12 <vmassol> the second way is to sue the CM
12:12 <cjd> If there are 2 ways to do something which are functionally equivilant, always prefer the one which requires typing more code
12:12 <cjd> <trollface>
12:13 <woshilapin> I inherit from a class that contains an attribute (and I want parent class to not depend on components which means annotations and stuff)
12:13 <vmassol> woshilapin: you read http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module right?
12:13 <woshilapin> And in the child class, I'd like to inject this attribute, (potentially different hint in different implementations)
12:13 <vmassol> BTW Provider *is* a component
12:14 <vmassol> you also @Inject it
12:14 <woshilapin> Yes, but that I would use in the child which is fine
12:14 <vmassol> I think your question is whether we support constructor injection and the answer is no
12:15 <woshilapin> Then I'll try to understand my question first :-P
12:15 <vmassol> so you have to pass what you need to your POJO so that it can find other components
12:15 <vmassol> either passing the components it needs in its constructor or passing the CM instance
12:15 <vmassol> (if I understand your need ;))
12:16 <woshilapin> Yes, call Utils.getComponent in the constructor would be my solution but as far as I understand, it doesn't work
12:17 <woshilapin> (and then, I guess, I understand my question, right?)
12:17 <vmassol> don't use Utils if you can avoid it
12:17 <vmassol> just pass the component you need
12:17 <woshilapin> (yes, it was shorter to write but I would use provider)
12:17 <cjd> initialize() { super.setWhateverAttribute(this.injectedAttributeThingy); }
12:17 <vmassol> inversion of control
12:17 <cjd> initialize is called after injections are complet
12:17 <woshilapin> Yes, that what Fabio suggested me, but I was trying to understand really the problem :-)
12:18 <woshilapin> extends Initializable and then define initialize() method seems to be my solution then
12:18 <cjd> the CM will create the object, then it will reflect the private fields and put the stuff in them according to the @Inject annoatations
12:18 <woshilapin> (or implements Initializable...)
12:18 <cjd> then it will look for an initialize() and call it if it exists
12:18 <vmassol> so your use case is to provision a POJO, right?
12:19 <vmassol> so indeed 2 choices:
12:19 <vmassol> 1) Implement a Provider to return a provisioned POJO
12:19 <vmassol> 2) Pass whatever the POJO needs in its constructor (ie all components it needs)
12:19 <cjd> AFAICT he's trying to set some crap in the superclass
12:19 <vmassol> but evenf or 1) you'll need to do 2) ;)
12:20 <vmassol> cjd: I don't see what that has to do with components
12:20 <cjd> The component is a subclass of something which needs some customization itself
12:21 <vmassol> then yes Initializable is good for this
12:21 <cjd> he's using the Object Inheritence antipattern so he has to use a hack here
12:21 <vmassol> if you need to do that at init time and not in a lazy way
12:24 <woshilapin> OK, thanks both of you
12:24 <woshilapin> I think I'll sleep on that at lunch for now :-)
13:28 <Denis1> has joined #xwiki
13:30 <lynxt_> has joined #xwiki
13:31 <tillo_> has joined #xwiki
13:37 <Denis> has quit
13:37 <tillo> has quit
13:37 <Pbas> has quit
13:37 <Pbas> has joined #xwiki
13:37 <tillo_> is now known as <tillo>
14:09 <tmortagne> has joined #xwiki
14:18 <OSIMasson> has quit
14:36 <Ramona> has joined #xwiki
15:13 <Ramona> has quit
15:27 <OSIMasson> has joined #xwiki
15:29 <OSIMasson> has quit
15:33 <Denis1> is now known as <Denis>
15:49 <Ramona> has joined #xwiki
16:26 <OSIMasson> has joined #xwiki
16:27 <Ramona> has quit
16:28 <Denis> has quit
16:28 <Denis1> has joined #xwiki
16:31 <msmeria> has quit
17:15 <OSIMasson> has quit
17:15 <OSIMasson> has joined #xwiki
17:30 <sdumitriu> tmortagne: Question about GenericProvider https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-default/src/main/java/org/xwiki/component/embed/GenericProvider.java
17:30 <tmortagne> sdumitriu: shoot
17:30 <sdumitriu> Any reason why it uses the root component manager, and not the default one?
17:31 <sdumitriu> Wait
17:31 <sdumitriu> By default, I mean "context/root"
17:32 <tmortagne> on we don't have the same definition of root indeed :)
17:32 <tmortagne> it's using the CM from which it come from
17:33 <tmortagne> meaning that if a component installed in some wiki is responsible to asking this provider then the provider will see other components in the wiki
17:33 <tmortagne> if we force the provider to use the root CM is will only see root component
17:33 <sdumitriu> Which, for components initialized at startup, is the root component manager
17:33 <tmortagne> yes
17:34 <tmortagne> but only for them
17:34 <tmortagne> there is no reason to force the provider wherever it come from to use the root CM
17:35 <tmortagne> eventually it will end up in the root CM if it can't find anything in the current one so not sure hat is the issue exactly
17:35 <tmortagne> s/hat/what/
17:35 <sdumitriu> Here's my usecase:
17:35 <sdumitriu> @Inject Provider<List<SomeComponent>>
17:35 <sdumitriu> .get() doesn't give me components installed with the extension manager
17:36 <sdumitriu> So I had to implement my own Provider, which uses @Inject @Named("wiki") ComponentManager
17:37 <tmortagne> actually you'd probably better use the context component manager
17:37 <sdumitriu> The reason is that the component manager injected in the GenericProvider was the root one
17:37 <tmortagne> which will give you the righ SomeComponent depending on the current wiki, user etc
17:37 <tmortagne> s/SomeComponent/SomeComponents/
17:37 <sdumitriu> I thought about that, but since I use that to get some authorization modules, I don't want to use the "user" and "document" component manager
17:38 <sdumitriu> That would allow them to bypass authorization, if they're clever enough
17:38 <tmortagne> you would need PR to inject this kind of component anyway but as you like, it's better for performances anyway if wiki is enought for you
17:41 <tmortagne> so basically you initial question is why don't all Provider use the context CM or is it something else ?
17:42 <sdumitriu> Yes
17:42 <tmortagne> the exact answer would be that GenericProvider is older than the concept of context CM :) but that would certainly cover some use cases that prevent from using Providers right now
17:44 <sdumitriu> So that's something you'd consider a good improvement?
17:45 <tmortagne> we could maybe imagine support something like
17:46 <tmortagne> to be sure to not break some use case where the component really wanted the Provider to only search in its CM
17:46 <tmortagne> it's certainly a nice tool
17:46 <sdumitriu> The issue is that @Named applies to the component, not the provider
17:47 <tmortagne> right now yes, but we can probably find something
17:48 <tmortagne> either introduce a set a annotation to control GenericProvider which is too limited right now and would be nice for other use cases
17:48 <sdumitriu> We can define a new javax.inject.Qualifier
17:49 <tmortagne> javax.inject.Qualifier would be supposed to have the same logic than @Named wich is itself supposed to be just a javax.inject.Qualifier
17:49 <sdumitriu> For example @Documented @Retention(RUNTIME) @Qualifier public @interface ProviderType
17:49 <tmortagne> if we start supporting any javax.inject.Qualifier it's going to conflict
17:49 <sdumitriu> And then we can use @ProviderType("context")
17:50 <vmassol> btw on a related topic, we should seriously consider moving to CDI 2.0 which now supports JSE (and it's probably possible to do some runtime registration of beans - this is the part that needs to be researched)
17:51 <tmortagne> well we should consider moving it if there is runtime registration :)
17:51 <tmortagne> s/it/to it/
17:51 <tmortagne> without that it's pretty useless to us since we are doing that quite a lot
17:51 <vmassol> it's not built by default but I think there are options in the extensions
17:52 <tmortagne> in any case we can review CDI 2.0 annotation, there is probably some useful stuff for us we might want to support
17:52 <vmassol> yes that's got me thinking about that
17:53 <tmortagne> I remember talking about a more advanced provider with you
17:53 <vmassol> we should align our usage of annotations to the max extent
17:53 <tmortagne> (that was part of CDI)
17:54 <tmortagne> there is many things I don't like much about Provider and that could benefit from a few improvements
17:54 <vmassol> FTR https://issues.jboss.org/browse/CDI-114
18:22 <OSIMasson> has quit
18:30 <OSIMasson> has joined #xwiki
18:37 <cjd> has quit
18:52 <ClemensR> has quit
18:56 <OSIMasson> has quit
19:02 <Trefex> has quit
19:16 <mflorea> has quit
19:18 <woshilapin> has quit
19:18 <tmortagne> has quit
19:19 <evalica> has quit
19:20 <evalica> has joined #xwiki
19:20 <Enygma`> has quit
19:24 <sdumitriu1> has quit
19:24 <sdumitriu1> has joined #xwiki
19:24 <evalica> has quit
19:28 <cjd> has joined #xwiki
19:48 <gdelhumeau> has quit
20:04 <Enygma`> has joined #xwiki
20:20 <mflorea> has joined #xwiki
20:20 <woshilapin> has joined #xwiki
20:20 <Slashman> has quit
20:21 <OSIMasson> has joined #xwiki
20:48 <OSIMasson> has quit
20:52 <OSIMasson> has joined #xwiki
21:24 <risherry> has joined #xwiki
21:56 <lucaa1> has quit
22:03 <OSIMasson> has quit
22:10 <woshilapin> has quit
22:21 <lucaa> has joined #xwiki
22:27 <OSIMasson> has joined #xwiki
22:27 <KermitTheFragger> has quit
22:37 <woshilapin> has joined #xwiki
23:01 <lucaa> has quit
23:01 <lucaa> has joined #xwiki
23:23 <lynxt> has quit
23:25 <lynxt> has joined #xwiki
23:27 <lucaa> has quit
23:28 <tillo> has quit
23:29 <tillo> has joined #xwiki
23:34 <risherry> has quit
23:34 <mflorea> has quit
23:55 <vmassol> has quit
01:38 <ansuz> has quit
01:38 <ansuz> has joined #xwiki
02:59 <sdumitriu> has quit
03:14 <sdumitriu> has joined #xwiki
06:02 <Denis> has joined #xwiki
06:03 <Denis1> has quit
06:43 <mflorea> has joined #xwiki
08:05 <vmassol> has joined #xwiki
08:07 <Ramona2> has joined #xwiki
08:12 <cjd> has quit
08:27 <abusenius> has joined #xwiki
08:40 <msmeria> has joined #xwiki
08:45 <KermitTheFragger> has joined #xwiki
08:49 <Pbas> has joined #xwiki
08:52 <mflorea> has quit
08:53 <lucaa> has joined #xwiki
08:54 <cjd> has joined #xwiki
09:04 <lucaa> has quit
09:04 <lucaa1> has joined #xwiki
09:23 <gsmeria> has joined #xwiki
09:24 <gsmeria1> has joined #xwiki
09:24 <gsmeria> has quit
09:29 <mflorea> has joined #xwiki
09:31 <gdelhumeau> has joined #xwiki
09:37 <Slashman> has joined #xwiki
09:38 <vmassol> mflorea: do you know why line ednings have changed in http://www.xwiki.org/xwiki/bin/view/Main/Support?viewer=changes&rev1=30.1&rev2=30.4 ?
09:38 <vmassol> doesn't look right
09:38 <mflorea> let me see
09:39 <mflorea> vmassol: probably because Windows vs. Linux editing
09:39 <vmassol> yes but that doesn't look noemal
09:39 <vmassol> *normal
09:40 <vmassol> that would mean we don't normalize the content and all xobjects are saved again when yiu save
09:40 <vmassol> *you
09:40 <mflorea> I don't think we do this
09:40 <vmassol> only the modified xobject should we modified in the DB
09:40 <vmassol> not all comments
09:40 <vmassol> s/should we/should be
09:41 <mflorea> I think that in object editor all the objects are updated
09:41 <vmassol> ok I'm opening a jira issue, we probably already have one though
09:41 <mflorea> when you save, because the entire HTML form (with all the fields for each object) is submitted
09:41 <Trefex> has joined #xwiki
09:42 <mflorea> but from the diff it looks like the user only added some comments, so I doubt it was from object editor
09:42 <vmassol> hmm
09:42 <vmassol> I added 2 comments
09:42 <mflorea> and the add comment form shouldn't affect existing comments
09:42 <vmassol> and the link I gave you now doesn't show the issue anymore
09:43 <vmassol> why is even more weird
09:44 <vmassol> do you still have it open in ordder to take a screenshot for thr issue?
09:44 <vmassol> :)
09:44 <mflorea> yes
09:44 <vmassol> cool
09:44 <vmassol> starting issue creation
09:44 <vmassol> and you can add it once I'm done
09:46 <mflorea> yes, just give me the link
09:50 <vmassol> mflorea: http://jira.xwiki.org/browse/XWIKI-12307# could you name your file diff1.png?
09:50 <mflorea> sure
09:51 <mflorea> done
09:51 <vmassol> thx
09:53 <vmassol> mflorea: 18 test failures at http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/testReport/ For example http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/EditObjectsTest/testPropertyDisplayersForNewObjects/ doesn't seem related to the new script permissions, is it?
09:59 <gsmeria1> has quit
10:00 <gsmeria> has joined #xwiki
10:00 <mflorea> vmassol: checking
10:55 <Trefex> has quit
11:13 <gsmeria> has quit
11:16 <ClemensR> has joined #xwiki
11:30 <Enygma`> has joined #xwiki
11:35 <spawn57> has joined #xwiki
11:36 <spawn57> Hi, For the share page by email feature. Is it possible to customise the email template?
11:39 <vmassol> spawn57: yes
11:39 <vmassol> it's located in XWiki.SharePage AFAIR
11:39 <vmassol> yep that's it (just checked)
11:40 <vmassol> so you edit that page using the object editor and you can customize the template
11:40 <spawn57> thanks!
11:41 <vmassol> added quickly here FYI: http://extensions.xwiki.org/xwiki/bin/view/Extension/Share+Page+Application#HConfiguretheMailTemplate
11:47 <Trefex> has joined #xwiki
11:59 <evalica> has joined #xwiki
12:03 <woshilapin> Hi here, I will probably ask a dumb question but I'd like to understand anyway...
12:03 <woshilapin> To Inject a component, I have 3 ways:
12:03 <woshilapin> - @Inject
12:03 <woshilapin> - Utils.getComponent
12:03 <woshilapin> - Creating a provider
12:03 <woshilapin> Right?
12:04 <woshilapin> If yes, I'd like to understand the difference between the last 2
12:05 <woshilapin> (because second is one-line, and for the third, you have to inject a provider, and then use it, so it's more 2 lines (3 with the @Inject))
12:10 <vmassol> no
12:10 <vmassol> well
12:10 <vmassol> :)
12:10 <woshilapin> :-)
12:10 <vmassol> Utils is a hack
12:10 <vmassol> to access components from a non component world
12:11 <woshilapin> OK, so the nice way is the provider...
12:11 <vmassol> provider is for factories
12:11 <woshilapin> Yes, but I guess that if @Singleton...
12:11 <vmassol> to inject a component there's only a single way
12:11 <vmassol> @Inject
12:11 <woshilapin> OK, let me explain my problem with @Inject
12:12 <vmassol> actually there are 2 ways
12:12 <woshilapin> (and be sure that architecture is probably not perfect)
12:12 <vmassol> the second way is to sue the CM
12:12 <cjd> If there are 2 ways to do something which are functionally equivilant, always prefer the one which requires typing more code
12:12 <cjd> <trollface>
12:13 <woshilapin> I inherit from a class that contains an attribute (and I want parent class to not depend on components which means annotations and stuff)
12:13 <vmassol> woshilapin: you read http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module right?
12:13 <woshilapin> And in the child class, I'd like to inject this attribute, (potentially different hint in different implementations)
12:13 <vmassol> BTW Provider *is* a component
12:14 <vmassol> you also @Inject it
12:14 <woshilapin> Yes, but that I would use in the child which is fine
12:14 <vmassol> I think your question is whether we support constructor injection and the answer is no
12:15 <woshilapin> Then I'll try to understand my question first :-P
12:15 <vmassol> so you have to pass what you need to your POJO so that it can find other components
12:15 <vmassol> either passing the components it needs in its constructor or passing the CM instance
12:15 <vmassol> (if I understand your need ;))
12:16 <woshilapin> Yes, call Utils.getComponent in the constructor would be my solution but as far as I understand, it doesn't work
12:17 <woshilapin> (and then, I guess, I understand my question, right?)
12:17 <vmassol> don't use Utils if you can avoid it
12:17 <vmassol> just pass the component you need
12:17 <woshilapin> (yes, it was shorter to write but I would use provider)
12:17 <cjd> initialize() { super.setWhateverAttribute(this.injectedAttributeThingy); }
12:17 <vmassol> inversion of control
12:17 <cjd> initialize is called after injections are complet
12:17 <woshilapin> Yes, that what Fabio suggested me, but I was trying to understand really the problem :-)
12:18 <woshilapin> extends Initializable and then define initialize() method seems to be my solution then
12:18 <cjd> the CM will create the object, then it will reflect the private fields and put the stuff in them according to the @Inject annoatations
12:18 <woshilapin> (or implements Initializable...)
12:18 <cjd> then it will look for an initialize() and call it if it exists
12:18 <vmassol> so your use case is to provision a POJO, right?
12:19 <vmassol> so indeed 2 choices:
12:19 <vmassol> 1) Implement a Provider to return a provisioned POJO
12:19 <vmassol> 2) Pass whatever the POJO needs in its constructor (ie all components it needs)
12:19 <cjd> AFAICT he's trying to set some crap in the superclass
12:19 <vmassol> but evenf or 1) you'll need to do 2) ;)
12:20 <vmassol> cjd: I don't see what that has to do with components
12:20 <cjd> The component is a subclass of something which needs some customization itself
12:21 <vmassol> then yes Initializable is good for this
12:21 <cjd> he's using the Object Inheritence antipattern so he has to use a hack here
12:21 <vmassol> if you need to do that at init time and not in a lazy way
12:24 <woshilapin> OK, thanks both of you
12:24 <woshilapin> I think I'll sleep on that at lunch for now :-)
13:28 <Denis1> has joined #xwiki
13:30 <lynxt_> has joined #xwiki
13:31 <tillo_> has joined #xwiki
13:37 <Denis> has quit
13:37 <tillo> has quit
13:37 <Pbas> has quit
13:37 <Pbas> has joined #xwiki
13:37 <tillo_> is now known as <tillo>
14:09 <tmortagne> has joined #xwiki
14:18 <OSIMasson> has quit
14:36 <Ramona> has joined #xwiki
15:13 <Ramona> has quit
15:27 <OSIMasson> has joined #xwiki
15:29 <OSIMasson> has quit
15:33 <Denis1> is now known as <Denis>
15:49 <Ramona> has joined #xwiki
16:26 <OSIMasson> has joined #xwiki
16:27 <Ramona> has quit
16:28 <Denis> has quit
16:28 <Denis1> has joined #xwiki
16:31 <msmeria> has quit
17:15 <OSIMasson> has quit
17:15 <OSIMasson> has joined #xwiki
17:30 <sdumitriu> tmortagne: Question about GenericProvider https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-default/src/main/java/org/xwiki/component/embed/GenericProvider.java
17:30 <tmortagne> sdumitriu: shoot
17:30 <sdumitriu> Any reason why it uses the root component manager, and not the default one?
17:31 <sdumitriu> Wait
17:31 <sdumitriu> By default, I mean "context/root"
17:32 <tmortagne> on we don't have the same definition of root indeed :)
17:32 <tmortagne> it's using the CM from which it come from
17:33 <tmortagne> meaning that if a component installed in some wiki is responsible to asking this provider then the provider will see other components in the wiki
17:33 <tmortagne> if we force the provider to use the root CM is will only see root component
17:33 <sdumitriu> Which, for components initialized at startup, is the root component manager
17:33 <tmortagne> yes
17:34 <tmortagne> but only for them
17:34 <tmortagne> there is no reason to force the provider wherever it come from to use the root CM
17:35 <tmortagne> eventually it will end up in the root CM if it can't find anything in the current one so not sure hat is the issue exactly
17:35 <tmortagne> s/hat/what/
17:35 <sdumitriu> Here's my usecase:
17:35 <sdumitriu> @Inject Provider<List<SomeComponent>>
17:35 <sdumitriu> .get() doesn't give me components installed with the extension manager
17:36 <sdumitriu> So I had to implement my own Provider, which uses @Inject @Named("wiki") ComponentManager
17:37 <tmortagne> actually you'd probably better use the context component manager
17:37 <sdumitriu> The reason is that the component manager injected in the GenericProvider was the root one
17:37 <tmortagne> which will give you the righ SomeComponent depending on the current wiki, user etc
17:37 <tmortagne> s/SomeComponent/SomeComponents/
17:37 <sdumitriu> I thought about that, but since I use that to get some authorization modules, I don't want to use the "user" and "document" component manager
17:38 <sdumitriu> That would allow them to bypass authorization, if they're clever enough
17:38 <tmortagne> you would need PR to inject this kind of component anyway but as you like, it's better for performances anyway if wiki is enought for you
17:41 <tmortagne> so basically you initial question is why don't all Provider use the context CM or is it something else ?
17:42 <sdumitriu> Yes
17:42 <tmortagne> the exact answer would be that GenericProvider is older than the concept of context CM :) but that would certainly cover some use cases that prevent from using Providers right now
17:44 <sdumitriu> So that's something you'd consider a good improvement?
17:45 <tmortagne> we could maybe imagine support something like
17:46 <tmortagne> to be sure to not break some use case where the component really wanted the Provider to only search in its CM
17:46 <tmortagne> it's certainly a nice tool
17:46 <sdumitriu> The issue is that @Named applies to the component, not the provider
17:47 <tmortagne> right now yes, but we can probably find something
17:48 <tmortagne> either introduce a set a annotation to control GenericProvider which is too limited right now and would be nice for other use cases
17:48 <sdumitriu> We can define a new javax.inject.Qualifier
17:49 <tmortagne> javax.inject.Qualifier would be supposed to have the same logic than @Named wich is itself supposed to be just a javax.inject.Qualifier
17:49 <sdumitriu> For example @Documented @Retention(RUNTIME) @Qualifier public @interface ProviderType
17:49 <tmortagne> if we start supporting any javax.inject.Qualifier it's going to conflict
17:49 <sdumitriu> And then we can use @ProviderType("context")
17:50 <vmassol> btw on a related topic, we should seriously consider moving to CDI 2.0 which now supports JSE (and it's probably possible to do some runtime registration of beans - this is the part that needs to be researched)
17:51 <tmortagne> well we should consider moving it if there is runtime registration :)
17:51 <tmortagne> s/it/to it/
17:51 <tmortagne> without that it's pretty useless to us since we are doing that quite a lot
17:51 <vmassol> it's not built by default but I think there are options in the extensions
17:52 <tmortagne> in any case we can review CDI 2.0 annotation, there is probably some useful stuff for us we might want to support
17:52 <vmassol> yes that's got me thinking about that
17:53 <tmortagne> I remember talking about a more advanced provider with you
17:53 <vmassol> we should align our usage of annotations to the max extent
17:53 <tmortagne> (that was part of CDI)
17:54 <tmortagne> there is many things I don't like much about Provider and that could benefit from a few improvements
17:54 <vmassol> FTR https://issues.jboss.org/browse/CDI-114
18:22 <OSIMasson> has quit
18:30 <OSIMasson> has joined #xwiki
18:37 <cjd> has quit
18:52 <ClemensR> has quit
18:56 <OSIMasson> has quit
19:02 <Trefex> has quit
19:16 <mflorea> has quit
19:18 <woshilapin> has quit
19:18 <tmortagne> has quit
19:19 <evalica> has quit
19:20 <evalica> has joined #xwiki
19:20 <Enygma`> has quit
19:24 <sdumitriu1> has quit
19:24 <sdumitriu1> has joined #xwiki
19:24 <evalica> has quit
19:28 <cjd> has joined #xwiki
19:48 <gdelhumeau> has quit
20:04 <Enygma`> has joined #xwiki
20:20 <mflorea> has joined #xwiki
20:20 <woshilapin> has joined #xwiki
20:20 <Slashman> has quit
20:21 <OSIMasson> has joined #xwiki
20:48 <OSIMasson> has quit
20:52 <OSIMasson> has joined #xwiki
21:24 <risherry> has joined #xwiki
21:56 <lucaa1> has quit
22:03 <OSIMasson> has quit
22:10 <woshilapin> has quit
22:21 <lucaa> has joined #xwiki
22:27 <OSIMasson> has joined #xwiki
22:27 <KermitTheFragger> has quit
22:37 <woshilapin> has joined #xwiki
23:01 <lucaa> has quit
23:01 <lucaa> has joined #xwiki
23:23 <lynxt> has quit
23:25 <lynxt> has joined #xwiki
23:27 <lucaa> has quit
23:28 <tillo> has quit
23:29 <tillo> has joined #xwiki
23:34 <risherry> has quit
23:34 <mflorea> has quit
23:55 <vmassol> has quit
