IRC Archive for channel #xwiki on 10 July 2015
Last modified by Vincent Massol on 2015/07/10 22:49
<abusenius> has quit
03:40 <_cjd_> has joined #xwiki
03:43 <_cjd> has quit
05:06 <MasterPiece> has joined #xwiki
06:04 <Denis> has quit
06:04 <Denis> has joined #xwiki
06:25 <MasterPiece> has quit
07:39 <woshilapin> has quit
07:50 <msmeria> has joined #xwiki
08:04 <gsmeria> has joined #xwiki
08:12 <tmortagne> has joined #xwiki
08:26 <woshilapin> has joined #xwiki
08:32 <mflorea> has joined #xwiki
08:36 <mflorea> has quit
08:39 <vmassol> has joined #xwiki
08:54 <sdumitriu> has quit
08:54 <sdumitriu> has joined #xwiki
08:55 <vmassol> good morning
08:55 <sdumitriu> Good morning
08:55 <vmassol> hey hi sdumitriu
08:55 <vmassol> long time no see
08:56 <vmassol> @all: so we have 12 test failures for platform to fix today: http://ci.xwiki.org/job/xwiki-platform/1574/#showFailuresLink
08:56 <vmassol> I'll check the useprofile ones
08:56 <vmassol> since I thought I had fixed them already
09:03 <lucaa> has joined #xwiki
09:04 <tmortagne> vmassol: DisplayMacroTest failure looks related to event rendering parameters reorder
09:04 <vmassol> ah thanks fixing (it's easy)
09:13 <Slashman> has joined #xwiki
09:26 <Trefex> has joined #xwiki
09:30 <ClemensR> has joined #xwiki
09:34 <Trefex> has quit
09:35 <lucaa> has quit
09:35 <lucaa> has joined #xwiki
09:35 <Trefex> has joined #xwiki
09:45 <vmassol> fyi having a problem building office module in my ide…. preventing me from debugging the profile tests…
09:48 <vmassol> ah found why
09:48 <vmassol> marius made a mistake
09:48 <vmassol> fixing
10:08 <lucaa> has quit
10:08 <lucaa> has joined #xwiki
10:11 <Trefex> has quit
10:13 <tmortagne> vmassol: waiting for whatever decision regarding Maven 3.3.3 deploying xwiki-platform-url-scheme-filesystem by hand to workaround the issue on agents
10:14 <Trefex> has joined #xwiki
10:16 <tmortagne> hmm wait
10:16 <tmortagne> vmassol: I think I found what 3.0.5 is not happy actually
10:16 <tmortagne> and I actually don't see how 3.3.3 can work
10:16 <tmortagne> see https://github.com/xwiki/xwiki-platform/blob/stable-7.1.x/xwiki-platform-core/xwiki-platform-url/xwiki-platform-url-schemes/xwiki-platform-url-scheme-filesystem/pom.xml
10:16 <tmortagne> see anything weird ? :)
10:17 <vmassol> hmm no
10:17 <vmassol> hint?
10:17 <vmassol> :)
10:17 <vmassol> found it
10:17 <vmassol> indeed stupid
10:17 <vmassol> fixing
10:17 <vmassol> the version
10:18 <vmassol> thanks tmortagne!
10:19 <tmortagne> vmassol: I tried to deploy it and I saw 7.2-SNAPSHOT all other the Maven log
10:19 <Enygma`> has joined #xwiki
10:20 <evalica> has joined #xwiki
10:24 <gsmeria> has quit
10:25 <gsmeria> has joined #xwiki
10:38 <vmassol> ok thanks tmortagne you beat me, was talking on skype with someone ;)
10:42 <vmassol> evalica: FTR apparently I didn't fully fixed the profile editing, debugging it now
10:43 <evalica> k
10:43 <vmassol> apparently there was more to it than what I fixed...
10:44 <vmassol> the problem now is that after we save we are redirected to …/WebHome
10:45 <vmassol> and that's going to be true when editing and saving any terminal page, I need to find some idea to handle this :)
10:45 <vmassol> actually it should work since the doc exist
10:45 <vmassol> debugging… we'll see...
10:48 <evalica> k - good luck - tell me if I can help
10:49 <vmassol> so the problem seems to be the doc exist cache, it says that the doc doesn't exist
10:50 <vmassol> need to find who put in that cache that doc for "5:xwiki4:Main5:Admin" doesn't exist!
10:57 <vmassol> weird...
10:58 <vmassol> select doc.fullName from XWikiDocument as doc where doc.fullName=:fullName (where fullName = Main.Admin)
10:58 <vmassol> returns false
10:58 <vmassol> ah yes
10:58 <vmassol> it's XWiki.Admin
10:58 <vmassol> my bad
10:58 <vmassol> need to find why it's the wrong space
10:59 <evalica> tmortagne: I cannot launch the latest snapshots 99, 100 - I get the same error message as http://jira.xwiki.org/browse/XWIKI-11992 even though it is the only instance active. Do you know something about it?
10:59 <vmassol> should be easy to find..
11:01 <tmortagne> evalica: nop, never saw this issue with a single instance
11:01 <tmortagne> try to clean you cache maybe
11:01 <tmortagne> I mean the filesystem cache
11:01 <evalica> I will remove the folders from filesystem - thanks
11:02 <tmortagne> you sure you don't have anything running that might be using those files ?
11:02 <evalica> it sais 'An XWiki lock file exists at /var/tmp/xwiki-8080.lck but no XWiki is executing. Removing lock file...' … but I don;t have any console running - maybe is hanging. I will look at the processes.
11:04 <vmassol> guys, anyone know where XWiki.currentSpace is defined, I can't find it in xwiki.js?
11:04 <evalica> has quit
11:05 <vmassol> Enygma`: any idea?
11:06 <evalica> has joined #xwiki
11:07 <evalica> vmassol: javscript.vm
11:07 <evalica> inside skins/
11:08 <vmassol> ah indeed thanks
11:08 <vmassol> another question
11:08 <vmassol> when I look for xwiki*.js in my xwiki install I get 2 files
11:08 <vmassol> ./webapps/xwiki/resources/js/xwiki/xwiki-min.js
11:08 <vmassol> ./webapps/xwiki/resources/js/xwiki/xwiki.js
11:09 <vmassol> and the second one (xwiki.js) is minified
11:09 <vmassol> what's the difference between those 2 files and why is xwiki.js minified?
11:09 <evalica> the min one was added by Marius I remember…
11:10 <vmassol> I was expecting both to have the same content but one being minified and not the other
11:10 <vmassol> so I was surprised to see that xwiki.js is minified, is that normal?
11:11 <evalica> from what I remember the xwiki-min combined more js from diff apps, but I don't know
11:11 <vmassol> i any case something is amiss
11:11 <vmassol> *in
11:11 <vmassol> the naming isn't right
11:12 <Enygma`> vmassol: yes, minify=true does not do what you might expect for those js files
11:13 <Enygma`> all js files in the distribution are minified
11:13 <Enygma`> xwiki-min is just a bundling of all of them into a single js file
11:13 <Enygma`> also maybe badly named
11:13 <vmassol> I'm not sure about that Enygma`, I remember I had implemented a feature to have the non minified in the build
11:13 <vmassol> with a parameter in the URL to get the non minified version
11:13 <Enygma`> since xwiki-min contains xwiki.js, it`s not just the minified version of xwiki.js
11:14 <vmassol> need to find the issue/doc again
11:14 <Enygma`> minify=false works as expected in JSX
11:14 <vmassol> I had put that in javascript.vm checking now
11:14 <Enygma`> but for .js files it behaves diferently, i.e. it's only about grouping
11:15 <Enygma`> so to get the clear individual js files, you have to use minify=false *and* override the js file from the sources into your distrib directory
11:15 <Enygma`> since the one already in the distrib is already minified
11:15 <vmassol> yes seems so, we'll need to do something about this
11:15 <vmassol> 2 things actualy
11:15 <vmassol> 1) improve the naming
11:16 <vmassol> 2) also bundle non minified versions at least for snapshots
11:16 <vmassol> that would help debugging
11:16 <vmassol> thanks fro the help
11:20 <vmassol> evalica: I really doubt anyone cares for dev
11:20 <vmassol> (that it's bigger)
11:21 <gsmeria> has quit
11:24 <vmassol> so XWiki.currentSpace is not defined, need to find why...
11:26 <_cjd_> ever or just not when the js runs ?
11:26 <_cjd_> check the view-source and see if it's there
11:26 <_cjd_> might be a race condition
11:27 <vmassol> no it's because the js from javascript.vm is executed after the xwiki.js
11:27 <vmassol> since we have in xwiki.js:
11:27 <vmassol> XWiki.Document.currentSpace = XWiki.currentSpace || "Main";
11:27 <vmassol> thus XWiki.Document.currentSpace is set to "Main"
11:27 <vmassol> now checking if it's suppose to be overwritten later on
11:27 <vmassol> *supposed
11:28 <_cjd_> race condition
11:28 <_cjd_> well hmm yeah it's supposed to be top-to-bottom
11:29 <vmassol> there's a defer on xwiki.js too
11:29 <_cjd_> ahh so indeed race condition
11:29 <vmassol> ah no
11:29 <vmassol> defer=false
11:32 <lucaa> has quit
11:33 <vmassol> any idea what this means:
11:33 <vmassol> if (htmlElement.readAttribute('XWiki.Document.currentSpace')) {
11:33 <vmassol> XWiki.Document.currentSpace = htmlElement.readAttribute('data-xwiki-space');
11:33 <vmassol> we're looking for an attribute named "XWiki.Document.currentSpace" in the html tag?
11:33 <vmassol> why?
11:34 <vmassol> I'd have expected it to be: if(htmlElement.readAttribute('data-xwiki-space')) {
11:34 <vmassol> I think that's the bug
11:34 <vmassol> checking who did this
11:34 <evalica> apparently in the head we have meta like <meta name="space" content="A.B">
11:34 <evalica> I think GD
11:34 <vmassol> arg
11:34 <vmassol> it's me
11:35 <evalica> :) even better
11:35 <vmassol> by error in my previous commit
11:35 <vmassol> I didn't even know I had done this, some bad copy paste in my IDE
11:35 <vmassol> fixing
11:36 <vmassol> so I'll fix it
11:36 <vmassol> but I still think the code is wrong since
11:36 <vmassol> XWiki.currentSpace
11:36 <vmassol> is never defined before xwiki.js executes
11:36 <vmassol> anyway I'll leave that to our js experts ;)
11:39 <_cjd_> has quit
12:02 <gsmeria> has joined #xwiki
12:11 <vmassol> I'm now debugging a new problem found by Caty when clicking on an attachment
12:16 <vmassol> actually evalica I think the problem is the upload action
12:16 <vmassol> because the url is correct
12:16 <vmassol> so it seems the attachment is not saved in the right place
12:17 <vmassol> could be the download action too
12:18 <vmassol> it has probbaly not been modified to support nested spaces
12:18 <vmassol> all Actions need to be modified and only create/iview have AFAIK
12:19 <vmassol> indeed I see some bugs in DownloadAction.getFileName()
12:19 <vmassol> the main issue is that all actions do their own url parsing
12:19 <vmassol> they must be modified to use DocumentResourceReference
12:20 <vmassol> I mean EntityResourceReference
12:25 <vmassol> evalica and all: http://jira.xwiki.org/browse/XWIKI-12293
12:44 <Trefex> has quit
12:51 <evalica> vmassol: thanks for investigating
12:51 <vmassol> seems we have only 1 test failing for platform: http://ci.xwiki.org/job/xwiki-platform/1577/
12:51 <vmassol> going to check it out
12:53 <vmassol> this one is for marius but he seems to be off today:
12:53 <vmassol> [WARNING] Rule violated for bundle XWiki Platform - Refactoring - API: instructions covered ratio is 0.42, but expected minimum is 0.88
12:55 <vmassol> @evalica/@msmeria: actually it would be good to test other actions to see which ones have problems with NestedSpaces and report jira issues for them (as "Task")
12:56 <vmassol> maybe gsmeria could help on this actually
12:56 <vmassol> (full list of actions is defined in struts-config.xml)
12:57 <vmassol> hmm re the failing MailTests, it works locally must be a flicker, checking to see if I can notie a problem quickly
13:04 <lucaa> has joined #xwiki
13:16 <abusenius> has joined #xwiki
13:22 <gsmeria> @vmassol I'm on it
13:24 <vmassol> thanks gsmeria
13:33 <abusenius> has quit
13:43 <vmassol> working on fixing http://jira.xwiki.org/browse/XWIKI-12169?focusedCommentId=87192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87192 ATM
14:01 <Trefex> has joined #xwiki
14:09 <vmassol> going offline for some time to test without internet connection
14:11 <tmortagne> vmassol: you can probably forbid network access to java without shutting down your computer network
14:13 <vmassol> has quit
14:14 <vmassol> has joined #xwiki
14:18 <vmassol> has quit
14:19 <vmassol> has joined #xwiki
14:30 <vmassol> has quit
14:30 <vmassol> has joined #xwiki
14:33 <vmassol> tmortagne: could you merge the change you did on master to the 7.1.x branch to fix http://ci.xwiki.org/job/xwiki-platform-7.1.x/org.xwiki.platform$xwiki-platform-tool-xmldoc-update-plugin/60/testReport/junit/com.xpn.xwiki.tool.doc/DocumentUpdateMojoTest/execute/ ?
14:36 <vmassol> Enygma`: there are several failing tests that seem related to Create at http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/testReport/ but I guess you're on it right?
14:37 <tmortagne> vmassol: you mean XWIKI-12290 ?
14:37 <vmassol> yes
14:37 <vmassol> that's the error you fixed right?
14:37 <vmassol> (on master)
14:37 <vmassol> (I didn't see it at the time so I'm guesing)
14:37 <vmassol> *guessing
14:38 <woshilapin> Hi devs, I want to getDocument from my class (a component) but I'm not sure about the best way to access the com.xpn.xwiki.api.XWiki?
14:38 <woshilapin> Through a @Inject Provider<XWiki> xwiki?
14:38 <vmassol> depends what you need to do woshilapin
14:38 <vmassol> for simple things you could use DocumentAccessBridge
14:39 <vmassol> otherwise you can use a XWikiContextProvider
14:39 <woshilapin> I have strings which are FullName
14:39 <vmassol> Provider<XWikiContext>
14:39 <tmortagne> woshilapin: @Inject Provider<XWikiContext> xcontextProvider;
14:39 <woshilapin> And I want the document of it
14:39 <vmassol> and then get().getXWiki()
14:39 <tmortagne> and then you can access the whole oldcore stuff trough XWikiContext
14:39 <woshilapin> Yes, but this Provider give access to the private API, right?
14:39 <woshilapin> Need to give context to each function I'll call?
14:39 <vmassol> you now have two answer :)
14:40 <vmassol> from java you always must access the pirvate api
14:40 <woshilapin> Ah
14:40 <vmassol> the "non private" api is for scripting only
14:40 <woshilapin> Why?
14:40 <woshilapin> OK, so then I was trying to do I should not then
14:40 <vmassol> in practice it's not private vs not private
14:40 <vmassol> it's scripting api vs java api
14:40 <vmassol> :)
14:40 <woshilapin> (because I know about the xcontextProvider...)
14:40 <woshilapin> OK
14:40 <tmortagne> the only thing the public API adds is right checking and you usually don't want that in a component
14:41 <vmassol> and returning null instead of throwing exceptions thoma
14:41 <vmassol> *thomas
14:41 <vmassol> (which is bad in java)
14:41 <tmortagne> I doubt he care about that in Java
14:41 <woshilapin> OK, so then I was knowing how to do, I just tried to improve something that was not a problem...
14:41 <vmassol> (but ok in velocity)
14:41 <woshilapin> :-\
14:41 <vmassol> :)
14:41 <tmortagne> XWikiContext is public from java point of view, "private" is just to differienciate from the scripting API
14:41 <woshilapin> Thanks vmassol and tmortagne
14:42 <tmortagne> methods you use in XWikiContext are not going to be remove from one version to another
14:42 <woshilapin> But this ball and chain problem of context in each function... pfiuh...
14:42 <tmortagne> you don't have to pass the XWikiContext in your own methods
14:43 <vmassol> tmortagne: you told me about some failing test earlier on (you said 47)
14:43 <tmortagne> any method that need the context can get it from the provider
14:43 <vmassol> could you give me a linnk so that I can check them?
14:43 <tmortagne> vmassol: the 47 failing test were yesterday and most of them were cause by URLConfiguration
14:43 <vmassol> ok good
14:44 <vmassol> now I'm checking http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/testReport/ but most seem to be caused by the create action refactoring
14:44 <vmassol> checking the scheduler one now: http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui.scheduler/SchedulerTest/testJobActions/
14:45 <woshilapin> (oups, missed this DocumentAccessBridge comment, I guess I'll go for this one :-) )
14:59 <woshilapin> Is there a way to create a DocumentReference with a string (returned by a query for example), without having to load the heavy machinery of resolver?
14:59 <woshilapin> (I don't know, like a constructor for example)
14:59 <woshilapin> Or do I need to do the split('.') myself
14:59 <woshilapin> (which will be a pain since my pagename have some points in it
15:00 <tmortagne> the official way to parse a reference is a resolver
15:00 <woshilapin> Note that the string is well escaped since it comes from query.xwql
15:00 <vmassol> "Or do I need to do the split('.') myself" oh no don't do this :)
15:00 <vmassol> that' s why we made the resolvers for!
15:00 <woshilapin> Yes, that what I think too :-D
15:01 <tmortagne> the only thing tested and maintained to parse a reference is resolvers since that's what they are for
15:01 <vmassol> why do you consider it ehavy to use a resolver and not heay to parse the string yourself? :)
15:01 <woshilapin> Yes, but what is it not possible to do a DocumentRefence(string FullName) ?
15:01 <vmassol> new DocumentReference(wiki, spaces, page)
15:01 <woshilapin> (no, no, it's heavy to parse myself too...)
15:01 <woshilapin> A more buggy probably
15:01 <tmortagne> DocumentRefence is just a reference, it's not it's job to parse something in a syntaxe it's not supposed to know
15:02 <vmassol> if you know wiki name, space nales and page name (ie you don't need to resolve them) then use new DocumentReference(...)
15:02 <woshilapin> and getDocument(String) is deprecated
15:02 <vmassol> if you need to resolve them from a string use a resolver
15:02 <tmortagne> woshilapin: look at what getDocument(String) is doing
15:02 <vmassol> if you're in java, a resolver is a one line @Inject
15:02 <woshilapin> Yes, I know
15:03 <woshilapin> But what I just ask is some suger
15:03 <vmassol> can't do much simpler :)
15:03 <woshilapin> sugar
15:03 <woshilapin> One line to write instead of 10 :-)
15:03 <tmortagne> using a resolver in a component is super easy since you get injected with it
15:03 <woshilapin> But OK, I'll do with the resolver then
15:03 <vmassol> one working line instead of 20 buggy ones
15:03 <vmassol> :)
15:04 <tmortagne> for a component using a resolver is one line too...
15:04 <woshilapin> 10, I was speaking about Injecting Resolver and then Create a document reference and then finally getDocument
15:04 <tmortagne> you don't need to create a document
15:04 <tmortagne> you are just using the wrong resolver
15:04 <tmortagne> you have DocumentReferenceResolver
15:04 <woshilapin> OK
15:05 <woshilapin> hint=default?
15:05 <tmortagne> depends what is our reference
15:06 <tmortagne> if it's a complete reference then no hint yes, if it's a partial reference that you want to complete with current context then @Named("current")
15:06 <woshilapin> Space.page, is it partial (because no wiki)
15:06 <woshilapin> Space.page, is it partial (because no wiki)?
15:06 <tmortagne> yes it's partial because no wiki
15:07 <tmortagne> the it depends what wiki you want, either the default one, the current one or you can also passe the wiki reference you want as parameter to the resolver
15:07 <tmortagne> s/the it/then it/
15:08 <woshilapin> OK
15:08 <woshilapin> Thanks :-)
15:08 <tmortagne> there is usually enough resolvers to find one that will give you what you want in one line ;)
15:09 <vmassol> woshilapin: some info here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Model+Module#HResolvingaReference
15:10 <woshilapin> Thanks for the documentation
15:45 <Enygma`> vmassol: I know about the failing create tests, but I am trying to focus on the script right right now, since that is a functionality problem. Handling the tests as soon as I can.
15:45 <vmassol> ok
15:50 <abusenius> has joined #xwiki
15:53 <vmassol> this is an interesting problem: in a test we delete a page and later on we come back to the back to undelete it
15:54 <vmassol> but since the page doesn't exist anymore navigating to it isn't possible...
15:54 <vmassol> (it's a terminal page)
15:54 <vmassol> so we're missing a way to navigate to a terminal page if it doesn't exist, I guess we could add some parameter for that...
15:55 <vmassol> ?spaceRedirect=false or ?nestedDocument=false
15:55 <vmassol> tmortagne and all: wdyt?
15:56 <vmassol> or ?terminal=true
15:56 <vmassol> ?terminalPage=true ?terminalDocument=true
16:00 <Trefex> has quit
16:02 <_cjd_> has joined #xwiki
16:03 <vmassol> ok I'm going for ?spaceRedirect=false for now, let me know if you have an opinion on 1) this feature and 2) the naming
16:04 <Enygma`> one option would be to treat a non-existig terminal page that has recycle bin entries as "existing" in the view action and don`t redirect to WebHome
16:04 <Enygma`> this would be backwards compatible
16:05 <evalica> I've seen this - to the issue is that when create a space 'A', it can be accessed with 'A/WebHome', 'A/' or 'A'. If want a terminal page A, you cannot create it just by going to the URL + pressing Add: you need to specify it in a particular manner in the create step. For me this is normal - in the context that we don't encourage terminal pages anymore, just for advanced users.
16:05 <vmassol> interesting but I prefer the parameter as 1) it also allows to create terminal pages from the url directly and 2) it's going to be a lot faster in perf
16:05 <tmortagne> this is not backward compatibility, it's just hacking for a specific test
16:06 <vmassol> @evalica: it's not a problem, the add page UI will provide the ability to create terminal pages
16:06 <vmassol> (which you'll getwhen you click on "edit" when a page deosn't exist)
16:06 <vmassol> tmortagne: it's not for a specific test
16:06 <evalica> well the Recycle Bin should provide also the functionality to restore terminal pages. Not sure we need to optimize this from URL
16:07 <vmassol> indeed we could decide to drop this feature altogether
16:07 <vmassol> (for terminal pages)
16:08 <Trefex> has joined #xwiki
16:08 <vmassol> but I have the feeling it would be interesting to have a way to navigate to a terminal page from the url
16:08 <vmassol> it's very easy to add a check in XWikiAction in my redirect code
16:08 <evalica> or we just drop the redirect to 'A' when A is a space. In this case 'A' goes always to terminal pages, and we always need 'A/' to go to a space. (or A/WebHome)
16:08 <tmortagne> if it's just about having the possibility to restore deleted page we would display the recycle bing for both webhome and the page corresponding to the space if it exist
16:09 <tmortagne> s/would/could/
16:09 <vmassol> evalica: what??????
16:09 <vmassol> :)
16:09 <evalica> and this we also can display in the 'Location' livetables in order to visually differenciate terminal from space: the absence or presence of '.'
16:09 <vmassol> you want to redo everything? and restart the discussion???
16:09 <evalica> '/'
16:09 <tmortagne> i.e. you are redirected to the not existing WebHome as usual but you have the link to restore the previously deleted page
16:09 <vmassol> definitely not, big -1
16:09 <vmassol> :)
16:09 <vmassol> that's the whole point
16:09 <evalica> :)
16:09 <vmassol> to be able to nav to non terminal pages easily
16:10 <abusenius> has quit
16:10 <Enygma`> tmortagne: but the WebHome could be existing, thus masking your deleted terminal that can not be undeleted now, since you don`t get to the recycle bin UI
16:10 <vmassol> tmortagne: I don't like mixing 2 pages, they're different pages
16:10 <evalica> anyway - even with a query param … the feature will be hidden and not many will know about it
16:10 <vmassol> sure
16:10 <vmassol> that's the point
16:10 <tmortagne> Enygma`: I said if the WebHome does not exist
16:10 <vmassol> it's an edge case which we woudln't promote
16:11 <tmortagne> anyway we want to end up in the WebHome when you enter A
16:12 <vmassol> my personal view is:
16:12 <msmeria> has quit
16:12 <Enygma`> yes, but if we really want to get to terminal A (which does not exist) and not non-termial A/ (that does exist), we can`t
16:12 <vmassol> - doign this automatic redirect is something on top in order to offer a shortcut
16:12 <vmassol> - we should have a way to turn this feature off if we need
16:12 <Enygma`> so yeah, a query param should probably do it
16:12 <vmassol> (hence the idea of the parameter to turn it off when needed)
16:13 <Enygma`> just that apps that use only terminal documents should pretty much use this query param
16:13 <tmortagne> Enygma`: I never told about not having the parameter, I'm talking about default behavior
16:13 <tmortagne> the parameter is the only way if we have the redirect anyway
16:13 <Enygma`> yea, I guess
16:13 <vmassol> Enygma`: yes and by default I'd add this parameter in our selenium test framework (gotoPage())
16:14 <Enygma`> vmassol: I`d prefer using it only when needed
16:14 <tmortagne> vmassol: not sure about that, the point of selenium is to mimic user behavior
16:14 <Enygma`> since we want to test regular behavior
16:14 <tmortagne> yep
16:14 <vmassol> let me rephrase, I'd add a new gotoPage() method
16:15 <vmassol> (new signature)
16:16 <vmassol> ok for "spaceRedirect=false"? (trying to be close to the method name which is redirectSpaceURLs())
16:16 <tmortagne> by the way do we have an option to disable the redirect ?
16:16 <vmassol> you mean config?
16:16 <tmortagne> yes
16:16 <vmassol> no config ATM
16:17 <tmortagne> I'm sure some already existing wikis will prefer disabling that
16:17 <Enygma`> forceTerminal=true?
16:17 <evalica> one idea would be if the user has 'Allow terminal' in profile to disable the redirect. But depends what behavior we want to promote.
16:18 <vmassol> evalica: i don't think it's a per user config
16:18 <vmassol> that would cause problems
16:18 <vmassol> you give a link to someoe… and it doesn't work
16:18 <vmassol> so for me it's a subwiki level
16:18 <vmassol> s/a/at
16:18 <evalica> other UI ideas could be: if also a terminal page exist: A. provide a warning in the UI - like a 'Do you wanted to go to X page?' or … maybe the breadcrumb could display there is an alternative :) …. anyway we could think of a solution - but again this would mean making the feature more visible.
16:19 <tmortagne> yes it's a wiki level config I think
16:19 <vmassol> (to take into account the farm mode)
16:20 <vmassol> evalica: we could have refinements later on but I think for now a param would be good
16:20 <vmassol> just need to agree on the name now
16:20 <vmassol> forceTerminal is not really the goal of this param
16:21 <vmassol> this param will be here to disable to automatic redirect when entering a space url
16:21 <evalica> well depends if you want to have a param that contains the word 'space' although we are deprecating the concept
16:21 <tmortagne> spaceRedirect is not very nice but it's the most accurate I can think of
16:22 <vmassol> @evalica: we're not deprecating the concept
16:22 <vmassol> :)
16:22 <vmassol> only in the UI
16:22 <vmassol> for ex the REST URL will still contain /spaces/ too
16:23 <vmassol> since it('s a technical param I don't see it as a problem that it contains "space"
16:23 <tmortagne> yes it's not really a problem since the param itself does not make any sense without space concept
16:24 <evalica> I'm +0
16:24 <tmortagne> (you would not have non terminal vs terminal page in a real nested documents environment)
16:25 <vmassol> Enygma`: wdyt?
16:25 <Enygma`> you will also not have spaces in a real nested documents environment :) so it`s pretty much the same from that point of view
16:25 <vmassol> yes that's thomas's point
16:25 <tmortagne> Enygma`: my point is that without spaves this paremeter would not exist
16:25 <tmortagne> s/spaves/spaces/
16:26 <vmassol> there would be no redirect
16:26 <vmassol> and no need to disable it
16:26 <Enygma`> sure, I think it`s fine and there`s really not much need to dwell on it IMO
16:26 <evalica> ?redirect=false or ?stopRedirect=true…. anyway I guess is fine ?spaceRedirect=false
16:26 <vmassol> the first 2 are too generic
16:26 <evalica> k
16:26 <vmassol> we have plenty of other rediects
16:26 <Enygma`> and conflict with xredirect
16:26 <evalica> k
16:26 <tmortagne> redirect might be understood as xredirect canceller or somehting liek this
16:26 <tmortagne> yes
16:27 <Enygma`> +1 for spaceRedirect
16:27 <vmassol> ok going for spaceRedirect for now and we have till 7.2 final to change our mind on the namin g :)
16:27 <tmortagne> anyway it's not a big deal, spaceRedirect is explicit enough and if we really want it's not very hard to add a new one later and deprecated this one
16:27 <vmassol> thanks everyone for the inpuy
16:27 <vmassol> *input
16:35 <vmassol> btw you're right, I'm not going to add any signature for gotoPage since it already supports passing a querys tring
16:45 <lucaa> has quit
16:57 <abusenius> has joined #xwiki
17:08 <gsmeria1> has joined #xwiki
17:09 <gsmeria1> has quit
17:17 <vmassol> Scheduler test should work fine now :)
17:24 <Bugen_do> has joined #xwiki
17:26 <vmassol> tmortagne: strange error: http://ci.xwiki.org/job/xwiki-platform-7.1.x/62/console
17:26 <vmassol> restarting the job...
17:27 <Trefex> has quit
17:27 <vmassol> ok all http://ci.xwiki.org/job/xwiki-enterprise-test-wysiwyg/ failing tests are caused by the create action changes
17:28 <vmassol> working on http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/LoginTest/testLoginLogoutAsAdmin/ now
17:28 <tmortagne> vmassol: looks like nexus has some issues
17:29 <vmassol> someone should check these ones:
17:29 <vmassol> - http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/EditClassTest/testAddProperty/
17:29 <vmassol> - http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui.appwithinminutes/ApplicationNameTest/testSpecialCharactersInAppName/
17:29 <vmassol> they don't seem related to the create action changes
17:29 <tmortagne> looks at http://nexus.xwiki.org/nexus/content/repositories/snapshots/org/xwiki/platform/xwiki-platform-dashboard-macro/7.1.2-SNAPSHOT/
17:29 <vmassol> then there's http://ci.xwiki.org/job/xwiki-enterprise-test-escaping/lastBuild/testReport/ to look at too
17:29 <tmortagne> the jar is here but not the pom
17:30 <vmassol> strange
17:30 <tmortagne> nexus returned a 502 when maven tried to deploy it
17:30 <tmortagne> that's the error we see at the end
17:31 <vmassol> I know, that's why I restarted the build to see if it was transient or not
17:31 <tmortagne> its not the first network related issue I see today
17:33 <vmassol> hopefully http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/LoginTest/testLoginLogoutAsAdmin/ should be fixed now
17:45 <Denis> has quit
17:46 <woshilapin> Heyhey, you thought I was done for today but I don't
17:46 <woshilapin> I reach this error
17:46 <woshilapin> https://ezcrypt.xwikisas.com/C#2fu02t6L9XCzNcOvtBtSbDjF
17:46 <woshilapin> And I'm not sure of what is happening
17:46 <woshilapin> I suspect that the 'parent' in the URL contains a '.' in the name of the page and then it crashes...
17:47 <woshilapin> Should I double escape or something like that?
17:47 <_cjd_> u trollin ?
17:48 <vmassol> woshilapin: it means the URL is not valid
17:48 <vmassol> it's not properly encoded
17:48 <woshilapin> (resume: I click on a link that look like MySpace/MyPage?template=Space.PageTemplate&parent=MySpace.Some\.thing
17:48 <woshilapin> Backslash not allowed, right?
17:48 <Denis2> has joined #xwiki
17:48 <_cjd_> yeah, that \ is going to make tomcat upset
17:48 <vmassol> Caused by: java.net.URISyntaxException: Illegal character in query at index 145: http://localhost:8080/xwiki/bin/edit/mymodel/b29fcf50-4595-48a4-95a1-fc24457832ec?template=xwiki:LearnPAdCode.FeedbackTemplate&parent=mymodel.obj\.45020&LearnPAdCode.FeedbackClass_0_id=b29fcf50-4595-48a4-95a1-fc24457832ec
17:49 <woshilapin> yep
17:49 <woshilapin> The parent part is breaking
17:49 <_cjd_> encodeURIComponent() ?
17:50 <_cjd_> turns \ into %blahsomething
17:50 <_cjd_> so no more evil \
17:51 <_cjd_> ahh, you're using the normal way to create a page and it's blowing up XWiki ?
17:51 <woshilapin> $xwiki.getURL()
17:51 <_cjd_> That's deprecated, you should really use the new Component based API
17:51 <woshilapin> $xwiki.getURL(DocumentReference, 'edit', 'someparameters')
17:52 <woshilapin> haha
17:52 <vmassol> note that the query string is NOT encoded
17:52 <_cjd_> $xwiki is deprecated
17:52 <vmassol> you need to do that
17:52 <vmassol> see the javadoc
17:53 <tmortagne> woshilapin: that's called job to provider a proper query string
17:53 <tmortagne> (you can't escape a query string already created)
17:53 <tmortagne> s/provider/provide/
17:53 <woshilapin> ?
17:53 <vmassol> woshilapin: here: https://gist.github.com/vmassol/7110f663f9afe955874a
17:53 <_cjd_> He meant: It's the caller's job to provide a properly encoded query string
17:53 <vmassol> (I wrote that javadoc)
17:53 <vmassol> (it explains it)
17:54 <tmortagne> s/called/caller/
17:54 <_cjd_> $xwiki.getURL(DocumentReference, 'edit', "someparameters&$escapetool.url("\\\bsjklc]\]as")")
17:54 <_cjd_> $xwiki.getURL(DocumentReference, 'edit', "someparameters&parent=$escapetool.url("\\\bsjklc]\]as")")
17:55 <_cjd_> there ya go
17:55 <tmortagne> yes
17:55 <tmortagne> (except for the double quote inside double quote but you encode a variable I guess anyway)
17:56 <_cjd_> I think wacky double quotes in velocity does work :D
17:56 <woshilapin> OK, works
17:56 <woshilapin> Thanks
18:01 <vmassol> has quit
18:02 <ClemensR> has left #xwiki
18:04 <Denis> has joined #xwiki
18:04 <_cjd_> has quit
18:04 <Denis> has quit
18:06 <Denis2> has quit
18:27 <Pbas> has left #xwiki
18:30 <fca> has joined #xwiki
18:55 <fca> Hi, when installing XWiki 7.1.1 via WAR on Debian Jessie with Tomcat 8, Oracle JDK 8, PostgreSQL 9.4 (PGDG version), and a (apparently) working internet connection, the distribution wizard does not complete. It stops at : «Resolving extension dependency [org.xwiki.platform:xwiki-platform-user-profile-ui-7.1.1] on namespace [xwiki]» No special error message from tomcat.
19:04 <_cjd_> has joined #xwiki
19:10 <tmortagne> has quit
19:34 <evalica> fca: it's a bit late now - maybe you can write a mail on [email protected] or fill an issue
19:42 <woshilapin> has quit
20:14 <lucaa> has joined #xwiki
20:19 <lucaa> has quit
20:23 <lucaa> has joined #xwiki
20:36 <fca> evalica: I will try to find the source of the problem, or at least narrow it before posting. Installing 6.4.4 with the same stack and same config works fine. So, ATM, I'll be installing 6.4.4.
20:37 <lucaa> has quit
20:39 <evalica> k
20:44 <woshilapin> has joined #xwiki
21:55 <Slashman> has quit
22:49 <evalica> has quit
22:49 <Enygma`> has quit
03:40 <_cjd_> has joined #xwiki
03:43 <_cjd> has quit
05:06 <MasterPiece> has joined #xwiki
06:04 <Denis> has quit
06:04 <Denis> has joined #xwiki
06:25 <MasterPiece> has quit
07:39 <woshilapin> has quit
07:50 <msmeria> has joined #xwiki
08:04 <gsmeria> has joined #xwiki
08:12 <tmortagne> has joined #xwiki
08:26 <woshilapin> has joined #xwiki
08:32 <mflorea> has joined #xwiki
08:36 <mflorea> has quit
08:39 <vmassol> has joined #xwiki
08:54 <sdumitriu> has quit
08:54 <sdumitriu> has joined #xwiki
08:55 <vmassol> good morning
08:55 <sdumitriu> Good morning
08:55 <vmassol> hey hi sdumitriu
08:55 <vmassol> long time no see
08:56 <vmassol> @all: so we have 12 test failures for platform to fix today: http://ci.xwiki.org/job/xwiki-platform/1574/#showFailuresLink
08:56 <vmassol> I'll check the useprofile ones
08:56 <vmassol> since I thought I had fixed them already
09:03 <lucaa> has joined #xwiki
09:04 <tmortagne> vmassol: DisplayMacroTest failure looks related to event rendering parameters reorder
09:04 <vmassol> ah thanks fixing (it's easy)
09:13 <Slashman> has joined #xwiki
09:26 <Trefex> has joined #xwiki
09:30 <ClemensR> has joined #xwiki
09:34 <Trefex> has quit
09:35 <lucaa> has quit
09:35 <lucaa> has joined #xwiki
09:35 <Trefex> has joined #xwiki
09:45 <vmassol> fyi having a problem building office module in my ide…. preventing me from debugging the profile tests…
09:48 <vmassol> ah found why
09:48 <vmassol> marius made a mistake
09:48 <vmassol> fixing
10:08 <lucaa> has quit
10:08 <lucaa> has joined #xwiki
10:11 <Trefex> has quit
10:13 <tmortagne> vmassol: waiting for whatever decision regarding Maven 3.3.3 deploying xwiki-platform-url-scheme-filesystem by hand to workaround the issue on agents
10:14 <Trefex> has joined #xwiki
10:16 <tmortagne> hmm wait
10:16 <tmortagne> vmassol: I think I found what 3.0.5 is not happy actually
10:16 <tmortagne> and I actually don't see how 3.3.3 can work
10:16 <tmortagne> see https://github.com/xwiki/xwiki-platform/blob/stable-7.1.x/xwiki-platform-core/xwiki-platform-url/xwiki-platform-url-schemes/xwiki-platform-url-scheme-filesystem/pom.xml
10:16 <tmortagne> see anything weird ? :)
10:17 <vmassol> hmm no
10:17 <vmassol> hint?
10:17 <vmassol> :)
10:17 <vmassol> found it
10:17 <vmassol> indeed stupid
10:17 <vmassol> fixing
10:17 <vmassol> the version
10:18 <vmassol> thanks tmortagne!
10:19 <tmortagne> vmassol: I tried to deploy it and I saw 7.2-SNAPSHOT all other the Maven log
10:19 <Enygma`> has joined #xwiki
10:20 <evalica> has joined #xwiki
10:24 <gsmeria> has quit
10:25 <gsmeria> has joined #xwiki
10:38 <vmassol> ok thanks tmortagne you beat me, was talking on skype with someone ;)
10:42 <vmassol> evalica: FTR apparently I didn't fully fixed the profile editing, debugging it now
10:43 <evalica> k
10:43 <vmassol> apparently there was more to it than what I fixed...
10:44 <vmassol> the problem now is that after we save we are redirected to …/WebHome
10:45 <vmassol> and that's going to be true when editing and saving any terminal page, I need to find some idea to handle this :)
10:45 <vmassol> actually it should work since the doc exist
10:45 <vmassol> debugging… we'll see...
10:48 <evalica> k - good luck - tell me if I can help
10:49 <vmassol> so the problem seems to be the doc exist cache, it says that the doc doesn't exist
10:50 <vmassol> need to find who put in that cache that doc for "5:xwiki4:Main5:Admin" doesn't exist!
10:57 <vmassol> weird...
10:58 <vmassol> select doc.fullName from XWikiDocument as doc where doc.fullName=:fullName (where fullName = Main.Admin)
10:58 <vmassol> returns false
10:58 <vmassol> ah yes
10:58 <vmassol> it's XWiki.Admin
10:58 <vmassol> my bad
10:58 <vmassol> need to find why it's the wrong space
10:59 <evalica> tmortagne: I cannot launch the latest snapshots 99, 100 - I get the same error message as http://jira.xwiki.org/browse/XWIKI-11992 even though it is the only instance active. Do you know something about it?
10:59 <vmassol> should be easy to find..
11:01 <tmortagne> evalica: nop, never saw this issue with a single instance
11:01 <tmortagne> try to clean you cache maybe
11:01 <tmortagne> I mean the filesystem cache
11:01 <evalica> I will remove the folders from filesystem - thanks
11:02 <tmortagne> you sure you don't have anything running that might be using those files ?
11:02 <evalica> it sais 'An XWiki lock file exists at /var/tmp/xwiki-8080.lck but no XWiki is executing. Removing lock file...' … but I don;t have any console running - maybe is hanging. I will look at the processes.
11:04 <vmassol> guys, anyone know where XWiki.currentSpace is defined, I can't find it in xwiki.js?
11:04 <evalica> has quit
11:05 <vmassol> Enygma`: any idea?
11:06 <evalica> has joined #xwiki
11:07 <evalica> vmassol: javscript.vm
11:07 <evalica> inside skins/
11:08 <vmassol> ah indeed thanks
11:08 <vmassol> another question
11:08 <vmassol> when I look for xwiki*.js in my xwiki install I get 2 files
11:08 <vmassol> ./webapps/xwiki/resources/js/xwiki/xwiki-min.js
11:08 <vmassol> ./webapps/xwiki/resources/js/xwiki/xwiki.js
11:09 <vmassol> and the second one (xwiki.js) is minified
11:09 <vmassol> what's the difference between those 2 files and why is xwiki.js minified?
11:09 <evalica> the min one was added by Marius I remember…
11:10 <vmassol> I was expecting both to have the same content but one being minified and not the other
11:10 <vmassol> so I was surprised to see that xwiki.js is minified, is that normal?
11:11 <evalica> from what I remember the xwiki-min combined more js from diff apps, but I don't know
11:11 <vmassol> i any case something is amiss
11:11 <vmassol> *in
11:11 <vmassol> the naming isn't right
11:12 <Enygma`> vmassol: yes, minify=true does not do what you might expect for those js files
11:13 <Enygma`> all js files in the distribution are minified
11:13 <Enygma`> xwiki-min is just a bundling of all of them into a single js file
11:13 <Enygma`> also maybe badly named
11:13 <vmassol> I'm not sure about that Enygma`, I remember I had implemented a feature to have the non minified in the build
11:13 <vmassol> with a parameter in the URL to get the non minified version
11:13 <Enygma`> since xwiki-min contains xwiki.js, it`s not just the minified version of xwiki.js
11:14 <vmassol> need to find the issue/doc again
11:14 <Enygma`> minify=false works as expected in JSX
11:14 <vmassol> I had put that in javascript.vm checking now
11:14 <Enygma`> but for .js files it behaves diferently, i.e. it's only about grouping
11:15 <Enygma`> so to get the clear individual js files, you have to use minify=false *and* override the js file from the sources into your distrib directory
11:15 <Enygma`> since the one already in the distrib is already minified
11:15 <vmassol> yes seems so, we'll need to do something about this
11:15 <vmassol> 2 things actualy
11:15 <vmassol> 1) improve the naming
11:16 <vmassol> 2) also bundle non minified versions at least for snapshots
11:16 <vmassol> that would help debugging
11:16 <vmassol> thanks fro the help
11:20 <vmassol> evalica: I really doubt anyone cares for dev
11:20 <vmassol> (that it's bigger)
11:21 <gsmeria> has quit
11:24 <vmassol> so XWiki.currentSpace is not defined, need to find why...
11:26 <_cjd_> ever or just not when the js runs ?
11:26 <_cjd_> check the view-source and see if it's there
11:26 <_cjd_> might be a race condition
11:27 <vmassol> no it's because the js from javascript.vm is executed after the xwiki.js
11:27 <vmassol> since we have in xwiki.js:
11:27 <vmassol> XWiki.Document.currentSpace = XWiki.currentSpace || "Main";
11:27 <vmassol> thus XWiki.Document.currentSpace is set to "Main"
11:27 <vmassol> now checking if it's suppose to be overwritten later on
11:27 <vmassol> *supposed
11:28 <_cjd_> race condition
11:28 <_cjd_> well hmm yeah it's supposed to be top-to-bottom
11:29 <vmassol> there's a defer on xwiki.js too
11:29 <_cjd_> ahh so indeed race condition
11:29 <vmassol> ah no
11:29 <vmassol> defer=false
11:32 <lucaa> has quit
11:33 <vmassol> any idea what this means:
11:33 <vmassol> if (htmlElement.readAttribute('XWiki.Document.currentSpace')) {
11:33 <vmassol> XWiki.Document.currentSpace = htmlElement.readAttribute('data-xwiki-space');
11:33 <vmassol> we're looking for an attribute named "XWiki.Document.currentSpace" in the html tag?
11:33 <vmassol> why?
11:34 <vmassol> I'd have expected it to be: if(htmlElement.readAttribute('data-xwiki-space')) {
11:34 <vmassol> I think that's the bug
11:34 <vmassol> checking who did this
11:34 <evalica> apparently in the head we have meta like <meta name="space" content="A.B">
11:34 <evalica> I think GD
11:34 <vmassol> arg
11:34 <vmassol> it's me
11:35 <evalica> :) even better
11:35 <vmassol> by error in my previous commit
11:35 <vmassol> I didn't even know I had done this, some bad copy paste in my IDE
11:35 <vmassol> fixing
11:36 <vmassol> so I'll fix it
11:36 <vmassol> but I still think the code is wrong since
11:36 <vmassol> XWiki.currentSpace
11:36 <vmassol> is never defined before xwiki.js executes
11:36 <vmassol> anyway I'll leave that to our js experts ;)
11:39 <_cjd_> has quit
12:02 <gsmeria> has joined #xwiki
12:11 <vmassol> I'm now debugging a new problem found by Caty when clicking on an attachment
12:16 <vmassol> actually evalica I think the problem is the upload action
12:16 <vmassol> because the url is correct
12:16 <vmassol> so it seems the attachment is not saved in the right place
12:17 <vmassol> could be the download action too
12:18 <vmassol> it has probbaly not been modified to support nested spaces
12:18 <vmassol> all Actions need to be modified and only create/iview have AFAIK
12:19 <vmassol> indeed I see some bugs in DownloadAction.getFileName()
12:19 <vmassol> the main issue is that all actions do their own url parsing
12:19 <vmassol> they must be modified to use DocumentResourceReference
12:20 <vmassol> I mean EntityResourceReference
12:25 <vmassol> evalica and all: http://jira.xwiki.org/browse/XWIKI-12293
12:44 <Trefex> has quit
12:51 <evalica> vmassol: thanks for investigating
12:51 <vmassol> seems we have only 1 test failing for platform: http://ci.xwiki.org/job/xwiki-platform/1577/
12:51 <vmassol> going to check it out
12:53 <vmassol> this one is for marius but he seems to be off today:
12:53 <vmassol> [WARNING] Rule violated for bundle XWiki Platform - Refactoring - API: instructions covered ratio is 0.42, but expected minimum is 0.88
12:55 <vmassol> @evalica/@msmeria: actually it would be good to test other actions to see which ones have problems with NestedSpaces and report jira issues for them (as "Task")
12:56 <vmassol> maybe gsmeria could help on this actually
12:56 <vmassol> (full list of actions is defined in struts-config.xml)
12:57 <vmassol> hmm re the failing MailTests, it works locally must be a flicker, checking to see if I can notie a problem quickly
13:04 <lucaa> has joined #xwiki
13:16 <abusenius> has joined #xwiki
13:22 <gsmeria> @vmassol I'm on it
13:24 <vmassol> thanks gsmeria
13:33 <abusenius> has quit
13:43 <vmassol> working on fixing http://jira.xwiki.org/browse/XWIKI-12169?focusedCommentId=87192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87192 ATM
14:01 <Trefex> has joined #xwiki
14:09 <vmassol> going offline for some time to test without internet connection
14:11 <tmortagne> vmassol: you can probably forbid network access to java without shutting down your computer network
14:13 <vmassol> has quit
14:14 <vmassol> has joined #xwiki
14:18 <vmassol> has quit
14:19 <vmassol> has joined #xwiki
14:30 <vmassol> has quit
14:30 <vmassol> has joined #xwiki
14:33 <vmassol> tmortagne: could you merge the change you did on master to the 7.1.x branch to fix http://ci.xwiki.org/job/xwiki-platform-7.1.x/org.xwiki.platform$xwiki-platform-tool-xmldoc-update-plugin/60/testReport/junit/com.xpn.xwiki.tool.doc/DocumentUpdateMojoTest/execute/ ?
14:36 <vmassol> Enygma`: there are several failing tests that seem related to Create at http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/testReport/ but I guess you're on it right?
14:37 <tmortagne> vmassol: you mean XWIKI-12290 ?
14:37 <vmassol> yes
14:37 <vmassol> that's the error you fixed right?
14:37 <vmassol> (on master)
14:37 <vmassol> (I didn't see it at the time so I'm guesing)
14:37 <vmassol> *guessing
14:38 <woshilapin> Hi devs, I want to getDocument from my class (a component) but I'm not sure about the best way to access the com.xpn.xwiki.api.XWiki?
14:38 <woshilapin> Through a @Inject Provider<XWiki> xwiki?
14:38 <vmassol> depends what you need to do woshilapin
14:38 <vmassol> for simple things you could use DocumentAccessBridge
14:39 <vmassol> otherwise you can use a XWikiContextProvider
14:39 <woshilapin> I have strings which are FullName
14:39 <vmassol> Provider<XWikiContext>
14:39 <tmortagne> woshilapin: @Inject Provider<XWikiContext> xcontextProvider;
14:39 <woshilapin> And I want the document of it
14:39 <vmassol> and then get().getXWiki()
14:39 <tmortagne> and then you can access the whole oldcore stuff trough XWikiContext
14:39 <woshilapin> Yes, but this Provider give access to the private API, right?
14:39 <woshilapin> Need to give context to each function I'll call?
14:39 <vmassol> you now have two answer :)
14:40 <vmassol> from java you always must access the pirvate api
14:40 <woshilapin> Ah
14:40 <vmassol> the "non private" api is for scripting only
14:40 <woshilapin> Why?
14:40 <woshilapin> OK, so then I was trying to do I should not then
14:40 <vmassol> in practice it's not private vs not private
14:40 <vmassol> it's scripting api vs java api
14:40 <vmassol> :)
14:40 <woshilapin> (because I know about the xcontextProvider...)
14:40 <woshilapin> OK
14:40 <tmortagne> the only thing the public API adds is right checking and you usually don't want that in a component
14:41 <vmassol> and returning null instead of throwing exceptions thoma
14:41 <vmassol> *thomas
14:41 <vmassol> (which is bad in java)
14:41 <tmortagne> I doubt he care about that in Java
14:41 <woshilapin> OK, so then I was knowing how to do, I just tried to improve something that was not a problem...
14:41 <vmassol> (but ok in velocity)
14:41 <woshilapin> :-\
14:41 <vmassol> :)
14:41 <tmortagne> XWikiContext is public from java point of view, "private" is just to differienciate from the scripting API
14:41 <woshilapin> Thanks vmassol and tmortagne
14:42 <tmortagne> methods you use in XWikiContext are not going to be remove from one version to another
14:42 <woshilapin> But this ball and chain problem of context in each function... pfiuh...
14:42 <tmortagne> you don't have to pass the XWikiContext in your own methods
14:43 <vmassol> tmortagne: you told me about some failing test earlier on (you said 47)
14:43 <tmortagne> any method that need the context can get it from the provider
14:43 <vmassol> could you give me a linnk so that I can check them?
14:43 <tmortagne> vmassol: the 47 failing test were yesterday and most of them were cause by URLConfiguration
14:43 <vmassol> ok good
14:44 <vmassol> now I'm checking http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/testReport/ but most seem to be caused by the create action refactoring
14:44 <vmassol> checking the scheduler one now: http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui.scheduler/SchedulerTest/testJobActions/
14:45 <woshilapin> (oups, missed this DocumentAccessBridge comment, I guess I'll go for this one :-) )
14:59 <woshilapin> Is there a way to create a DocumentReference with a string (returned by a query for example), without having to load the heavy machinery of resolver?
14:59 <woshilapin> (I don't know, like a constructor for example)
14:59 <woshilapin> Or do I need to do the split('.') myself
14:59 <woshilapin> (which will be a pain since my pagename have some points in it
15:00 <tmortagne> the official way to parse a reference is a resolver
15:00 <woshilapin> Note that the string is well escaped since it comes from query.xwql
15:00 <vmassol> "Or do I need to do the split('.') myself" oh no don't do this :)
15:00 <vmassol> that' s why we made the resolvers for!
15:00 <woshilapin> Yes, that what I think too :-D
15:01 <tmortagne> the only thing tested and maintained to parse a reference is resolvers since that's what they are for
15:01 <vmassol> why do you consider it ehavy to use a resolver and not heay to parse the string yourself? :)
15:01 <woshilapin> Yes, but what is it not possible to do a DocumentRefence(string FullName) ?
15:01 <vmassol> new DocumentReference(wiki, spaces, page)
15:01 <woshilapin> (no, no, it's heavy to parse myself too...)
15:01 <woshilapin> A more buggy probably
15:01 <tmortagne> DocumentRefence is just a reference, it's not it's job to parse something in a syntaxe it's not supposed to know
15:02 <vmassol> if you know wiki name, space nales and page name (ie you don't need to resolve them) then use new DocumentReference(...)
15:02 <woshilapin> and getDocument(String) is deprecated
15:02 <vmassol> if you need to resolve them from a string use a resolver
15:02 <tmortagne> woshilapin: look at what getDocument(String) is doing
15:02 <vmassol> if you're in java, a resolver is a one line @Inject
15:02 <woshilapin> Yes, I know
15:03 <woshilapin> But what I just ask is some suger
15:03 <vmassol> can't do much simpler :)
15:03 <woshilapin> sugar
15:03 <woshilapin> One line to write instead of 10 :-)
15:03 <tmortagne> using a resolver in a component is super easy since you get injected with it
15:03 <woshilapin> But OK, I'll do with the resolver then
15:03 <vmassol> one working line instead of 20 buggy ones
15:03 <vmassol> :)
15:04 <tmortagne> for a component using a resolver is one line too...
15:04 <woshilapin> 10, I was speaking about Injecting Resolver and then Create a document reference and then finally getDocument
15:04 <tmortagne> you don't need to create a document
15:04 <tmortagne> you are just using the wrong resolver
15:04 <tmortagne> you have DocumentReferenceResolver
15:04 <woshilapin> OK
15:05 <woshilapin> hint=default?
15:05 <tmortagne> depends what is our reference
15:06 <tmortagne> if it's a complete reference then no hint yes, if it's a partial reference that you want to complete with current context then @Named("current")
15:06 <woshilapin> Space.page, is it partial (because no wiki)
15:06 <woshilapin> Space.page, is it partial (because no wiki)?
15:06 <tmortagne> yes it's partial because no wiki
15:07 <tmortagne> the it depends what wiki you want, either the default one, the current one or you can also passe the wiki reference you want as parameter to the resolver
15:07 <tmortagne> s/the it/then it/
15:08 <woshilapin> OK
15:08 <woshilapin> Thanks :-)
15:08 <tmortagne> there is usually enough resolvers to find one that will give you what you want in one line ;)
15:09 <vmassol> woshilapin: some info here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Model+Module#HResolvingaReference
15:10 <woshilapin> Thanks for the documentation
15:45 <Enygma`> vmassol: I know about the failing create tests, but I am trying to focus on the script right right now, since that is a functionality problem. Handling the tests as soon as I can.
15:45 <vmassol> ok
15:50 <abusenius> has joined #xwiki
15:53 <vmassol> this is an interesting problem: in a test we delete a page and later on we come back to the back to undelete it
15:54 <vmassol> but since the page doesn't exist anymore navigating to it isn't possible...
15:54 <vmassol> (it's a terminal page)
15:54 <vmassol> so we're missing a way to navigate to a terminal page if it doesn't exist, I guess we could add some parameter for that...
15:55 <vmassol> ?spaceRedirect=false or ?nestedDocument=false
15:55 <vmassol> tmortagne and all: wdyt?
15:56 <vmassol> or ?terminal=true
15:56 <vmassol> ?terminalPage=true ?terminalDocument=true
16:00 <Trefex> has quit
16:02 <_cjd_> has joined #xwiki
16:03 <vmassol> ok I'm going for ?spaceRedirect=false for now, let me know if you have an opinion on 1) this feature and 2) the naming
16:04 <Enygma`> one option would be to treat a non-existig terminal page that has recycle bin entries as "existing" in the view action and don`t redirect to WebHome
16:04 <Enygma`> this would be backwards compatible
16:05 <evalica> I've seen this - to the issue is that when create a space 'A', it can be accessed with 'A/WebHome', 'A/' or 'A'. If want a terminal page A, you cannot create it just by going to the URL + pressing Add: you need to specify it in a particular manner in the create step. For me this is normal - in the context that we don't encourage terminal pages anymore, just for advanced users.
16:05 <vmassol> interesting but I prefer the parameter as 1) it also allows to create terminal pages from the url directly and 2) it's going to be a lot faster in perf
16:05 <tmortagne> this is not backward compatibility, it's just hacking for a specific test
16:06 <vmassol> @evalica: it's not a problem, the add page UI will provide the ability to create terminal pages
16:06 <vmassol> (which you'll getwhen you click on "edit" when a page deosn't exist)
16:06 <vmassol> tmortagne: it's not for a specific test
16:06 <evalica> well the Recycle Bin should provide also the functionality to restore terminal pages. Not sure we need to optimize this from URL
16:07 <vmassol> indeed we could decide to drop this feature altogether
16:07 <vmassol> (for terminal pages)
16:08 <Trefex> has joined #xwiki
16:08 <vmassol> but I have the feeling it would be interesting to have a way to navigate to a terminal page from the url
16:08 <vmassol> it's very easy to add a check in XWikiAction in my redirect code
16:08 <evalica> or we just drop the redirect to 'A' when A is a space. In this case 'A' goes always to terminal pages, and we always need 'A/' to go to a space. (or A/WebHome)
16:08 <tmortagne> if it's just about having the possibility to restore deleted page we would display the recycle bing for both webhome and the page corresponding to the space if it exist
16:09 <tmortagne> s/would/could/
16:09 <vmassol> evalica: what??????
16:09 <vmassol> :)
16:09 <evalica> and this we also can display in the 'Location' livetables in order to visually differenciate terminal from space: the absence or presence of '.'
16:09 <vmassol> you want to redo everything? and restart the discussion???
16:09 <evalica> '/'
16:09 <tmortagne> i.e. you are redirected to the not existing WebHome as usual but you have the link to restore the previously deleted page
16:09 <vmassol> definitely not, big -1
16:09 <vmassol> :)
16:09 <vmassol> that's the whole point
16:09 <evalica> :)
16:09 <vmassol> to be able to nav to non terminal pages easily
16:10 <abusenius> has quit
16:10 <Enygma`> tmortagne: but the WebHome could be existing, thus masking your deleted terminal that can not be undeleted now, since you don`t get to the recycle bin UI
16:10 <vmassol> tmortagne: I don't like mixing 2 pages, they're different pages
16:10 <evalica> anyway - even with a query param … the feature will be hidden and not many will know about it
16:10 <vmassol> sure
16:10 <vmassol> that's the point
16:10 <tmortagne> Enygma`: I said if the WebHome does not exist
16:10 <vmassol> it's an edge case which we woudln't promote
16:11 <tmortagne> anyway we want to end up in the WebHome when you enter A
16:12 <vmassol> my personal view is:
16:12 <msmeria> has quit
16:12 <Enygma`> yes, but if we really want to get to terminal A (which does not exist) and not non-termial A/ (that does exist), we can`t
16:12 <vmassol> - doign this automatic redirect is something on top in order to offer a shortcut
16:12 <vmassol> - we should have a way to turn this feature off if we need
16:12 <Enygma`> so yeah, a query param should probably do it
16:12 <vmassol> (hence the idea of the parameter to turn it off when needed)
16:13 <Enygma`> just that apps that use only terminal documents should pretty much use this query param
16:13 <tmortagne> Enygma`: I never told about not having the parameter, I'm talking about default behavior
16:13 <tmortagne> the parameter is the only way if we have the redirect anyway
16:13 <Enygma`> yea, I guess
16:13 <vmassol> Enygma`: yes and by default I'd add this parameter in our selenium test framework (gotoPage())
16:14 <Enygma`> vmassol: I`d prefer using it only when needed
16:14 <tmortagne> vmassol: not sure about that, the point of selenium is to mimic user behavior
16:14 <Enygma`> since we want to test regular behavior
16:14 <tmortagne> yep
16:14 <vmassol> let me rephrase, I'd add a new gotoPage() method
16:15 <vmassol> (new signature)
16:16 <vmassol> ok for "spaceRedirect=false"? (trying to be close to the method name which is redirectSpaceURLs())
16:16 <tmortagne> by the way do we have an option to disable the redirect ?
16:16 <vmassol> you mean config?
16:16 <tmortagne> yes
16:16 <vmassol> no config ATM
16:17 <tmortagne> I'm sure some already existing wikis will prefer disabling that
16:17 <Enygma`> forceTerminal=true?
16:17 <evalica> one idea would be if the user has 'Allow terminal' in profile to disable the redirect. But depends what behavior we want to promote.
16:18 <vmassol> evalica: i don't think it's a per user config
16:18 <vmassol> that would cause problems
16:18 <vmassol> you give a link to someoe… and it doesn't work
16:18 <vmassol> so for me it's a subwiki level
16:18 <vmassol> s/a/at
16:18 <evalica> other UI ideas could be: if also a terminal page exist: A. provide a warning in the UI - like a 'Do you wanted to go to X page?' or … maybe the breadcrumb could display there is an alternative :) …. anyway we could think of a solution - but again this would mean making the feature more visible.
16:19 <tmortagne> yes it's a wiki level config I think
16:19 <vmassol> (to take into account the farm mode)
16:20 <vmassol> evalica: we could have refinements later on but I think for now a param would be good
16:20 <vmassol> just need to agree on the name now
16:20 <vmassol> forceTerminal is not really the goal of this param
16:21 <vmassol> this param will be here to disable to automatic redirect when entering a space url
16:21 <evalica> well depends if you want to have a param that contains the word 'space' although we are deprecating the concept
16:21 <tmortagne> spaceRedirect is not very nice but it's the most accurate I can think of
16:22 <vmassol> @evalica: we're not deprecating the concept
16:22 <vmassol> :)
16:22 <vmassol> only in the UI
16:22 <vmassol> for ex the REST URL will still contain /spaces/ too
16:23 <vmassol> since it('s a technical param I don't see it as a problem that it contains "space"
16:23 <tmortagne> yes it's not really a problem since the param itself does not make any sense without space concept
16:24 <evalica> I'm +0
16:24 <tmortagne> (you would not have non terminal vs terminal page in a real nested documents environment)
16:25 <vmassol> Enygma`: wdyt?
16:25 <Enygma`> you will also not have spaces in a real nested documents environment :) so it`s pretty much the same from that point of view
16:25 <vmassol> yes that's thomas's point
16:25 <tmortagne> Enygma`: my point is that without spaves this paremeter would not exist
16:25 <tmortagne> s/spaves/spaces/
16:26 <vmassol> there would be no redirect
16:26 <vmassol> and no need to disable it
16:26 <Enygma`> sure, I think it`s fine and there`s really not much need to dwell on it IMO
16:26 <evalica> ?redirect=false or ?stopRedirect=true…. anyway I guess is fine ?spaceRedirect=false
16:26 <vmassol> the first 2 are too generic
16:26 <evalica> k
16:26 <vmassol> we have plenty of other rediects
16:26 <Enygma`> and conflict with xredirect
16:26 <evalica> k
16:26 <tmortagne> redirect might be understood as xredirect canceller or somehting liek this
16:26 <tmortagne> yes
16:27 <Enygma`> +1 for spaceRedirect
16:27 <vmassol> ok going for spaceRedirect for now and we have till 7.2 final to change our mind on the namin g :)
16:27 <tmortagne> anyway it's not a big deal, spaceRedirect is explicit enough and if we really want it's not very hard to add a new one later and deprecated this one
16:27 <vmassol> thanks everyone for the inpuy
16:27 <vmassol> *input
16:35 <vmassol> btw you're right, I'm not going to add any signature for gotoPage since it already supports passing a querys tring
16:45 <lucaa> has quit
16:57 <abusenius> has joined #xwiki
17:08 <gsmeria1> has joined #xwiki
17:09 <gsmeria1> has quit
17:17 <vmassol> Scheduler test should work fine now :)
17:24 <Bugen_do> has joined #xwiki
17:26 <vmassol> tmortagne: strange error: http://ci.xwiki.org/job/xwiki-platform-7.1.x/62/console
17:26 <vmassol> restarting the job...
17:27 <Trefex> has quit
17:27 <vmassol> ok all http://ci.xwiki.org/job/xwiki-enterprise-test-wysiwyg/ failing tests are caused by the create action changes
17:28 <vmassol> working on http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/LoginTest/testLoginLogoutAsAdmin/ now
17:28 <tmortagne> vmassol: looks like nexus has some issues
17:29 <vmassol> someone should check these ones:
17:29 <vmassol> - http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/EditClassTest/testAddProperty/
17:29 <vmassol> - http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui.appwithinminutes/ApplicationNameTest/testSpecialCharactersInAppName/
17:29 <vmassol> they don't seem related to the create action changes
17:29 <tmortagne> looks at http://nexus.xwiki.org/nexus/content/repositories/snapshots/org/xwiki/platform/xwiki-platform-dashboard-macro/7.1.2-SNAPSHOT/
17:29 <vmassol> then there's http://ci.xwiki.org/job/xwiki-enterprise-test-escaping/lastBuild/testReport/ to look at too
17:29 <tmortagne> the jar is here but not the pom
17:30 <vmassol> strange
17:30 <tmortagne> nexus returned a 502 when maven tried to deploy it
17:30 <tmortagne> that's the error we see at the end
17:31 <vmassol> I know, that's why I restarted the build to see if it was transient or not
17:31 <tmortagne> its not the first network related issue I see today
17:33 <vmassol> hopefully http://ci.xwiki.org/job/xwiki-enterprise-test-ui/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-ui/testReport/org.xwiki.test.ui/LoginTest/testLoginLogoutAsAdmin/ should be fixed now
17:45 <Denis> has quit
17:46 <woshilapin> Heyhey, you thought I was done for today but I don't
17:46 <woshilapin> I reach this error
17:46 <woshilapin> https://ezcrypt.xwikisas.com/C#2fu02t6L9XCzNcOvtBtSbDjF
17:46 <woshilapin> And I'm not sure of what is happening
17:46 <woshilapin> I suspect that the 'parent' in the URL contains a '.' in the name of the page and then it crashes...
17:47 <woshilapin> Should I double escape or something like that?
17:47 <_cjd_> u trollin ?
17:48 <vmassol> woshilapin: it means the URL is not valid
17:48 <vmassol> it's not properly encoded
17:48 <woshilapin> (resume: I click on a link that look like MySpace/MyPage?template=Space.PageTemplate&parent=MySpace.Some\.thing
17:48 <woshilapin> Backslash not allowed, right?
17:48 <Denis2> has joined #xwiki
17:48 <_cjd_> yeah, that \ is going to make tomcat upset
17:48 <vmassol> Caused by: java.net.URISyntaxException: Illegal character in query at index 145: http://localhost:8080/xwiki/bin/edit/mymodel/b29fcf50-4595-48a4-95a1-fc24457832ec?template=xwiki:LearnPAdCode.FeedbackTemplate&parent=mymodel.obj\.45020&LearnPAdCode.FeedbackClass_0_id=b29fcf50-4595-48a4-95a1-fc24457832ec
17:49 <woshilapin> yep
17:49 <woshilapin> The parent part is breaking
17:49 <_cjd_> encodeURIComponent() ?
17:50 <_cjd_> turns \ into %blahsomething
17:50 <_cjd_> so no more evil \
17:51 <_cjd_> ahh, you're using the normal way to create a page and it's blowing up XWiki ?
17:51 <woshilapin> $xwiki.getURL()
17:51 <_cjd_> That's deprecated, you should really use the new Component based API
17:51 <woshilapin> $xwiki.getURL(DocumentReference, 'edit', 'someparameters')
17:52 <woshilapin> haha
17:52 <vmassol> note that the query string is NOT encoded
17:52 <_cjd_> $xwiki is deprecated
17:52 <vmassol> you need to do that
17:52 <vmassol> see the javadoc
17:53 <tmortagne> woshilapin: that's called job to provider a proper query string
17:53 <tmortagne> (you can't escape a query string already created)
17:53 <tmortagne> s/provider/provide/
17:53 <woshilapin> ?
17:53 <vmassol> woshilapin: here: https://gist.github.com/vmassol/7110f663f9afe955874a
17:53 <_cjd_> He meant: It's the caller's job to provide a properly encoded query string
17:53 <vmassol> (I wrote that javadoc)
17:53 <vmassol> (it explains it)
17:54 <tmortagne> s/called/caller/
17:54 <_cjd_> $xwiki.getURL(DocumentReference, 'edit', "someparameters&$escapetool.url("\\\bsjklc]\]as")")
17:54 <_cjd_> $xwiki.getURL(DocumentReference, 'edit', "someparameters&parent=$escapetool.url("\\\bsjklc]\]as")")
17:55 <_cjd_> there ya go
17:55 <tmortagne> yes
17:55 <tmortagne> (except for the double quote inside double quote but you encode a variable I guess anyway)
17:56 <_cjd_> I think wacky double quotes in velocity does work :D
17:56 <woshilapin> OK, works
17:56 <woshilapin> Thanks
18:01 <vmassol> has quit
18:02 <ClemensR> has left #xwiki
18:04 <Denis> has joined #xwiki
18:04 <_cjd_> has quit
18:04 <Denis> has quit
18:06 <Denis2> has quit
18:27 <Pbas> has left #xwiki
18:30 <fca> has joined #xwiki
18:55 <fca> Hi, when installing XWiki 7.1.1 via WAR on Debian Jessie with Tomcat 8, Oracle JDK 8, PostgreSQL 9.4 (PGDG version), and a (apparently) working internet connection, the distribution wizard does not complete. It stops at : «Resolving extension dependency [org.xwiki.platform:xwiki-platform-user-profile-ui-7.1.1] on namespace [xwiki]» No special error message from tomcat.
19:04 <_cjd_> has joined #xwiki
19:10 <tmortagne> has quit
19:34 <evalica> fca: it's a bit late now - maybe you can write a mail on [email protected] or fill an issue
19:42 <woshilapin> has quit
20:14 <lucaa> has joined #xwiki
20:19 <lucaa> has quit
20:23 <lucaa> has joined #xwiki
20:36 <fca> evalica: I will try to find the source of the problem, or at least narrow it before posting. Installing 6.4.4 with the same stack and same config works fine. So, ATM, I'll be installing 6.4.4.
20:37 <lucaa> has quit
20:39 <evalica> k
20:44 <woshilapin> has joined #xwiki
21:55 <Slashman> has quit
22:49 <evalica> has quit
22:49 <Enygma`> has quit
