Hi,
First time I tried 'XWiki Watch' (standalone JAR). I like the idea very
much.
Is it planned to support manual added pages too? The use-case would be, if
someone finds a specific article, which other team members could maybe use
too. So instead adding the whole RSS (if even one is available) you would
just add the specific link to the article and comment it, group it, tag and
flag it...
Cheers,
Squirrel
PS: Could you maybe add a link to the actual Watch space, too (on the first
page of the installation and on the sidebar)? I tried the whole time to
click at the 'Watch' menu entry at the top, but this isn't 'XWiki Watch' but
the default watch from XWiki, I figured...*g*
Good day.
I test work of xwiki virtual mode with mysql and discovered, that if I
follow Administration Guide and create database user xwiki, than switching
between wiki-s in virtual mode is failed with exception like:
Access denied for user 'xwiki'@'127.0.0.1' to database 'a22ii'
When I set user root in hibernate.cfg.xml than all is good.
1. So, this must be noted in Administration Guide.
2. And why I write to list: I discovered that
'grant all on *.* to xwiki(a)127.0.0.1' does not fix situation ..
So, this is something wrang with my mysql ? [fresh install from Fedora9
packages] or exists some extra magic to grant access to all databases to
xwiki mysql user ?
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
Hi devs,
The current Rights implementation treats the registration as a special case, being the only right
that is denied to guests in an empty wiki.
I propose that we change this by default to be true, but allow it to be configured in xwiki.cfg (and
only there, since guests can edit XWikiPreferences).
Anyone against it?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi guys,
I know, it's kind of late to give you a general feedback for the new admin
interface, nevertheless I'd like to point some things out:
* The icons are nice, but way too big (tested on 1280x800, FF3, Opera &
Konqueror)
* In the 'Rights' section the two tables don't have the same width, though
the same content and space is unnecessarily wasted (this is true for most
sections) ..
* I miss some structure, categories...everything seems now cluttered...I
know, underneath not much changed, but compared with the previous surface
it's now quite obvious to me. Ie. the 'User' and the 'Group' section. They
just make no sense anymore. I guess you could easily integrate the 'Group'
section into the 'User' section and call it 'User Administration'. Some
clickable filter (titles like 'username' 'groupname' etc.) and a search
input-field. And instead editing the group and add a new user to the group,
you add the group(s) to the user. If you edit a group (click on the groups
name) you will then not adding users but change the rights for the group
('Rights' section)....if you add a group you give it a name and set the
groups rights.
* I miss a content overview...this interferes somehow with spaces, pages and
rights...
* The space preferences are (still) puzzling to me, although I don't have a
better solution in my sleeves...
Hmm...I don't have enough time *right now* to explain in deep what I
mean...actually I'm not quite sure about what I mean either...it's just a
feeling that there is something not quite right...I don't know. I'm sorry
I'm this late with my input...
I hope it's not useless and if so, feel free to ignore this post ;-)
I'm testing now the functional part of it.
Cheers,
Squirrel
We should separate the curriki commiters from the xwiki commiters.
We could also make the list of commiters manageable from
http://curriki.xwiki.org
We could or have to (I'm not sure if it is necessary) also move the code
to a separate svn tree
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
hi Fabio/Vincent
As you have requested, I have uploaded the sample code which uses the xwiki
parser. I have written a maven script to build the sample code. It prints
the xdom object model in to a tree structure. And it also uses the
Parser.traverse() to reprint the xwiki document to the console.
hear is the url http://svn.xwiki.org/svnroot/sandbox/xdom/
In order to undestand how the parser wokes i exaimed it with several xwiki
documents.I think there are some points needed to be clarified about the
parser.It would be greate if you can tell me the criteria which has been
used to build the xdom tree from the xwiki.
For an example consider the following xwiki
plaintext*bold~~bolditalik~~bold*
is this syntax valid?
This is the tree structure of the xdom
XDOM
---ParagraphBlock
---WordBlock
---BoldBlock
---WordBlock
---BoldBlock
---WordBlock
---BoldBlock
---WordBlock
In the above tree bolditalic part is not reflected.
Any comment on this
Thanks
-- Malaka Ekanayake
CSE UOM
Evelina Slatineanu wrote:
>
> For the new Administration application to work properly in an empty wiki
> (create users, groups, set rights etc), the following files have to be moved
> from XE to Administration:
>
> Xwiki.Admin
> Xwiki.Users
> Xwiki.XwikiUserSheet
> Xwiki.XWikiUserTemplate
> Xwiki.AdminGroup
> Xwiki.AllGroup
> Xwiki.Groups
> Xwiki.XwikiGroupSheet
> Xwiki.XwikiGroupTemplate
> Xwiki.Rights
> Xwiki.GlobalRights
> Xwiki.DefaultSkin
> Xwiki.Skins
> Xwiki.XwikiPreferences
>
Since XE will always contain Administration, I see no danger in doing this. In the end XE should
only be an empty shell with several other applications included in it.
So, +1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Jun 26, 2008, at 9:05 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-06-26 21:05:24 +0200 (Thu, 26 Jun 2008)
> New Revision: 10858
>
> Modified:
> xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/
> main/java/org/xwiki/cache/jbosscache/internal/
> JBossCacheCacheConfiguration.java
> xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/
> test/java/org/xwiki/cache/jbosscache/JBossCacheCacheTest.java
> Log:
> XWIKI-1744: Use JBoss Cache by default in XWiki
> * improve JBoss cache configuration loading
[snip]
> public void testCreateAndDestroyCacheLRUMaxEntries() throws
> ComponentLookupException, Exception
> {
> - /*CacheFactory factory = getCacheFactory();
> + CacheFactory factory = getCacheFactory();
>
> CacheConfiguration conf = new CacheConfiguration();
> LRUEvictionConfiguration lec = new LRUEvictionConfiguration();
> lec.setMaxEntries(1);
> + // Force JBoss eviction interval to the minimum
> +
> lec.put(JBossCacheCacheConfiguration.CONFX_EVICTION_WAKEUPINTERVAL,
> 1);
> conf.put(LRUEvictionConfiguration.CONFIGURATIONID, lec);
>
> Cache<Object> cache = factory.newCache(conf);
> @@ -36,19 +39,24 @@
>
> cache.set("key2", 2);
>
> + // Wait for the JBoss Eviction policy to be called
> + Thread.sleep(1000);
warning, warning, warning! (insert flashing lights here)
[snip]
> assertEquals("value", cache.get("key"));
>
> - Thread.sleep(1000);
> + // Wait for the JBoss Eviction policy to be called
> + Thread.sleep(3000);
Same, but worse... :)
This reminds me of the setSpeed() in our selenium tests that I've
removed in the RMUI tests.
Note that I'm not proposing a solution since I have no clue and
haven't read the code yet.
BTW isn't it dangerous to switch cache implementation in a RC? I'd say
it is.... I don't even think we've tested it in any real instance so
I'd be -0 to do that before testing it in real for several days/week.
WDYT?
Thanks
-Vincent
Hi everyone,
Yesterday was our third bug fixing day. The following bugs were fixed: http://tinyurl.com/6jve9d
- Sergiu
XWIKI-2498 Exporting a page with an image to PDF fails on Jetty
XWIKI-715 Arguments passed to radeox macros like {image} or {attach}
should not be rendered
XWIKI-2296 EventCalendar Exception after creating Events
XWIKI-2509 Empty StringProperty-s are loaded as null in Oracle
XWIKI-2510 Make the Link and Url filters more stable
XAPANELS-51 Context root 'xwiki' is hard coded in the search panel
- Artem
XSALBATROSS-30 Import / Export script chokes on documents with ' in
name
XWIKI-2472 Wrong mapping for stats on oracle
- Jean-Vincent
XE-256 Exception while generating lucene search RSS feed
So that's a total of 9 bugs fixed. Well done everybody and thanks to
all who participated. A special congratulations to Sergiu who's again
done more than anyone else (despite the fact that he "was busy and
wouldn't be able to do much" ;)). Another congratulations to both
Sergiu and Artem who have participated to all 3 bugfixing days so far.
Total High Score Bugs Fixed Over All BugFixingDay Sessions:
* Sergiu: 13
* Artem: 4
* Thomas: 4
* Fabio: 4
* Vincent: 2
* Jean-Vincent: 1
Let's try to beat sergiu next time ;)
Thanks
-Vincent