Hi,
I've been thinking a lot about the Container component I introduced
and while writing unit tests for some of the new rendering classes I
realized there was something not right: it's not normal that the HTML
exporter or the rendering module depend on the Container object, and
especially on the Request.
Thus I'd like to introduce the notion of Execution Context (EC in
short).
The idea is that the xwiki entry points depend on the environment
(Servlet, Portlet, etc) but those entry points create an Execution
Context which is then used by the core components, independently of
the environment. For example the VelocityContext is now put in the EC
and not in the Request object.
The Container objects still exist and can be used where required but
it's expected that they should not be used since that makes the code
dependent on the environment.
This solves issue I had with code that don't have a request.
I have it done on my machine. WDYT? Ok to commit?
Thanks
-Vincent
PS: BTW this makes it very similar to the current XWikiContext (which
is good) with the exception that the Container objects are not located
inside the EC but as separate threadsafe variables.
Hi,
I want to develop a component to handle office documents in xwiki. As we
discussion before, I want to use openoffice api. I set a openoffice develop
environment in my pc running ubuntu 8.04, and learn how to use openoffice
api. Yes, The oo sdk is powerful to address office documents, MS doc, MS
excel...
But there's a problem. AFAIK, openoffice api need a openoffice local runtime
or a remote server running openoffice. The whole openoffice runtime is 356M,
more or less, so we shouldn't contain it in xwiki release. Hense, I think if
we want the office importer run in a computer, the computer should have
installed openoffice or configurate a remote openoffice server.
WDYT?
I need some suggestion.
Thanks.
--
Sincerely,
Wang Ning
Hello devs,
XWS 1.1 M2 was originally planned for May 26th. Unfortunately, I have been
taken by other projects and could not stick to that date. I give you here
a status on what needs to be achieved and new dates proposal.
For me, the consequent tasks left to be done for us to be feature closed
for M2 are the following:
* XWS-7 (Manage groups of administrators & power users). It has been
started by Florin. For me it's 80% complete today. Florin will continue to
work on it.
* XWS-79 (Invitation management). About 50% complete.
* XWS-23 Support public registration
As for dates, here is my proposal :
* 1.1 M2 next Monday (June 9th)
* 1.1 RC1 on June 19th
* 1.1 RC2 or 1.1 final on June 30th.
wdyt ?
Regards,
Jerome.
Good day community.
I want to ask again about XWIKI-2006 issue.
http://jira.xwiki.org/jira/browse/XWIKI-2006
Now I find the way to change initialization of hibernate (instead calling of
setDatabase in the beginning of each session) for non-virtual mode. [attached
as configurated_db_schema_07.patch] Can I ask committers to review one ?
(See previous discussion in this mail list
http://markmail.org/message/6mtyxwff4ccmn3lk)
We have 2 votes for previous patch. We need three [as I remember rules of this
game] -- yet one vote, please ;)
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
Hi devs.
I would like to propose:
1. Make all xwiki stores as components.
So they will be constructed via our ComponentManager.
2. Deprecate all store public constructors.
Because they are useless for components.
3. Add SessionFactory component to all hibernate stores.
this will fix XWIKI-2332: Share one session factory among all hibernate
stores.
move all hibernate configuration to SessionFactory component.
one SessionFactory is shared by all stores by default (configured in
components.xml).
here is tentative interface SessionFactory {
Session openSession()
Configuration getConfiguration()
/** rebuild session factory with new configuration. needed for inject
hibernate custom mappings. */
void updateConfiguration(Configuration cfg)
}
4. Add QueryManager component to main store (XWikiStoreInterface)
WDYT?
--
Artem Melentyev
Hi,
As XE 1.5M1 is now released, I would like to released XEM 1.3M1 based
on it after XEM 1.2 final release.
The pure XEM modification part is the same as XEM 1.2 final but with
all new XE 1.5 branch features.
See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM13M1
Here is my +1
--
Thomas Mortagne
Hi XWikiers,
XWiki Enterprise 1.4 has introduced a regression for group management
in farm mode.
We strongly suggest to use XWiki Enterprise 1.3.2 if you are upgrading
a wiki farm before the 1.4.1 release.
XWiki Enterprise 1.4.1 is planned on june 2nd and will be performed by
Thomas Mortagne, it will include the following fixes :
* XWIKI-2413 : Global groups are not taken into account in a virtual wiki
Anything missing in the list ?
Thanks,
--
Jean-Vincent Drean
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.5 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
First milestone of the XWiki Enterprise 1.5 version.
Main changes:
* LDAP support improvements
** Add possibility to map one LDAP group with more that one XWiki group
** Add the ability to configure LDAP groups classes and members fields names
** LDAP authenticator re-save user page even there is no modification
** "userPassword" LDAP field should be configurable
** Makes the SSL provider implementation used to support LDAP
communication over SSL configurable
** LDAP authentication print error message with empty "group_mapping" property
* Better PDF export support
* Have "from" (second to last version) and "to" (last version) fields
checked by default in the the document history
* Ability to change just one (or several) object properties
* Automatic logging of deprecated method calls in Velocity
* Better language negotiation
* Don't display the login link on the login page
Note that the general goals of XE 1.5 are :
* More bug fixes
* Better performance
* More automated tests
* Overhaul of the Administration
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise15M1
Thanks,
The XWiki dev team