xwiki-devs October 2008

xwiki-devs@xwiki.org

40 participants
133 discussions

[xwiki-devs] geenric-webdav / jcr-webdav conflict

by Asiri Rathnayake

Hi Devs, I think it's fair to call our current webdav implementation a generic webdav server implementation for xwiki because it directly utilizes the xwiki core and presents a custom webdav view of an xwiki repository for users. At the time we began working on webdav, this is the only option we had. But with the xwiki-jcr component in town we can have a different sort of a webdav server which is kind of a ready made one which is capable of exposing any jcr repository via webdav (ex. jackrabbit jcr server). Now the conflict is now we have two webdav server implemntations, what are we going to do now ? Please excuse me for any errors since my current understanding of JCR is poor. Thanks - Asiri

16 years, 2 months

[xwiki-devs] XWiki workspace performance

by Vivian Richard

We are trying out Xwiki workspace. We find it really slow compared to Xwiki enterprise in same environment. How can we improve it's performance ?

16 years, 2 months

[xwiki-devs] DBStringList SQL query issue

by Pascal Voitot

Hello, as you may now (or even may have coded), you can put a SQL query in a DBStringList property... something like select prop.value from BaseObject as obj, StringProperty as prop where obj.name = "mydocname" and obj.className="myclassname" and obj.id.id = prop.id and prop.name = "mypropname" but you can also use 2 columns (first one for stored value and second one for displayed value) select prop.value, prop2.value from BaseObject as obj, StringProperty as prop, StringProperty as prop2 where obj.name = "mydocname" and obj.className="myclassname" and obj.id.id = prop.id and prop.name = "mypropname" and obj.id.id = prop2.id and prop2.name = "myprop2name" So then I have tried something more complex select prop.value, prop.value||prop2.value from BaseObject as obj, StringProperty as prop, StringProperty as prop2 where obj.name = "mydocname" and obj.className="myclassname" and obj.id.id = prop.id and prop.name = "mypropname" and obj.id.id = prop2.id and prop2.name = "myprop2name" or select prop.value, concat(prop.value, prop2.value) from BaseObject as obj, StringProperty as prop, StringProperty as prop2 where obj.name = "mydocname" and obj.className="myclassname" and obj.id.id = prop.id and prop.name = "mypropname" and obj.id.id = prop2.id and prop2.name = "myprop2name" and it throws some funny errors... why? In DBStringListClass, makeList transforms the SQL query to separate both columns and re-creates SQL query with one column only. But apparently, it doesn't manage such expressions... the funniest is "||" since it looks like it is rendered as a Wiki expression... regards Pascal

16 years, 2 months

Re: [xwiki-devs] [xwiki-notifications] r13414 - in sandbox/xwiki-webdav/src/main: java/com/xpn/xwiki/plugin/webdav/resources java/com/xpn/xwiki/plugin/webdav/resources/views java/com/xpn/xwiki/plugin/webdav/utils resources resources/META-INF resource

by Asiri Rathnayake

Hi Sergiu, On Fri, Oct 10, 2008 at 6:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > asiri (SVN) wrote: > > Modified: > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > > =================================================================== > > --- > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > 2008-10-08 11:28:58 UTC (rev 13413) > > +++ > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > 2008-10-08 12:12:14 UTC (rev 13414) > > @@ -9,6 +9,8 @@ > > import org.apache.jackrabbit.webdav.DavResourceLocator; > > import org.apache.jackrabbit.webdav.DavSession; > > import org.apache.jackrabbit.webdav.lock.LockManager; > > +import org.xwiki.component.manager.ComponentManager; > > +import org.xwiki.component.phase.Composable; > > > > import com.xpn.xwiki.XWikiContext; > > > > @@ -18,9 +20,14 @@ > > * > > * @version $Id$ > > */ > > -public interface XWikiDavResource extends DavResource > > +public interface XWikiDavResource extends DavResource, Composable > > { > > /** > > + * This component's role, used when code needs to look it up. > > + */ > > + String ROLE = XWikiDavResource.class.getName(); > > + > > + /** > > * Initializes this resource with common attributes inherited from > the parent. > > * > > * @param parent Parent resource. > > @@ -72,6 +79,11 @@ > > XWikiContext getXwikiContext(); > > > > /** > > + * @return The {@link ComponentManager} used to lookup components. > > + */ > > + ComponentManager getComponentManager(); > > + > > + /** > > * @return The {@link LockManager} associated with this request > (global). > > */ > > LockManager getLockManager(); > > I don't like this... a component interface should not expose the > component manager, which is supposed to be used in implementations. Please: > - remove the Composable from the interface > - add it to AbstractXWikiDavResource, if needed > - move the getComponentManager there, too, if you must > > I'm not sure you need the component manager inside all DAV resources. As > I see in the code, you only need it in the Root view, so you should only > declare that XWikiRootDavView implements Composable. > > > FYI, the XWiki helper interfaces (Composable, LogEnabled, Initializable) > are supposed to be used by implementations, not by other interfaces. Working on it. Thanks. - Asiri > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

16 years, 2 months

[xwiki-devs] [xwiki-notifications] r13428 - in sandbox/xwiki-webdav/src: main/java/com/xpn/xwiki/plugin/webdav/resources/views main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages test/java/com/xpn/xwiki/plugin/webdav/tests

by Asiri Rathnayake

---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Thu, Oct 9, 2008 at 2:09 PM Subject: Re: [xwiki-notifications] r13428 - in sandbox/xwiki-webdav/src: main/java/com/xpn/xwiki/plugin/webdav/resources/views main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages test/java/com/xpn/xwiki/plugin/webdav/tests To: XWiki Notifications <notifications(a)xwiki.org> Hi Vincent, Sergiu and all, I will try to explain the need to componetize xwiki-webdav. May be we shouldn't componetize xwiki-webdav after all ;) Following is the way we lookup for a base-view (a particular view of an xwiki-repository). Basically, when a request comes for a particular url, we take the corresponding segment of the url (nextToken here), append "-baseview" and lookup for a component with that ROLE_HINT. If found, we'll handover the job to that component. > + XWikiDavResource resource = null; > + try { > + resource = > + (XWikiDavResource) getComponentManager() > + .lookup(ROLE, nextToken + "-baseview"); > + resource.init(this, nextToken, "/" + nextToken); > + stack.push(resource); > + resource.decode(stack, tokens, next + 1); > + } catch (ComponentLookupException e) { > + throw new > DavException(DavServletResponse.SC_INTERNAL_SERVER_ERROR, e); > Bellow is where we list the set of possible views. for this i need to filter out only those views which has the "-baseview" id appended to their role hint. This is why i added the getRoleHint() method into the component interface. The use of this approach is, if someone need to add a new view, he simply have to extend the XWikiDavResource interface and have the ROLE_HINT ending like "-baseview", nothing else. The other approach is to manually load each base view using lookup("role", "role-hint") but in this case, the developer of the new view will have to change the RootView's code to load his view along with the rest of base views. > > + List<XWikiDavResource> viewsList = > getComponentManager().lookupList(ROLE); > + for (XWikiDavResource view : viewsList) { > + String componentHint = view.getRoleHint(); > + int dash = componentHint.lastIndexOf('-'); > + if (componentHint.endsWith("-baseview")) { > + String name = componentHint.substring(0, dash); > + view.init(this, name, "/" + name); > + children.add(view); > + } > + } > + } catch (ComponentLookupException e) { > + LOG.error("Unexpected Error : ", e); > May be this is a wrong approach. And yes, XWikiDavResource is not a business interface. But I think this increases the extensibility / flexibility of xwiki-webdav. To add a new view, (as i said before) extend XWikiDavResourve and end your ROLE_HINT with "-baseview". To remove an existing view, simply remove the "-baseview" part from your components.xml configuration file, that's it. I would like to know your thoughts. And i can revert these changes if necessary. Thanks. - Asiri

16 years, 2 months

[xwiki-devs] XWiki as ACEGI provider?

by Paul Libbrecht

Has anyone worked on XWiki serving the role of an ACEGI provider? (identity managed by XWiki but shared to other, in VMs, web-apps) thanks in advance paul

16 years, 2 months

by Sergiu Dumitriu

asiri (SVN) wrote: > Modified: sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > =================================================================== > --- sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java 2008-10-08 11:28:58 UTC (rev 13413) > +++ sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java 2008-10-08 12:12:14 UTC (rev 13414) > @@ -9,6 +9,8 @@ > import org.apache.jackrabbit.webdav.DavResourceLocator; > import org.apache.jackrabbit.webdav.DavSession; > import org.apache.jackrabbit.webdav.lock.LockManager; > +import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.component.phase.Composable; > > import com.xpn.xwiki.XWikiContext; > > @@ -18,9 +20,14 @@ > * > * @version $Id$ > */ > -public interface XWikiDavResource extends DavResource > +public interface XWikiDavResource extends DavResource, Composable > { > /** > + * This component's role, used when code needs to look it up. > + */ > + String ROLE = XWikiDavResource.class.getName(); > + > + /** > * Initializes this resource with common attributes inherited from the parent. > * > * @param parent Parent resource. > @@ -72,6 +79,11 @@ > XWikiContext getXwikiContext(); > > /** > + * @return The {@link ComponentManager} used to lookup components. > + */ > + ComponentManager getComponentManager(); > + > + /** > * @return The {@link LockManager} associated with this request (global). > */ > LockManager getLockManager(); I don't like this... a component interface should not expose the component manager, which is supposed to be used in implementations. Please: - remove the Composable from the interface - add it to AbstractXWikiDavResource, if needed - move the getComponentManager there, too, if you must I'm not sure you need the component manager inside all DAV resources. As I see in the code, you only need it in the Root view, so you should only declare that XWikiRootDavView implements Composable. FYI, the XWiki helper interfaces (Composable, LogEnabled, Initializable) are supposed to be used by implementations, not by other interfaces. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 2 months

[xwiki-devs] [Idea] Providing a production level packaging solution with Jetty+Derby

by Vincent Massol

Hi, I was wondering today if we could provide a production quality XE packaging. Here's what would be my combo: * Jetty 6 or 7 * Latest Derby (aka JavaDB - which is included in JDK 1.6 BTW) in embedded mode See http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-45170… for performance stats * Java Service Wrapper See http://wrapper.tanukisoftware.org/doc/english/integrate.html The nice thing with the wrapper is that it can also monitor the JVM and restart it if hung or not responding, in addition to restarting the service when the machine is rebooted of course. I'm confident that we could offer a base packaging that would work well for relatively large usages of XE and that is still small and all- preconfigured. Basically I think we could replace our current combo of Jetty 5.x + HSQLDB with this new combo and still get the best of both worlds: * simple packaging * production level quality Whereas our current standalone packaging is not production ready and is just for getting started with XWiki. WDYT? Thanks -Vincent

16 years, 2 months

Re: [xwiki-devs] [xwiki-users] Loginsubmit

by Jean-Vincent Drean

On Wed, Sep 24, 2008 at 4:44 PM, Spinring <bi2607(a)fh-weihenstephan.de> wrote: > > Hello, > > I am trying to change the registration page, so that it redirects to the > pevious page after you have registered (like after you have logged in) > > I know, that login.vm and registerinline.vm are called in global.vm. My > first try was to add xredirect=$xwiki.getURLEncoded($logredir) to the > $regurl, but it did work. The register action takes into account the xredirect and do it immediatly. [1] Anyway you could add redirect=$xwiki.getURLEncoded($logredir) to the $regurl (global.vm) And apply this to registerinline.vm #elseif($reg) + #if($request.redirect) + $response.sendRedirect($request.redirect) + #end #set($xwname = "XWiki.${request.xwikiname}") #info("$msg.get('core.register.successful', [$xwiki.getUserName($xwname), $request.xwikiname])") #end Anyway I'm not sure that you'll get the expected behavior since the user will be correctly redirected .. without being logged in. To log the user automatically after sign up (+ redirection) you can apply the following patch to registerinline.vm (replace the one above) : #elseif($reg) + #if($request.redirect) + #set ($xredirect = $xwiki.getURL("XWiki.XWikiLogin", "loginsubmit", "j_username=$!request.xwikiname&j_password=$!request.register_password&xredirect=$!request.redirect")) + $response.sendRedirect($xredirect) + #end #set($xwname = "XWiki.${request.xwikiname}") #info("$msg.get('core.register.successful', [$xwiki.getUserName($xwname), $request.xwikiname])") #end 1) While we are at it, WWYT about adding this in XE 1.7, xwiki devs ? Is it bad to have the password sent over the network once again ? 2) In this case is there a reason to keep the sendRedirect call in RegisterAction (see [1]) ? Thanks, JV.

16 years, 2 months

Re: [xwiki-devs] [xwiki-notifications] r13383 - platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/parser

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-10-07 20:01:06 +0200 (Tue, 07 Oct 2008) > New Revision: 13383 > > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/parser/SyntaxType.java > Log: > XWIKI-2744: Can't add a Parser component for an unknown syntax > * add equals and hashCode methods > Since these methods do nothing but the default, why do we need to override them? The inherited methods should be enough, no? Anyway, I'd rather have a real implementation, since we can't be sure that everybody will create syntaxes using the factory method. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 2 months

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2008