IRC Archive for channel #xwiki on 20 April 2015
Last modified by Vincent Massol on 2015/04/20 23:27
<thomass> has joined #xwiki
02:16 <thomass> has quit
02:17 <sdumitriu1> has joined #xwiki
02:19 <thomass__> has joined #xwiki
02:19 <thomass__> has quit
02:19 <thomass> has joined #xwiki
02:22 <thomass> has quit
02:51 <Chuguniy> has quit
05:14 <sdumitriu1> has quit
06:59 <msmeria> has joined #xwiki
07:14 <DarkKnightCZ> has joined #xwiki
07:54 <woshilapin> has quit
08:19 <vmassol> has joined #xwiki
08:43 <cjd> has joined #xwiki
08:43 <woshilapin> has joined #xwiki
08:45 <martin-h> has quit
08:53 <KermitTheFragger> has joined #xwiki
08:59 <Enygma`> has joined #xwiki
09:00 <martin-h> has joined #xwiki
09:46 <lucaa> has joined #xwiki
09:54 <mflorea> has joined #xwiki
09:57 <Pbas> has joined #xwiki
10:04 <Pbas> Hello everyone, someone have some time to watch my PR for http://jira.xwiki.org/browse/XWIKI-6118 issue? Thxs
10:07 <martin-h> has quit
10:08 <vmassol> has quit
10:08 <vmassol> has joined #xwiki
10:17 <martin-h> has joined #xwiki
10:17 <Slashman> has joined #xwiki
10:54 <gsmeria> has joined #xwiki
11:09 <lucaa> has quit
11:11 <martin-h> has quit
11:11 <lucaa> has joined #xwiki
11:20 <martin-h> has joined #xwiki
12:01 <vmassol> FYI I've documented the new URL Architecture here: http://platform.xwiki.org/xwiki/bin/preview/DevGuide/URL+Architecture
12:03 <cjd> preview link
12:03 <cjd> http://platform.xwiki.org/xwiki/bin/view/DevGuide/URL+Architecture
12:05 <cjd> looks nice
12:06 <vmassol> indeed, thanks for fixing the link
12:07 <cjd> So I can just URLHandler.map("/cjd/", functionWrappedInObjectBecauseJavaDoesNotSupportFirstClassFunctions); ?
12:07 <cjd> or URLHandler.map("/cjd/", myServlet) ?
12:07 <vmassol> cjd: yes, not a servlet though, a component class
12:08 <cjd> you register a class?
12:08 <cjd> as opposed to an object?
12:08 <vmassol> cjd: http://extensions.xwiki.org/xwiki/bin/view/Extension/Resource+API#HAddinganewResourceTypeHandler
12:09 <cjd> ahh no it's an object
12:09 <cjd> why this? public static final ResourceType TYPE = new ResourceType("webjars");
12:10 <cjd> instead of using: @Named("webjars")
12:10 <vmassol> it's not instead
12:10 <vmassol> it's in addition
12:10 <vmassol> you have to implement getSupportedResourceReferences()
12:10 <cjd> can I leave out the public static final ResourceType TYPE = new ResourceType("webjars"); and public List<ResourceType> getSupportedResourceReferences() and have it just use @Named() ?
12:11 <vmassol> no
12:11 <vmassol> getSupportedResourceReferences() is in the interface
12:11 <vmassol> actually I need to change that name it's not correct… should getSupportedResourceReferenceTypes()
12:11 <vmassol> it's all the types supported by this handler
12:12 <cjd> yeah, getSupportedResourceReferences is too short :P
12:12 <vmassol> indeed
12:13 <cjd> shouldn't AbstractResourceReferenceHandler be clever enough to introspect it's class, get the name and provide a default implementation of getSupportedResourceReferences ?
12:13 <cjd> *get the @Named() name
12:13 <vmassol> first a component currently doesn't have access to its metadata. I wanted to implement that but I don't think I've done it yet
12:14 <vmassol> actually maybe I did, I don't remember :)
12:14 <cjd> hmm
12:14 <vmassol> checking quickly
12:14 <vmassol> it's done ;)
12:15 <vmassol> @Inject private ComponentDescriptor descriptor:
12:15 <vmassol> so it's possible indeed to implement a default
12:15 <evalica> has joined #xwiki
12:16 <cjd> String tryThis() { return this.getClass().getAnnotation(Named.class).value }
12:16 <cjd> in the abstract superclass
12:16 <cjd> that should do the trick
12:16 <vmassol> that's really bad
12:16 <vmassol> and hackish
12:16 <cjd> objective fact or personal opinion?
12:17 <vmassol> for at least 2 reasons: it creates a link with the annotation name and it works only for components registered with annotations
12:17 <vmassol> (it'll fail if you register a component dynamically against the CM)
12:17 <vmassol> @Inject private ComponentDescriptor descriptor: is made for this
12:17 <cjd> reason #2 makes sense
12:18 <cjd> but then your impl is no better because it hardcodes the thing into the class
12:18 <cjd> so registering it dynamically will never work
12:19 <cjd> so actually given reason #2, it seems it is highly valuable to be able to use the metadata :)
12:19 <DarkKnightCZ> has quit
12:58 <DarkKnightCZ> has joined #xwiki
12:58 <vmassol> cjd: you're confusing things. getSupportedResourceReferences() should never be dynamic, that would be plain wrong since the handle() method needs to handle it
12:59 <DarkKnightCZ> has quit
13:01 <vmassol> (the dynamic part is only for the registration of the component)
13:38 <Denis1> has joined #xwiki
13:38 <Denis1> is now known as <Denis>
13:41 <cjd> vmassol: it's either one or the other, if hardcoding it in the @Named() is no good then neither is hardcoding it in the public static final ResourceType TYPE field.
13:41 <vmassol> you still don't get it :)
13:41 <cjd> hehe
13:42 <cjd> yeah, I think I understand
13:42 <vmassol> annotations are only statically to register components
13:42 <vmassol> when you register a component dynamocally (ie at runtime)
13:42 <vmassol> then annotations are not used
13:42 <vmassol> you provide a component descriptor to perform the registration
13:42 <vmassol> thus if there's some code in a component that assume that an annotation exists, it'll fail
13:43 <vmassol> or you'll need to maintain both places: i.e. the annotation + the component desciprtor
13:43 <cjd> however, it does help to once in a while admit that you are wrong because statistically everyone is wrong sometimes so if someone never admits that their idea was bunk, the default assumption has to be that they will never accept that anything they did was a bad idea
13:43 <vmassol> sorry what's the question? :)
13:44 <vmassol> (to which i need to admit that I was wrong)
13:44 <cjd> No offense or anything, just that if I have good memories of you saying "oops no, that was a bad idea, I will revert" then I will listen to your arguments more carefully
13:44 <vmassol> not srue what you're getting at
13:45 <vmassol> I think you've not read me corretly
13:45 <vmassol> read above
13:45 <vmassol> and look for th place that says that "I agree that we could do this"
13:45 <vmassol> now I cannot agree to all the things you said that are not correct obviously so I cannot agree to everything ;)
13:46 <cjd> haha I like that line
13:46 <vmassol> the line was "so it's possible indeed to implement a default"
13:46 <vmassol> if that's your question
13:46 <vmassol> again I'm unclear to what I should recognize that I was wrong here
13:47 <cjd> maybe you're exactly right
13:47 <vmassol> FTR I'm wrong several times a day :)
13:47 <vmassol> if the question is: we should read the @Named annotation in the component code, than I maintain that it's a terrible idea :)
13:47 <vmassol> *then
13:48 <cjd> well argument #2 doesn't exactly hold because we're not going to be dynamically registering anyway
13:48 <cjd> I mean we might but using a statically defined field is the same as a statically defined annotation
13:48 <vmassol> so your point is that parsing manually the @Named annotation is better than using the @Inject ComponentDescriptor?
13:49 <vmassol> (as you can see i'm really confused by what you're trying to prove here)
13:50 <vmassol> btw
13:50 <cjd> well @Named() is nicer for the end user (developer)
13:50 <vmassol> the @Named annotation value has nothing to see with the Resource Types that should be handled :)
13:51 <cjd> because it "just works" unless they override it
13:51 <vmassol> it just happens in this specific example I gave that I've used the same value but it's pure coincidence
13:51 <vmassol> cjd: @Inject ComponentDescriptor just works
13:51 <vmassol> (for all cases)
13:52 <vmassol> except that it's bad idea I think because the Resource Types and the component hint are othogonal
13:52 <cjd> I think that statement requires justification
13:53 <cjd> they're two strings, each of which are in a collision domain, so if url component collides or if CM name collides, badThings(tm)
13:53 <cjd> merging them seems a logical thing to do unless there is solid reason to avoid it
13:54 <vmassol> need to check something in the code, I don't remember how I do something and I might have a bug
13:55 <cjd> I would go as far as to say that one *must* be the same as the other, and if there needs to be multiple then we'll handle that bridge when we burn it
13:56 <martin-h> has quit
13:57 <vmassol> no it works, pfew :)
13:57 <vmassol> so I confirm that the resource handler component hint has nothing to do with handled resource types
13:58 <vmassol> the hint uses by a resource handler component is just a unique name that is not used, meant to differentiate it from other components implementing the same role interfgace
13:58 <vmassol> *interface
13:58 <vmassol> what's important is getSupportedResourceReferences()
13:58 <vmassol> and this is what tells the ResourceHandlerManager component what a given Resource Handler can handle
13:59 <cjd> I don't see any reason not to link SRRT's and hint name, doing so is Convention over Configuration
14:00 <cjd> "works by default"
14:00 <vmassol> the reason is that they're completely orthogonal so there's no reason to use it for that
14:00 <vmassol> that's why there's a getSupportedResourceReferences() method
14:01 <cjd> 13:59 <@vmassol> the reason is that ... there's no reason <-- I understand you but "no reason is the reason" is not the most compelling argument
14:02 <vmassol> it's the opposite caleb
14:02 <vmassol> when you wish to related 2 unrelated stuff you need a strong argument
14:02 <vmassol> *relate
14:02 <vmassol> linking them would just create confusion and imply they're lated
14:02 <vmassol> $related
14:02 <vmassol> *related
14:02 <cjd> the relationship is they're both identifiers for the same object
14:03 <vmassol> I personnally prefer clarity ad 3 more lines
14:03 <vmassol> *and
14:03 <vmassol> btw
14:04 <vmassol> we could imagine
14:04 <vmassol> an improvement in the Component Manager
14:04 <vmassol> so that we don't have to use a @Named if we don't care about it
14:04 <vmassol> and internally the CM would just use some random id
14:04 <martin-h> has joined #xwiki
14:05 <cjd> anonymous components?
14:05 <vmassol> (we would need a standard for the default hint though - Sergiu had a proposal for this too)
14:05 <vmassol> yes something like that
14:05 <cjd> at first glance that sounds like a sort of memory leak factory
14:05 <vmassol> :)
14:06 <vmassol> I tend to agree :)
14:06 <cjd> ahh, you're picking up the trick ;)
14:07 <Slashman> has quit
14:28 <Trefex> has joined #xwiki
14:28 <Slashman> has joined #xwiki
14:50 <woshilapin> Hi devs, I'm currently working with the packager plugin which is great
14:51 <woshilapin> I'm wondering if I can also configure some of the XWiki properties
14:51 <woshilapin> like superadmin password for example
14:51 <woshilapin> This is my POM at the moment
14:51 <woshilapin> https://ezcrypt.it/RqAn#h854PuPTfnz2PWxU0BoljT2m
14:52 <vmassol> woshilapin: hi
14:52 <vmassol> yes you can pass the superadmin password
14:52 <woshilapin> Hi vmassol, how can I do that in the pom.xml
14:53 <vmassol> you should check xwiki.cfg.vm
14:53 <woshilapin> Because I'm not sure where to look to find the information
14:53 <vmassol> and any property in there can be defined in your pom.xml
14:53 <woshilapin> as <property> ?
14:53 <vmassol> for example you'll see:
14:53 <vmassol> xwiki.superadminpassword=$xwikiCfgSuperadminPassword
14:53 <vmassol> which means you can have in your pom, inside <properties>:
14:54 <vmassol> <xwikiCfgSuperadminPassword>pass</xwikiCfgSuperadminPassword>
14:54 <vmassol> (for eample)
14:54 <vmassol> *example
14:54 <woshilapin> OK, I'll try that
14:54 <woshilapin> Thanks
14:54 <vmassol> if you need to check the code it's in PackageMojo.java in createVelocityContext()
14:55 <woshilapin> OK
14:55 <vmassol> woshilapin: here's an example: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-activeinstalls/xwiki-platform-activeinstalls-test/xwiki-platform-activeinstalls-test-tests/pom.xml
14:56 <woshilapin> Yes, I found them but when I tried, it doesn't work
14:56 <woshilapin> So I'll retry harder, making sure I've not done something wrong :-)
15:04 <msmeria> has quit
15:04 <woshilapin> OK, I made a guess on Maven which was not true (I put the property in the parent POM of the distribution I was trying to compile, I thought that the property was transfer to all childs POM)
15:05 <woshilapin> tl;dr; It works, thanks
15:05 <vmassol> cool
15:05 <vmassol> you can configure this
15:05 <vmassol> any property is inherited from parent
15:05 <vmassol> but
15:05 <vmassol> if you redefine it in the children you need to tell maven if it needs to also merge parent stuff
15:05 <vmassol> by default it overwrites, not merge
15:06 <woshilapin> It was not defined in the child, only in the parent
15:06 <vmassol> to merge you need to specify: combine.children="append"
15:06 <woshilapin> Anyway, I had also another thing that may have cause the problem
15:06 <vmassol> if it's in the parent then it's inherited
15:06 <vmassol> you can verify with
15:06 <vmassol> mvn help:effective-pom
15:06 <woshilapin> ok
15:10 <woshilapin> ok, inheritence works well (I've just made other mistakes before)
15:10 <woshilapin> :-)
15:10 <woshilapin> Now, I'll use the packager on other projects :-)
15:10 <vmassol> ok cool
15:20 <sdumitriu1> has joined #xwiki
15:24 <Pbas> has quit
15:51 <gsmeria> has quit
16:15 <Pbas> has joined #xwiki
16:47 <gsmeria> has joined #xwiki
16:51 <vmassol> just updated (and simplified) the Architecture page at http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture
16:51 <vmassol> I hope you like it
16:52 <vmassol> (some diagrams would be nice)
17:09 <cjd> vmassol: do you know if XWiki Rights system fits the definition of NIST Role Based Access Control ?
17:09 <cjd> because it seems to from looking at the spec
17:12 <vmassol> cjd: no idea. I don't know this concept of NIST RBAC
17:12 <vmassol> I'm pretty sure it wasn't designed to be
17:12 <cjd> well... I think we reinvented it xD
17:12 <cjd> RBAC defines Subject, Role and Operation to be definable (subject is user)
17:13 <vmassol> we don't have Roles ATM
17:13 <vmassol> only groups
17:13 <cjd> do you know what is the difference?
17:13 <cjd> because I could not find one
17:14 <vmassol> for example JIRA uses both
17:14 <cjd> we have User, Group and a set of hardcoded operations (view,register,admin) which would seem to be in violation of the configurable consept of Operation, however our groups can contain groups so we can do wildly complex things fairly easily
17:15 <vmassol> we discussed roles in th past AFAIR
17:15 <MasterPiece> has joined #xwiki
17:15 <cjd> if there's a fundimental difference between a group and a role (at the enforcement engine level) then of course we need to implement them but if there isn't then that could be interesting
17:16 <cjd> NIST compliance with only changing a user interface component
17:17 <cjd> if people are looking to buy NIST compliance, 64mn$ question :)
17:17 <vmassol> would need to read again this thread: http://markmail.org/message/qlfwaze47bq3gtrh
17:17 <cjd> mmm thanks
17:18 <cjd> Denis's engine seems to be fast and is getting stable so it might be time to start really showcasing our permissions infra
17:18 <vmassol> would be nice to have the redesigned Rights UI to showcase it
17:18 <vmassol> http://design.xwiki.org/xwiki/bin/view/Improvements/Rights3AProposal shows some roles
17:21 <Denis> all this remind me that we have never inverted the way implied rights are provided (actually the resposibility of the implying right in place of being the one of the implied right)
17:22 <cjd> I don't understand, can you give an example ?
17:25 <Denis> actually, admin right implies view, edit, …, and this is the admin right that define that once for all, would be better if the view (edit, …) rights tells it is implied when you has admin right
17:25 <cjd> ahh ok, so mostly an internal matter
17:26 <Denis> no so internal, since actually you cannot add a new right that gets implied by admin right
17:26 <cjd> hmm I see
17:26 <Denis> since you may dynamically add right with a simple extension, it is a bit annoying
17:27 <cjd> adding new rights could be interesting because we could do hasAccessLevel() on them in code
17:27 <Denis> I realize this design fault too late, it was in the initial design from Andrea, and I have not catch it
17:28 <Denis> adding new right works, but adding those right as implied to other existing one don't
17:28 <cjd> /nod how about adding rights without writing any code ?
17:29 <cjd> Right Within Minutes ?
17:29 <Denis> you just have to register them, it is declarative
17:29 <cjd> so we could imagine a right registerer which runs a query for XObjects of a certain type and registers them all
17:29 <Denis> now, the UI should be adapted to use them of course
17:30 <Denis> you could, yes
17:31 <Denis> there is a hard limit however, of 64 rights registered in given running JVM
17:32 <Denis> you can unregister and re-register the same right many times, but only 64 at most
17:32 <Denis> 64 different right at most
17:32 <vmassol> this is just an impl limitation AFAIK Denis, right?
17:32 <Denis> yes
17:32 <vmassol> (bit shitfing or something like this
17:32 <vmassol> )
17:33 <Denis> bit storing
17:34 <Denis> bit get allocated on the fly, but forever for a given right during a given run
17:34 <cjd> it's certainly clever
17:34 <Denis> while a impl limitation, it is also important for performance
17:35 <Denis> IMO, 64 right for a human, is a lot !
17:35 <Denis> (I mean in term of management)
17:35 <cjd> paranoia knows no bounds ;)
17:36 <Bugen_do> has joined #xwiki
17:36 <cjd> does it precalculate the permission/user matrix in advance, collapsing all of the groups ?
17:36 <cjd> aka is isUserInGroup() still expensive ?
17:37 <vmassol> reminds me of all the prophecies around memory or computers….
17:37 <vmassol> like there be no more than 10 computers needed in all the world
17:37 <cjd> it should be no real problem to fix, we'll just start using a proper bitset
17:38 <cjd> which is backed by an array of int64
17:38 <cjd> so it expands as needed
17:39 <Denis> well, there is several level of optimizations, if you want to know more, a call could be faster :)
17:41 <cjd> I don't want to waste too much time unless we have decided we want to do something
17:45 <cjd> anyway a concrete question is "from a performance point of view, should I prefer to define a new right over creating a group and checking permission in the code using isUserInGroup() ?"
17:47 <Denis> The answer is not so simple, but it is a balance. To explain it fast, all rights (the bitset) are evaluated all at the same time for a given user/entity relation. The cache store the hierarchy of involved rules see so far, the user and group membership of involved user so far, and the evaluated bitsets.
17:47 <Denis> So asking a different right for the same couple, is a cache hit
17:48 <cjd> ok
17:48 <Denis> asking a document in the same space, will only require rules from that document, and a new eval, while the rest will came from the cache
17:49 <cjd> so we can implement "pseudo-rights" using groups and then checking isUserInGroup() without an enormous perf hit ?
17:49 <Denis> but at the same time, changing the XWiki.XWikiPreferences document, will lead in a full cache flush !
17:49 <cjd> which is fine because it never happens :)
17:50 <Denis> isUserInGroup() does not involve the security module at all, and I doubt it works properly
17:50 <Denis> I mean it only check the group, not sub groups
17:50 <cjd> ok so then it's certainly a database hit so we should avoid it
17:50 <Denis> there is an old group cache
17:51 <cjd> ok then we should put a /!\DANGER/!\ flag over that one :)
17:51 <Denis> that is still very useful anyway, since the security cache does not old the whole picture
17:51 <cjd> ok
17:51 <cjd> thanks
17:52 <Denis> the GroupService which use that group cache does not manage group in groups
17:52 <Denis> it just report gourps in groups as being members like uses
17:52 <Denis> s/uses/users
17:52 <cjd> oh actually we can create a faux document for representing a right, weird as it is
17:53 <cjd> if you can view document X, code in document Y will let you pass
17:53 <cjd> anyway I'll stop wasting your time, thanks for the explanation.
17:53 <Denis> quite efficient indeed, but really weird
17:58 <KermitTheFragger> has quit
18:15 <Trefex> has quit
18:28 <cjd> has quit
19:02 <lucaa> has quit
19:17 <Slashman> has quit
19:32 <Slashman> has joined #xwiki
20:02 <Slashman> has quit
20:30 <vmassol> has quit
21:22 <Bugen_do> has quit
22:52 <gsmeria> has quit
22:52 <mflorea> has quit
23:27 <evalica> has quit
02:16 <thomass> has quit
02:17 <sdumitriu1> has joined #xwiki
02:19 <thomass__> has joined #xwiki
02:19 <thomass__> has quit
02:19 <thomass> has joined #xwiki
02:22 <thomass> has quit
02:51 <Chuguniy> has quit
05:14 <sdumitriu1> has quit
06:59 <msmeria> has joined #xwiki
07:14 <DarkKnightCZ> has joined #xwiki
07:54 <woshilapin> has quit
08:19 <vmassol> has joined #xwiki
08:43 <cjd> has joined #xwiki
08:43 <woshilapin> has joined #xwiki
08:45 <martin-h> has quit
08:53 <KermitTheFragger> has joined #xwiki
08:59 <Enygma`> has joined #xwiki
09:00 <martin-h> has joined #xwiki
09:46 <lucaa> has joined #xwiki
09:54 <mflorea> has joined #xwiki
09:57 <Pbas> has joined #xwiki
10:04 <Pbas> Hello everyone, someone have some time to watch my PR for http://jira.xwiki.org/browse/XWIKI-6118 issue? Thxs
10:07 <martin-h> has quit
10:08 <vmassol> has quit
10:08 <vmassol> has joined #xwiki
10:17 <martin-h> has joined #xwiki
10:17 <Slashman> has joined #xwiki
10:54 <gsmeria> has joined #xwiki
11:09 <lucaa> has quit
11:11 <martin-h> has quit
11:11 <lucaa> has joined #xwiki
11:20 <martin-h> has joined #xwiki
12:01 <vmassol> FYI I've documented the new URL Architecture here: http://platform.xwiki.org/xwiki/bin/preview/DevGuide/URL+Architecture
12:03 <cjd> preview link
12:03 <cjd> http://platform.xwiki.org/xwiki/bin/view/DevGuide/URL+Architecture
12:05 <cjd> looks nice
12:06 <vmassol> indeed, thanks for fixing the link
12:07 <cjd> So I can just URLHandler.map("/cjd/", functionWrappedInObjectBecauseJavaDoesNotSupportFirstClassFunctions); ?
12:07 <cjd> or URLHandler.map("/cjd/", myServlet) ?
12:07 <vmassol> cjd: yes, not a servlet though, a component class
12:08 <cjd> you register a class?
12:08 <cjd> as opposed to an object?
12:08 <vmassol> cjd: http://extensions.xwiki.org/xwiki/bin/view/Extension/Resource+API#HAddinganewResourceTypeHandler
12:09 <cjd> ahh no it's an object
12:09 <cjd> why this? public static final ResourceType TYPE = new ResourceType("webjars");
12:10 <cjd> instead of using: @Named("webjars")
12:10 <vmassol> it's not instead
12:10 <vmassol> it's in addition
12:10 <vmassol> you have to implement getSupportedResourceReferences()
12:10 <cjd> can I leave out the public static final ResourceType TYPE = new ResourceType("webjars"); and public List<ResourceType> getSupportedResourceReferences() and have it just use @Named() ?
12:11 <vmassol> no
12:11 <vmassol> getSupportedResourceReferences() is in the interface
12:11 <vmassol> actually I need to change that name it's not correct… should getSupportedResourceReferenceTypes()
12:11 <vmassol> it's all the types supported by this handler
12:12 <cjd> yeah, getSupportedResourceReferences is too short :P
12:12 <vmassol> indeed
12:13 <cjd> shouldn't AbstractResourceReferenceHandler be clever enough to introspect it's class, get the name and provide a default implementation of getSupportedResourceReferences ?
12:13 <cjd> *get the @Named() name
12:13 <vmassol> first a component currently doesn't have access to its metadata. I wanted to implement that but I don't think I've done it yet
12:14 <vmassol> actually maybe I did, I don't remember :)
12:14 <cjd> hmm
12:14 <vmassol> checking quickly
12:14 <vmassol> it's done ;)
12:15 <vmassol> @Inject private ComponentDescriptor descriptor:
12:15 <vmassol> so it's possible indeed to implement a default
12:15 <evalica> has joined #xwiki
12:16 <cjd> String tryThis() { return this.getClass().getAnnotation(Named.class).value }
12:16 <cjd> in the abstract superclass
12:16 <cjd> that should do the trick
12:16 <vmassol> that's really bad
12:16 <vmassol> and hackish
12:16 <cjd> objective fact or personal opinion?
12:17 <vmassol> for at least 2 reasons: it creates a link with the annotation name and it works only for components registered with annotations
12:17 <vmassol> (it'll fail if you register a component dynamically against the CM)
12:17 <vmassol> @Inject private ComponentDescriptor descriptor: is made for this
12:17 <cjd> reason #2 makes sense
12:18 <cjd> but then your impl is no better because it hardcodes the thing into the class
12:18 <cjd> so registering it dynamically will never work
12:19 <cjd> so actually given reason #2, it seems it is highly valuable to be able to use the metadata :)
12:19 <DarkKnightCZ> has quit
12:58 <DarkKnightCZ> has joined #xwiki
12:58 <vmassol> cjd: you're confusing things. getSupportedResourceReferences() should never be dynamic, that would be plain wrong since the handle() method needs to handle it
12:59 <DarkKnightCZ> has quit
13:01 <vmassol> (the dynamic part is only for the registration of the component)
13:38 <Denis1> has joined #xwiki
13:38 <Denis1> is now known as <Denis>
13:41 <cjd> vmassol: it's either one or the other, if hardcoding it in the @Named() is no good then neither is hardcoding it in the public static final ResourceType TYPE field.
13:41 <vmassol> you still don't get it :)
13:41 <cjd> hehe
13:42 <cjd> yeah, I think I understand
13:42 <vmassol> annotations are only statically to register components
13:42 <vmassol> when you register a component dynamocally (ie at runtime)
13:42 <vmassol> then annotations are not used
13:42 <vmassol> you provide a component descriptor to perform the registration
13:42 <vmassol> thus if there's some code in a component that assume that an annotation exists, it'll fail
13:43 <vmassol> or you'll need to maintain both places: i.e. the annotation + the component desciprtor
13:43 <cjd> however, it does help to once in a while admit that you are wrong because statistically everyone is wrong sometimes so if someone never admits that their idea was bunk, the default assumption has to be that they will never accept that anything they did was a bad idea
13:43 <vmassol> sorry what's the question? :)
13:44 <vmassol> (to which i need to admit that I was wrong)
13:44 <cjd> No offense or anything, just that if I have good memories of you saying "oops no, that was a bad idea, I will revert" then I will listen to your arguments more carefully
13:44 <vmassol> not srue what you're getting at
13:45 <vmassol> I think you've not read me corretly
13:45 <vmassol> read above
13:45 <vmassol> and look for th place that says that "I agree that we could do this"
13:45 <vmassol> now I cannot agree to all the things you said that are not correct obviously so I cannot agree to everything ;)
13:46 <cjd> haha I like that line
13:46 <vmassol> the line was "so it's possible indeed to implement a default"
13:46 <vmassol> if that's your question
13:46 <vmassol> again I'm unclear to what I should recognize that I was wrong here
13:47 <cjd> maybe you're exactly right
13:47 <vmassol> FTR I'm wrong several times a day :)
13:47 <vmassol> if the question is: we should read the @Named annotation in the component code, than I maintain that it's a terrible idea :)
13:47 <vmassol> *then
13:48 <cjd> well argument #2 doesn't exactly hold because we're not going to be dynamically registering anyway
13:48 <cjd> I mean we might but using a statically defined field is the same as a statically defined annotation
13:48 <vmassol> so your point is that parsing manually the @Named annotation is better than using the @Inject ComponentDescriptor?
13:49 <vmassol> (as you can see i'm really confused by what you're trying to prove here)
13:50 <vmassol> btw
13:50 <cjd> well @Named() is nicer for the end user (developer)
13:50 <vmassol> the @Named annotation value has nothing to see with the Resource Types that should be handled :)
13:51 <cjd> because it "just works" unless they override it
13:51 <vmassol> it just happens in this specific example I gave that I've used the same value but it's pure coincidence
13:51 <vmassol> cjd: @Inject ComponentDescriptor just works
13:51 <vmassol> (for all cases)
13:52 <vmassol> except that it's bad idea I think because the Resource Types and the component hint are othogonal
13:52 <cjd> I think that statement requires justification
13:53 <cjd> they're two strings, each of which are in a collision domain, so if url component collides or if CM name collides, badThings(tm)
13:53 <cjd> merging them seems a logical thing to do unless there is solid reason to avoid it
13:54 <vmassol> need to check something in the code, I don't remember how I do something and I might have a bug
13:55 <cjd> I would go as far as to say that one *must* be the same as the other, and if there needs to be multiple then we'll handle that bridge when we burn it
13:56 <martin-h> has quit
13:57 <vmassol> no it works, pfew :)
13:57 <vmassol> so I confirm that the resource handler component hint has nothing to do with handled resource types
13:58 <vmassol> the hint uses by a resource handler component is just a unique name that is not used, meant to differentiate it from other components implementing the same role interfgace
13:58 <vmassol> *interface
13:58 <vmassol> what's important is getSupportedResourceReferences()
13:58 <vmassol> and this is what tells the ResourceHandlerManager component what a given Resource Handler can handle
13:59 <cjd> I don't see any reason not to link SRRT's and hint name, doing so is Convention over Configuration
14:00 <cjd> "works by default"
14:00 <vmassol> the reason is that they're completely orthogonal so there's no reason to use it for that
14:00 <vmassol> that's why there's a getSupportedResourceReferences() method
14:01 <cjd> 13:59 <@vmassol> the reason is that ... there's no reason <-- I understand you but "no reason is the reason" is not the most compelling argument
14:02 <vmassol> it's the opposite caleb
14:02 <vmassol> when you wish to related 2 unrelated stuff you need a strong argument
14:02 <vmassol> *relate
14:02 <vmassol> linking them would just create confusion and imply they're lated
14:02 <vmassol> $related
14:02 <vmassol> *related
14:02 <cjd> the relationship is they're both identifiers for the same object
14:03 <vmassol> I personnally prefer clarity ad 3 more lines
14:03 <vmassol> *and
14:03 <vmassol> btw
14:04 <vmassol> we could imagine
14:04 <vmassol> an improvement in the Component Manager
14:04 <vmassol> so that we don't have to use a @Named if we don't care about it
14:04 <vmassol> and internally the CM would just use some random id
14:04 <martin-h> has joined #xwiki
14:05 <cjd> anonymous components?
14:05 <vmassol> (we would need a standard for the default hint though - Sergiu had a proposal for this too)
14:05 <vmassol> yes something like that
14:05 <cjd> at first glance that sounds like a sort of memory leak factory
14:05 <vmassol> :)
14:06 <vmassol> I tend to agree :)
14:06 <cjd> ahh, you're picking up the trick ;)
14:07 <Slashman> has quit
14:28 <Trefex> has joined #xwiki
14:28 <Slashman> has joined #xwiki
14:50 <woshilapin> Hi devs, I'm currently working with the packager plugin which is great
14:51 <woshilapin> I'm wondering if I can also configure some of the XWiki properties
14:51 <woshilapin> like superadmin password for example
14:51 <woshilapin> This is my POM at the moment
14:51 <woshilapin> https://ezcrypt.it/RqAn#h854PuPTfnz2PWxU0BoljT2m
14:52 <vmassol> woshilapin: hi
14:52 <vmassol> yes you can pass the superadmin password
14:52 <woshilapin> Hi vmassol, how can I do that in the pom.xml
14:53 <vmassol> you should check xwiki.cfg.vm
14:53 <woshilapin> Because I'm not sure where to look to find the information
14:53 <vmassol> and any property in there can be defined in your pom.xml
14:53 <woshilapin> as <property> ?
14:53 <vmassol> for example you'll see:
14:53 <vmassol> xwiki.superadminpassword=$xwikiCfgSuperadminPassword
14:53 <vmassol> which means you can have in your pom, inside <properties>:
14:54 <vmassol> <xwikiCfgSuperadminPassword>pass</xwikiCfgSuperadminPassword>
14:54 <vmassol> (for eample)
14:54 <vmassol> *example
14:54 <woshilapin> OK, I'll try that
14:54 <woshilapin> Thanks
14:54 <vmassol> if you need to check the code it's in PackageMojo.java in createVelocityContext()
14:55 <woshilapin> OK
14:55 <vmassol> woshilapin: here's an example: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-activeinstalls/xwiki-platform-activeinstalls-test/xwiki-platform-activeinstalls-test-tests/pom.xml
14:56 <woshilapin> Yes, I found them but when I tried, it doesn't work
14:56 <woshilapin> So I'll retry harder, making sure I've not done something wrong :-)
15:04 <msmeria> has quit
15:04 <woshilapin> OK, I made a guess on Maven which was not true (I put the property in the parent POM of the distribution I was trying to compile, I thought that the property was transfer to all childs POM)
15:05 <woshilapin> tl;dr; It works, thanks
15:05 <vmassol> cool
15:05 <vmassol> you can configure this
15:05 <vmassol> any property is inherited from parent
15:05 <vmassol> but
15:05 <vmassol> if you redefine it in the children you need to tell maven if it needs to also merge parent stuff
15:05 <vmassol> by default it overwrites, not merge
15:06 <woshilapin> It was not defined in the child, only in the parent
15:06 <vmassol> to merge you need to specify: combine.children="append"
15:06 <woshilapin> Anyway, I had also another thing that may have cause the problem
15:06 <vmassol> if it's in the parent then it's inherited
15:06 <vmassol> you can verify with
15:06 <vmassol> mvn help:effective-pom
15:06 <woshilapin> ok
15:10 <woshilapin> ok, inheritence works well (I've just made other mistakes before)
15:10 <woshilapin> :-)
15:10 <woshilapin> Now, I'll use the packager on other projects :-)
15:10 <vmassol> ok cool
15:20 <sdumitriu1> has joined #xwiki
15:24 <Pbas> has quit
15:51 <gsmeria> has quit
16:15 <Pbas> has joined #xwiki
16:47 <gsmeria> has joined #xwiki
16:51 <vmassol> just updated (and simplified) the Architecture page at http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture
16:51 <vmassol> I hope you like it
16:52 <vmassol> (some diagrams would be nice)
17:09 <cjd> vmassol: do you know if XWiki Rights system fits the definition of NIST Role Based Access Control ?
17:09 <cjd> because it seems to from looking at the spec
17:12 <vmassol> cjd: no idea. I don't know this concept of NIST RBAC
17:12 <vmassol> I'm pretty sure it wasn't designed to be
17:12 <cjd> well... I think we reinvented it xD
17:12 <cjd> RBAC defines Subject, Role and Operation to be definable (subject is user)
17:13 <vmassol> we don't have Roles ATM
17:13 <vmassol> only groups
17:13 <cjd> do you know what is the difference?
17:13 <cjd> because I could not find one
17:14 <vmassol> for example JIRA uses both
17:14 <cjd> we have User, Group and a set of hardcoded operations (view,register,admin) which would seem to be in violation of the configurable consept of Operation, however our groups can contain groups so we can do wildly complex things fairly easily
17:15 <vmassol> we discussed roles in th past AFAIR
17:15 <MasterPiece> has joined #xwiki
17:15 <cjd> if there's a fundimental difference between a group and a role (at the enforcement engine level) then of course we need to implement them but if there isn't then that could be interesting
17:16 <cjd> NIST compliance with only changing a user interface component
17:17 <cjd> if people are looking to buy NIST compliance, 64mn$ question :)
17:17 <vmassol> would need to read again this thread: http://markmail.org/message/qlfwaze47bq3gtrh
17:17 <cjd> mmm thanks
17:18 <cjd> Denis's engine seems to be fast and is getting stable so it might be time to start really showcasing our permissions infra
17:18 <vmassol> would be nice to have the redesigned Rights UI to showcase it
17:18 <vmassol> http://design.xwiki.org/xwiki/bin/view/Improvements/Rights3AProposal shows some roles
17:21 <Denis> all this remind me that we have never inverted the way implied rights are provided (actually the resposibility of the implying right in place of being the one of the implied right)
17:22 <cjd> I don't understand, can you give an example ?
17:25 <Denis> actually, admin right implies view, edit, …, and this is the admin right that define that once for all, would be better if the view (edit, …) rights tells it is implied when you has admin right
17:25 <cjd> ahh ok, so mostly an internal matter
17:26 <Denis> no so internal, since actually you cannot add a new right that gets implied by admin right
17:26 <cjd> hmm I see
17:26 <Denis> since you may dynamically add right with a simple extension, it is a bit annoying
17:27 <cjd> adding new rights could be interesting because we could do hasAccessLevel() on them in code
17:27 <Denis> I realize this design fault too late, it was in the initial design from Andrea, and I have not catch it
17:28 <Denis> adding new right works, but adding those right as implied to other existing one don't
17:28 <cjd> /nod how about adding rights without writing any code ?
17:29 <cjd> Right Within Minutes ?
17:29 <Denis> you just have to register them, it is declarative
17:29 <cjd> so we could imagine a right registerer which runs a query for XObjects of a certain type and registers them all
17:29 <Denis> now, the UI should be adapted to use them of course
17:30 <Denis> you could, yes
17:31 <Denis> there is a hard limit however, of 64 rights registered in given running JVM
17:32 <Denis> you can unregister and re-register the same right many times, but only 64 at most
17:32 <Denis> 64 different right at most
17:32 <vmassol> this is just an impl limitation AFAIK Denis, right?
17:32 <Denis> yes
17:32 <vmassol> (bit shitfing or something like this
17:32 <vmassol> )
17:33 <Denis> bit storing
17:34 <Denis> bit get allocated on the fly, but forever for a given right during a given run
17:34 <cjd> it's certainly clever
17:34 <Denis> while a impl limitation, it is also important for performance
17:35 <Denis> IMO, 64 right for a human, is a lot !
17:35 <Denis> (I mean in term of management)
17:35 <cjd> paranoia knows no bounds ;)
17:36 <Bugen_do> has joined #xwiki
17:36 <cjd> does it precalculate the permission/user matrix in advance, collapsing all of the groups ?
17:36 <cjd> aka is isUserInGroup() still expensive ?
17:37 <vmassol> reminds me of all the prophecies around memory or computers….
17:37 <vmassol> like there be no more than 10 computers needed in all the world
17:37 <cjd> it should be no real problem to fix, we'll just start using a proper bitset
17:38 <cjd> which is backed by an array of int64
17:38 <cjd> so it expands as needed
17:39 <Denis> well, there is several level of optimizations, if you want to know more, a call could be faster :)
17:41 <cjd> I don't want to waste too much time unless we have decided we want to do something
17:45 <cjd> anyway a concrete question is "from a performance point of view, should I prefer to define a new right over creating a group and checking permission in the code using isUserInGroup() ?"
17:47 <Denis> The answer is not so simple, but it is a balance. To explain it fast, all rights (the bitset) are evaluated all at the same time for a given user/entity relation. The cache store the hierarchy of involved rules see so far, the user and group membership of involved user so far, and the evaluated bitsets.
17:47 <Denis> So asking a different right for the same couple, is a cache hit
17:48 <cjd> ok
17:48 <Denis> asking a document in the same space, will only require rules from that document, and a new eval, while the rest will came from the cache
17:49 <cjd> so we can implement "pseudo-rights" using groups and then checking isUserInGroup() without an enormous perf hit ?
17:49 <Denis> but at the same time, changing the XWiki.XWikiPreferences document, will lead in a full cache flush !
17:49 <cjd> which is fine because it never happens :)
17:50 <Denis> isUserInGroup() does not involve the security module at all, and I doubt it works properly
17:50 <Denis> I mean it only check the group, not sub groups
17:50 <cjd> ok so then it's certainly a database hit so we should avoid it
17:50 <Denis> there is an old group cache
17:51 <cjd> ok then we should put a /!\DANGER/!\ flag over that one :)
17:51 <Denis> that is still very useful anyway, since the security cache does not old the whole picture
17:51 <cjd> ok
17:51 <cjd> thanks
17:52 <Denis> the GroupService which use that group cache does not manage group in groups
17:52 <Denis> it just report gourps in groups as being members like uses
17:52 <Denis> s/uses/users
17:52 <cjd> oh actually we can create a faux document for representing a right, weird as it is
17:53 <cjd> if you can view document X, code in document Y will let you pass
17:53 <cjd> anyway I'll stop wasting your time, thanks for the explanation.
17:53 <Denis> quite efficient indeed, but really weird
17:58 <KermitTheFragger> has quit
18:15 <Trefex> has quit
18:28 <cjd> has quit
19:02 <lucaa> has quit
19:17 <Slashman> has quit
19:32 <Slashman> has joined #xwiki
20:02 <Slashman> has quit
20:30 <vmassol> has quit
21:22 <Bugen_do> has quit
22:52 <gsmeria> has quit
22:52 <mflorea> has quit
23:27 <evalica> has quit
