Hi comitters,
As soon as Jean Vincent will finish XE 1.3.2 release I would like to
release a new XEM 1.1 branch release to benefit from all major bugs
fixed in XE 1.3.1 and 1.3.2.
I also backported XEM/XWWM 1.2 bug fixes in 1.1 branch.
See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM111 for more.
Here is my +1.
--
Thomas Mortagne
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.3.2
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is a bug fix release.
Bugs fixed
* XWIKI-2283 - Overwrite on importing translation documents deletes
the original document too
* XWIKI-2293 - PropertyChangedRule does not work
* XWIKI-2298 - Character escaping using \ doesn't work anymore
* XWIKI-2299 - The XWiki object is created more than once
* XWIKI-2300 - HibernateStore synchronization problem
* XWIKI-2304 - When a user or a group is removed it's not removed from
rights objects
* XWIKI-2309 - Migration between xwiki 1.1.x and 1.2.x (and above) can
fail because of some documents
* XWIKI-2302
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise132
Thanks,
The XWiki dev team
We'd like to release XE 1.3.2 as soon as possible. Here are the bugs
fixed since 1.3.1 :
* [XWIKI-2298] - Character escaping using \ doesn't work anymore
* [XWIKI-2299] - The XWiki object is created more than once
* [XWIKI-2300] - HibernateStore synchronization problem
Anything else that would be required for 1.3.2 ?
I'd like to follow the "72h rule" for this vote so the release would
take place on april 14 (next monday).
Here's my +1
Thanks,
--
Jean-Vincent Drean
Hi SOC mentors,
We need to finalize our sorting/ranking of all the SOC applications
we've received.
I propose a Skype conf call tomorrow at 15:00 Paris time.
Thanks
-Vincent
Hi,
I am working with Xwiki . I made changes in the .CSS and Velocity
templates.
My database is Mysql and its working very fine But recently I
have to put a new setup of XWIKI into a new System .
Everything going well but when restart the Tomcat 5.0 then the
Xwiki automatically changing the version.
From Version 1.0 to 0.9 version .i m unable to root out this
problem.
Thanks and regard
Pramit
*********************************************************************************************************************************************
This e-mail communication and any attachments may be privileged and confidential to Hexaware and are intended only for the
use of the recipients named above. If you are not the intended recipient, please do not review, disclose, disseminate,
distribute or copy this e-mail and attachments. If you have received this email in error, please delete the same alongwith
all attachments thereto and notify us immediately at mailadmin(a)hexaware.com <mailto:mailadmin@hexaware.com>.
*********************************************************************************************************************************************
>
>
> Message: 10
> Date: Mon, 14 Apr 2008 12:02:19 -0500
> From: "Kamna Jain" <kammy.scorpi(a)gmail.com>
> Subject: [xwiki-devs] Integrating Java Swing components with Xwiki
> To: devs(a)xwiki.org
> Message-ID:
> <fb681d280804141002k18a26459rdb4cc748d73d1b86(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello Devs,
>
> This is regarding the capability to upload Multiple files at a time to
> Xwiki.
> I understand that currently the attach functionality is rendered using
> HTML.
> The HTML file upload control does not allow mutliple files to be
> selected/uploaded at one time.
>
> Hence, I looked the JFileChooser component of Java Swing. I can write a
> Class that brings up a JFileChooser object and allow multiple selections
> at
> once.
> But, I am not sure how to integrate this functionality with Xwiki ,
Velocity is a scripting language to render web pages where as swing
component is a desktop based application, unless swing components are
embedded inside an applet
>
> especially with the Velocity templates (which are used to render the
> pages).
> Few Questions:
>
> 1) in order to achieve this, do I need to create a velocity template that
> will render the fileChooser on the XWiki page ?
>
No I don't think velocity can render JFileChooser
> 2) If yes, how do I accomplish this? create a new "action" and then write
> the render and action methods for that?
>
> 3) If no, what are my other options to achieve this?
>
Try to look for ajax components which achieve the the same functionality as
JFileChooser
>
> Please guide me.
> Thanks
>
>
> ------------------------------
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
> End of devs Digest, Vol 10, Issue 47
> ************************************
>
Hello Devs,
This is regarding the capability to upload Multiple files at a time to
Xwiki.
I understand that currently the attach functionality is rendered using HTML.
The HTML file upload control does not allow mutliple files to be
selected/uploaded at one time.
Hence, I looked the JFileChooser component of Java Swing. I can write a
Class that brings up a JFileChooser object and allow multiple selections at
once.
But, I am not sure how to integrate this functionality with Xwiki ,
especially with the Velocity templates (which are used to render the pages).
Few Questions:
1) in order to achieve this, do I need to create a velocity template that
will render the fileChooser on the XWiki page ?
2) If yes, how do I accomplish this? create a new "action" and then write
the render and action methods for that?
3) If no, what are my other options to achieve this?
Please guide me.
Thanks
The XWiki development team is pleased to announce the release of XWiki
Workspaces 1.0 RC 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is the first release candidate for the 1.0 version of XWiki
Workspaces. A second release candidate is planned for next monday, before
hopefully being able to deliver the 1.0 final release.
Bug fixed since 1.0 Milestone 2 :
* XWS-17 - JavaScript error when uploading photos
* XWS-29 - With IE6, selected users does not appear in the list when
adding members to a space group
* XWS-33 - On a private workspace, only admins can access content, not
writers and readers
* XWS-37 - Readers are not displayed in the directory of a space
* XWS-38 - List numbers are not shown in the WYSIWYG & view mode
* XWS-40 - Lightboxes are displayed real bad in IE6
* XWS-41 - Writers and readers rights are inverted in a workspace
* XWS-42 - Impossible to set a category for a Wiki Page : the active
field is automatically changed when we click on the categories Select
* XWS-43 - A macro is not evaluated when comparing two versions
* XWS-49 - The tooltips displayed when we are over the "My Profile" &
"MyDashboard" buttons are not translated
* XWS-50 - The dates are formated differently on the different pages
* XWS-56 - Comments do not show up anymore in wiki pages, blog posts
and photo albums
* XWS-59 - Missing activitystream hibernate mapping in the war
distribution
* XWS-60 - Galleries with empty description generates two entries in
gallery list
For more information, see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces10RC1
Regards,
The XWiki dev team
Dear all,
I've sent a patch on the Jira for a first version of the new XMLRPC
layer.
(http://jira.xwiki.org/jira/browse/XWIKI-1560)
This is a message just to let you know, since the Jira notification
message might have been passed unnoticed.
I don't have the rights to commit on the core so this patch should be
reviewed and applied by some core committer.
Following Sergiu's message about quality, I tried to keep a very high
quality standard for the code (tests are provided as well).
I'm getting back to XEclipse coding now since the XMLRPC API now has
support for Object edition and other niceties (e.g., translations,
attachments, revisions)
Let me know if there are issues.
Thanks.
Cheers,
Fabio
Dear developers,
while fixing the PropertyChangedRule class (XWIKI-2293) I found that there
is no way I can improve the code without breaking the current behaviour:
right now, since the className parameter is ignored, upon adding a
PropertyChangedRule with no className, the property change is checked on
the object returned by XWikiDocument.getxWikiObject() (which is the first
object of the class defined in the document). This behaviour makes no
sense in the context of a correctly implemented PropertyChangedRule: there
might be more than one object of that type so why check only on the first
and not all of them, why use the class defined by this document as default
in the first place and not test the specified property on all objects,
etc.
There are two choices:
1) break current behaviour and correctly implement the PropertyChangedRule
2) keep the current PropertyChangedRule class but deprecate it and add a
new notification rule class that would correctly implement the property
change rule.
I prefer the first one, since we can consider the current behaviour to be
buggy and this to be the fix, but the choice depends on actually how much
this would impact existing code, how much code relies on the current
behaviour to create PropertyChangedRules with unspecified classNames.
In the core, the only place where PropertyChangedRule is used is to
re-prepare plugins when the plugin preference is changed in
XWiki.XWikiPreferences, but there might also be some code in products,
xwiki applications, etc.
Here's my +1 for 1), but I would like to get some opinions on this from
the developers.
Also, since the PropertyChangedRule behaviour on unspecified className or
propertyName is ambiguous I propose to consider the rule as incompletely
specified if one of the two is missing and therefore never send
notifications from such a rule (though it wouldn't be consistent with
DocObjectChangeRule who is currently checking all objects on null
className).
Here's my +1 for this one, too.
WDYT?
Happy coding,
Anca
Hi devs,
There's a blocker issue preventing the finalization of the
SkinExtensions implementation
(http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions). To explain
a bit what the problem is:
- skin extensions are javascript or css pseudo-files, which are included
("linked to") in generated XHTML pages
- a skin extension is "requested" by some code using, for example,
$xwiki.jsx.use("XWiki.RightsManagement"); while generating the content,
the jsx plugin builds a list of used extensions
- after the whole page is parsed, the generated content must also
include the links to the needed extensions
The problem is that these links must be placed in the head part of the
HTML, which is generated before the body, where the extensions are
actually pulled in. This means that sometime after the parsing is done,
and before sending the response to the client, some code must insert
those links in the response. My dilemma was where...
One solution was to use the new notification mechanism to send some
parsing events that would allow listeners to change the content when the
parsing was done. Vincent opposed, so I dropped the idea.
Another solution would have been to write a Filter that would intercept
the response and insert the links, but the problem is that the filter is
isolated, without access to the context, the xwiki object, or the
jsx/ssx plugins. The component manager _could_ be a solution, but for
the moment it still needs the context, which is not available.
Another solution is to just modify Utils.parseTemplate, but this is not
elegant. It is more like a patchy workaround that would increase the
messiness of the code even more, so I'm against it.
Another solution could have been the existing plugin.endRendering, but
it is called many times during a request, and only when rendering with
Radeox, not when parsing, so it would not be called for the whole
template (so the html header would be left out).
The best solution I could come so far is to add two methods to the
PluginInterface, beginParsing and endParsing, called before and after
parsing the resulting template. This is generic enough, as it can be
used by other plugins, there's no code targeting exactly the jsx and ssx
plugins, it is extensible enough to allow other type of extensions to be
added (link extensions?), and except the StrutsActions which cannot be
added dynamically (at least not yet) it allows the SkinExtensions
implementation to be completely pluggable.
So, beginParsing will be called in com.xpn.xwiki.web.Utils.parseTemplate
before parsing the template that generates the response, and it allows
plugins to initialize some per-request variables. endParsing will be
called in the same method, right after generating the response, and will
allow plugins to change the resulting response or cleanup resources. The
signature of these methods would be:
public void beginParsing(XWikiContext context)
public String endParsing(String content, XWikiContext context)
endParsing could also be used by the FileUploadPlugin to cleanup the
resources (see
http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/core/trunk/xwiki-cor…
).
Now, the thing that I don't like is that this changes a public
interface, used by many plugins. It is good that most plugins extend
DefaultPlugin, as there is only one place where these methods must be
implemented, so the impact on existing plugins should be minimal. I also
don't like that the plugin interface contains so many methods, but that
is an acknowledged problem and it will be solved when everything would
be a component. Until then, these two methods seem to me like they
should already be there, given the other rendering-related methods.
Any other (better) solutions I didn't see? Objections to this change?
Thanks,
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi, devs.
How would you name a special "empty" store class used when some store
feature is disabled? (see FakeAttachmentVersioningStore, XWIKI-2275)
1 Void
2 Empty
3 Disabled
4 Dummy
5 Mock
6 else?
Vincent Massol wrote:
> I'm not sure if "Fake" is the best word to use...
>
> I don't think it's a Fake one. It's an empty implementation that does
> nothing. so I'd rather call it: VoidAttachmentVersioningStore or
> EmptyAttachmentVersioningStore.
>
> Also I'd replace the comment like:
>
>> + public void deleteArchive(XWikiAttachment attachment,
>> XWikiContext context,
>> + boolean transaction) throws XWikiException
>> + {
>> + // not needed
>> + }
>
> with:
>
> "// Don't do anything since it's a void implementation."
>
> WDYT?
Ok. I'll replace.
--
Artem Melentyev
Hello,
I would like to make a small modification to the XWikiLogin page on a
local xwiki instance xwiki v 1.3 to better understand the different
layers of configuration available for xwiki. There is an error occurring
on this login page when xwiki is configured for LDAP authentication. When
a user enters incorrect credentials, the login page does not provide any
indication of an error while the LDAP.LDAPAuthServiceImpl class returns
"LDAP Bind failed with Exception Invalid Credentials".
What is the best route for adding error notification into the XWikiLogin
page in the event of an invalid LDAP credentials error is propagated from
LDAP.LDAPAuthServiceImpl?
Thank you
Ross
The XWiki development team is pleased to announce the release of XWiki
Enterprise Manager 1.2 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release follow XWiki Enterprise 1.4 Milestone 1 release to
maintain XEM synchronised with XE.
Changes from 1.1:
The main change is XWiki Enterprise upgrade from 1.3 to 1.4M1.
Wiki Manager also fix a bug in translations page and is now able to
create a wiki with the name of one that just been deleted.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12M1
Thanks -The XWiki dev team
Hi comitters,
As XE 1.4M1 has been released and to follow its releases I would like
to release XEM 1.2M1.
Modification since XE 1.1 :
- XE 1.3 to XE 1.4M1 modifications.
- XAWM-63: Broken translations in wikis descritors sheet page
- XAWM-62: Can't recreate a wiki which just been deleted
Thanks,
--
Thomas Mortagne
Hello Devs,
I have been trying to figure if there is a possibility of adding HTML forms
(UI to obtain input from users) to Xwiki as part of the application we are
trying to build.
I know that XWiki pages can be edited to include HTML code in them. But, I
guess my question is where should we be looking in the code to see how the
data that goes into the form fields as user input, would be processed by the
XWiki Core?
Has anyone done this before ?
Also, if we wanted to create standard UI in XWiki, would it be a better
option to create a template (.vm) file for this purpose?
We also looked at creating Classes and Objects for this purpose but, I am
not sure if thats the option we need to choose.
What would be the best way to accomplish this task?
Thanks for all help.
Hi JV,
Are you sure about this patch?
It looks like it's adding a synchronize() that was not there before
and thus all threads will be waiting on this synchronize. Since
checkHibernate is called for all database access I'm worried this
could lead to performance issues.
Has this been tested for performance with a tool like JMeter to
simulate multiple users?
Note that I haven't analyzed the patch. I'm just worried that we might
be introducing a regression in term of performance.
If the session factory is only created once then maybe it should be
created on app init?
Thanks
-Vincent
On Apr 10, 2008, at 6:21 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2008-04-10 18:21:07 +0200 (Thu, 10 Apr 2008)
> New Revision: 9071
>
> Modified:
> xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/
> java/com/xpn/xwiki/store/XWikiHibernateBaseStore.java
> Log:
> XWIKI-2300 : HibernateStore synchronization problem
>
> Applied patch by Raffaello Pelagalli without modification. Added
> comment.
>
> Modified: xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/
> main/java/com/xpn/xwiki/store/XWikiHibernateBaseStore.java
> ===================================================================
> --- xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/
> java/com/xpn/xwiki/store/XWikiHibernateBaseStore.java 2008-04-10
> 14:45:54 UTC (rev 9070)
> +++ xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/
> java/com/xpn/xwiki/store/XWikiHibernateBaseStore.java 2008-04-10
> 16:21:07 UTC (rev 9071)
> @@ -510,13 +510,18 @@
> */
> public void checkHibernate(XWikiContext context) throws
> HibernateException
> {
> -
> + // Note : double locking is not a recommended pattern and
> is not guaranteed to work on all
> + // machines. See for example http://www.ibm.com/developerworks/java/library/j-dcl.html
> if (getSessionFactory() == null) {
> - initHibernate();
> -
> - /* Check Schema */
> - if (getSessionFactory() != null) {
> - updateSchema(context);
> + synchronized(this) {
> + if (getSessionFactory() == null) {
> +
> + initHibernate();
> + /* Check Schema */
> + if (getSessionFactory() != null) {
> + updateSchema(context);
> + }
> + }
> }
> }
> }
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
I've just downloaded the war file, imported it into IBMs RAD
Deveolopment environment and followed the Installation and configuration
steps to utilize this with our existing Oracle9i Enterprise Edition
Release 9.2.0.8.0 database.
I tried using a db user other then 'xwiki' by updating the
hibernate.cfg.xml file, however, there appears to be some hardcoding
somewhere because none of the table were being created and I was getting
a db connection exception saying xwiki doesn't exist. Created the xwiki
users, updated the hibernate.cfg.xml file and all the tables were
created just fine.
I am getting the following error at server startup however. Any ideas?
[4/10/08 11:22:11:566 EDT] 00000013 ServletWrappe I SRVE0242I:
[xWiki-EAR] [/xwikiApp] [action]: Initialization successful.
[4/10/08 11:22:11:597 EDT] 00000013 ServiceLogger I
com.ibm.ws.ffdc.IncidentStreamImpl initialize FFDC0009I: FFDC opened
incident stream file C:\Program
Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_10181018_08.04.10_11.22.11_0.txt
[4/10/08 11:22:11:722 EDT] 00000013 ServiceLogger I
com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC
closed incident stream file C:\Program
Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_10181018_08.04.10_11.22.11_0.txt
[4/10/08 11:22:11:753 EDT] 00000013 WebApp E Error while adding
servlet mapping for servlet : action :
java.lang.Exception: Mapping clash for
ServletWrapper[action:[action:/bin/*, action:/testbin/*,
action:/xwiki/*]]: Target
com.ibm.ws.portletcontainer.portletserving.PortletServingExtensionProcessor@9160916
already exists at node xwiki
at com.ibm.ws.util.ClauseNode.add(ClauseNode.java:59)
at com.ibm.ws.util.URIMatcher.put(URIMatcher.java:131)
at com.ibm.ws.util.URIMapper.addMapping(URIMapper.java:47)
at
com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:495)
at
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:304)
at com.ibm.ws.wswebcontainer.webapp.WebApp.initialize(WebApp.java:285)
at
com.ibm.ws.wswebcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:88)
at
com.ibm.ws.wswebcontainer.VirtualHost.addWebApplication(VirtualHost.java:157)
at
com.ibm.ws.wswebcontainer.WebContainer.addWebApp(WebContainer.java:655)
at
com.ibm.ws.wswebcontainer.WebContainer.addWebApplication(WebContainer.java:608)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:335)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:551)
at
com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1312)
at
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1129)
at
com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:569)
at
com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:814)
at
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:965)
at
com.ibm.ws.runtime.component.ApplicationMgrImpl$AppInitializer.run(ApplicationMgrImpl.java:2131)
at
com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:341)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
-=-----------------------------------------------------------------------------------------------------------------
Hi,
Since I'm working on the new rendering component it's a good time to
decide if we want a special wiki syntax for special icons such as for
emoticons and more.
For example Confluence has these:
http://snipplr.com/view/4931/confluence-emoticons/
I can think of 2 solutions for us:
1) we do the same, i.e. introduce new syntax for these
2) we rely on a macro instead (for ex: {icon:name/})
1) looks more natural for end users while 2) is more extensible (and
would allow us to include the whole Tango library for ex: http://tango.freedesktop.org/images/2/20/Tango-feet.png)
. 1) is also way more complex to implement than 2).
For 2) we would need to find some way so that it's easy for the user
to enter (of course the WYSIWYG editor could have a nice selector for
that macro but it would also be nice if it were not too hard to enter
in wiki mode).
WDYT?
Thanks
-Vincent
Hi Artem,
In general whenever you make a commit you must reference a JIRA issue
in your commit.
The reason is to keep tracability. If you don't put a jira issue then
this commit will not
appear in the subversion tab in jira for example.
The format we use is:
"
<JIRAID>: <JIRA description>
<optional comment here>
"
Thanks
-Vincent
On Apr 10, 2008, at 4:11 PM, amelentev (SVN) wrote:
> Author: amelentev
> Date: 2008-04-10 16:11:38 +0200 (Thu, 10 Apr 2008)
> New Revision: 9068
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/hibernate/HibernateAttachmentVersioningStore.java
> Log:
> [misc] a bug in my prev commit
>
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/store/hibernate/HibernateAttachmentVersioningStore.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/hibernate/HibernateAttachmentVersioningStore.java 2008-04-10
> 14:07:22 UTC (rev 9067)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/hibernate/HibernateAttachmentVersioningStore.java 2008-04-10
> 14:11:38 UTC (rev 9068)
> @@ -60,6 +60,7 @@
> {
> try {
> final XWikiAttachmentArchive archive = new
> XWikiAttachmentArchive();
> + archive.setAttachment(attachment);
> executeRead(context, bTransaction,
> new HibernateCallback<Object>() {
> public Object doInHibernate(Session session)
> @@ -73,7 +74,6 @@
> return null;
> }
> });
> - archive.setAttachment(attachment);
> attachment.setAttachment_archive(archive);
> return archive;
> } catch (Exception e) {
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications