xwiki-devs November 2008

xwiki-devs@xwiki.org

36 participants
108 discussions

[xwiki-devs] [XAOFFICE] [Proposal] Should we respect style / font attributes when importing office documents ?

by Asiri Rathnayake

Hi Devs, When converting office documents into html (before they are transformed into xwiki syntax) lots of style information gets added into the html. For an example : Text in a superscriptformat And finally when this is transformed into xwiki syntax, the result will look something like : (% class="western" %) Text in a ^^(% style="color:;font-family=;font-size=2pt;" %)superscript^^(%%) format The problem with this is, the resulting xwiki document will have lot's of (%%) elements which makes it difficult to make modifications in wiki mode. And another argument is that content is more important than style (vincent). So, there are three options : 1. Rip off style information. 2. Keep style information as it is. 3. Give the user an option to select between 1 and 2. I'm going with 3. :) WDYT ? Thanks. - Asiri [image: Asiri Rathnayake's Facebook profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r13942 - in sandbox/xwiki-plugin-officeimporter/src: main/java/com/xpn/xwiki/plugin/officeimporter/filter main/java/com/xpn/xwiki/plugin/officeimporter/transformer test/java/com/xpn/xwiki/plugin/officeconverter

by Vincent Massol

Hi Asiri, On Nov 4, 2008, at 5:47 AM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-04 05:47:05 +0100 (Tue, 04 Nov 2008) > New Revision: 13942 > > Added: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HtmlFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HtmlStylesFilter.java > Removed: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HTMLFilter.java > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/EmptyLinkFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ImageTagFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/PinLiFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/TagRemoveFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/UnderlineLinkFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/XWikiSyntaxEscapeFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiTransformer.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiTwoZeroTransformer.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiXhtmlTransformer.java > sandbox/xwiki-plugin-officeimporter/src/test/java/com/xpn/xwiki/ > plugin/officeconverter/HtmlFilterTest.java > Log: > JIRA : http://jira.xwiki.org/jira/browse/XAOFFICE-1 This is not the way we use to comment. Please use instead this format: XAOFFICE-1: <description of issue as in jira here> * Additional information here Thanks -Vincent

16 years, 1 month

[xwiki-devs] XWikiContext cloning

by Sergiu Dumitriu

Hi devs, We all know that the old XWikiContext is a burden that must still be carried around, in order to access any non-componentized functionality. The problem is that a context object is not supposed to be used by more than one thread. Example of non-threadsafe parts of the context are: - the Hibernate session - the request and response objects, cleared by the container - the velocity context - the XClass cache - the current wiki name - and maybe others This single-thread restriction is generally acceptable, since most of the code is executed in the single-threaded request-response workflow. Yet, some plugins execute in separate threads, for example the Lucene indexer and the scheduler plugin, and they need their XContext object. The current strategy is to clone the context and remove some of the dangerous elements listed above. This is not good, since: - it has to be done in every plugin that creates threads (duplication) - adding more non-threadsafe things to the context requires that all these plugins are changed - some non-threadsafe things might not yet be identified, and they surface sometimes as unidentified bugs - some things cannot be cleared from the outside (for example the XClass cache, which is a private member of the context) There are several solutions to this problem: 1. Override the clone() method to remove non-threadsafe elements from the cloned context. Pro: removes duplication Pro: establishes a safe clone method for all the codebase Con: some unsafe things might be overlooked, surfacing from time to time in rare thread inter-weaving. 2. Override the clone() method to create a blank context and only copy what needs to be part of any context. Pro: same as above, but also eliminates all possible non-threadsafe elements. Con: We might overlook something that needs to be part of the context. The advantage over option 1 is that this is always reproducible, and a simple stack trace is enough to spot the problem, unlike multithreaded issues. Con: We might introduce a regression, this needs to be tested well. 3. Override the clone() method to just eliminate non-threadsafe things that are unaccessible from outside (the XClass cache is the only one I see). Pro: keeps the current behavior, reducing the risk of regressions. Con: Doesn't really solve the problem. I'd go with option 2. Any other opinions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r13932 - sandbox/plugins/comments

by Vincent Massol

There's something wrong here. All projects in sandbox should use the SANDBOX JIRA project and only move to their own jira project when they graduate out of the sandbox. We have the exact same problem for the XOFFICE JIRA project. Let's leave them like this for now but please in the future follow this rule (which we had agreed on previously on the dev list). Thanks -Vincent PS: I should have raised this earlier on but I'm lagging behind on my mail on the list... On Nov 3, 2008, at 5:26 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2008-11-03 17:26:43 +0100 (Mon, 03 Nov 2008) > New Revision: 13932 > > Modified: > sandbox/plugins/comments/pom.xml > Log: > XACOMMENTS-1 Implement the initial feature set of the new comments > application > > * Set the plugin version to 1.0-SNAPSHOT > * Temporary set the dependency towards xwiki-core to 1.5.2, until I > resolve the need to have a patched core. (Currently, one need to > patch the 1.5.2 tag of xwiki-core to be able to build this comments > plugin.) > > Modified: sandbox/plugins/comments/pom.xml > =================================================================== > --- sandbox/plugins/comments/pom.xml 2008-11-03 13:18:22 UTC (rev > 13931) > +++ sandbox/plugins/comments/pom.xml 2008-11-03 16:26:43 UTC (rev > 13932) > @@ -31,7 +31,7 @@ > <version>10-SNAPSHOT</version> > </parent> > <artifactId>xwiki-plugin-comments</artifactId> > - <version>0.1-SNAPSHOT</version> > + <version>1.0-SNAPSHOT</version> > <name>XWiki Platform - Plugins - Comments</name> > <packaging>jar</packaging> > <description>XWiki Platform - Plugins - Comments</description> > @@ -39,7 +39,7 @@ > <dependency> > <groupId>com.xpn.xwiki.platform</groupId> > <artifactId>xwiki-core</artifactId> > - <version>1.6-SNAPSHOT</version> > + <version>1.5.2</version> > <scope>provided</scope> > </dependency> > </dependencies>

16 years, 1 month

[xwiki-devs] Compass and Hibernate Search

by Vincent Massol

I think it would be nice to look at Compass (http://www.compass-project.org/overview.html ) or Hibernate Search (http://www.hibernate.org/410.html) for the future. I think Compass is better for us since we don't want to rely on Hibernate for our storage in the future. Here are some features of Compass: " - Simple Compass provides a simple API for working with Lucene. If you know how to use an ORM, then you will feel right at home with Compass with simple operations for save, and delete & query. - Lucene Building on top of Lucene, Compass simplifies common usage patterns of Lucene such as google-style search, index updates as well as more advanced concepts such as caching and index sharding (sub indexes). Compass also uses built in optimizations for concurrent commits and merges. - Mapping Compass provides support for mapping of different data "formats" - indexing and storing (caching) them in the Search Engine: Object to Search Engine Mapping (using annotations or xml), XML to Search Engine Mapping (using simple xpath expressions), and the low level Resource to Search Engine Mappping. - Tx Compass provides a transactional API on top of the Search Engine supporting different transaction isolation levels. Externally, Compass provides a local transaction manager as well as integration with external transaction managers such as JTA (Sync and XA), Spring, and ORM ones. - ORM Compass integrates seamlessly with most popular ORM frameworks allowing automatic mirroring, to the index, of the changes in data performed via the ORM tool. Compass has generic support for JPA as well as embedded support for Hibernate, OpenJPA, TopLink Essentials, and EclipseLink allow to add Compass using three simple steps. - Spring Compass integrates seamlessly with Spring. Compass can be easily configured using Spring, integrates with Spring transaction management, has support for Spring MVC, and has Spring aspects built in for reflecting operations to the search engine. - Distributed Compass simplifies the creation of distributed Lucene index by allowing to store the Lucene index in a database, as well as storing the index simply with Data Grid products such as GigaSpaces, Coherence and Terracotta. " The last point is especially important for our distributed lucene searcg feature developed during the GSOC. Thanks -Vincent

16 years, 1 month

[xwiki-devs] Adding MS Office integration project to jira

by Florin Ciubotaru

Hi devs, We need to create a jira project for the MS Office integration. Jerome has proposed to put in "XWiki Core & Products" section, with the "*XOFFICE*" key. WDYT? The first Add-in in the suite will be the Word Add-in and is currently named *XWriter*( XWord is another option). I target the first milestone release on November 19th, and a first final version somewhere around XE 1.8 final release date. The solution also contains a project named *XWikiLib*. This is an assembly that will contain most logic for the server connection and other utilities. It might be useful for other members of the community that may want to connect to XWiki from a .NET client. Regards, Florin Ciubotaru

16 years, 1 month

[xwiki-devs] Fwd: [ANN] Maven Release Plugin 2.0-beta-8 Released

by Vincent Massol

Could be a good idea to upgrade... Maybe we could try it during the next release? Thanks -Vincent Begin forwarded message: > From: "Olivier Lamy" <olamy(a)apache.org> > Date: October 30, 2008 11:42:18 PM CEST > To: "Maven Users List" <users(a)maven.apache.org>, announce(a)maven.apache.org > Cc: "Maven Developers List" <dev(a)maven.apache.org> > Subject: [ANN] Maven Release Plugin 2.0-beta-8 Released > Reply-To: "Maven Developers List" <dev(a)maven.apache.org> > > The Maven team is pleased to announce the release of the Maven Release > Plugin, version 2.0-beta-8. > > http://maven.apache.org/plugins/maven-release-plugin/ > > You should specify the version in your project's plugin configuration: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-release-plugin</artifactId> > <version>2.0-beta-8</version> > </plugin> > > Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-8 > > > ** Bug > * [MRELEASE-87] - Poms are written with wrong encodings > * [MRELEASE-188] - release:perform is not updating some modules to > the next version identifier correctly. > * [MRELEASE-201] - Deployed POM is not valid XML > * [MRELEASE-221] - XML header missing in modified POM after > release:prepare > * [MRELEASE-223] - Generated pom.xml has invalid chars (does not > correctly handle xml entities) > * [MRELEASE-254] - tests failed on windows > * [MRELEASE-255] - during a release several elements are removed > from the pom.xml (which should be left there) > * [MRELEASE-267] - Whitespaces in artifactId or groupId prevent > version update > * [MRELEASE-268] - Release is broken with Subversion 1.3.x and > earlier > * [MRELEASE-302] - Test don't pass on windows due to encoding > issues > * [MRELEASE-305] - release:prepare forgets a slash when changing > the <scm> urls > * [MRELEASE-337] - generated command line must remove newLine > characters > * [MRELEASE-351] - xml declaration removed on release > * [MRELEASE-355] - Deploying from Leopard, with Svn 1.4.4 has > error on automated Svn commit > * [MRELEASE-360] - NullPointerException in release > * [MRELEASE-364] - InvokerMavenExecutor fails with NPE if > additional arguments are not set > * [MRELEASE-365] - ForkedMavenExecutor fails with NoSuchMethodError > * [MRELEASE-366] - Using InvokerMavenExecutor fails in combination > with space in paths > > ** Improvement > * [MRELEASE-173] - Allow command line specification of versions > * [MRELEASE-321] - Add support for -DdevelopmentVersion and > -DreleaseVersion to facilitate command line configuration > * [MRELEASE-341] - support release process that use a staging > repository > * [MRELEASE-345] - Keep comments in rewritten elements > * [MRELEASE-359] - Release plugin depends on mvn being in the path > of the shell that started the current build > * [MRELEASE-382] - Specifying workingDirectory as system property > on CL is not picked up by release:perform > > ** New Feature > * [MRELEASE-369] - upgrade scm version to last 1.1 (and add by > default new providers accurev and git) > > ** Task > * [MRELEASE-316] - remove copy of plexus-utils' XML encoding > support sources > > > ** Wish > * [MRELEASE-313] - add an option to set the profile(s) used to > perform the release > > Have fun ! > > -The Maven team > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe(a)maven.apache.org > For additional commands, e-mail: dev-help(a)maven.apache.org >

16 years, 1 month

[xwiki-devs] Problem connecting Xwiki with OpenLDAP

by Milan Mehta

I have configured Xwiki (release 1.6-milestone-2.12601) to authenticate against my OpenLDAP (v2.3.35). I am continuously getting a "Wrong user name" message on my UI. On investigating my ldap logs, I found that Xwiki first authenticates successfully to OpenLDAP with the users id & password. However it then tries to do a lookup of the user (I assume for the details of the user), and at that time, it does not seem to be passing the base DN in the request. In such scenarios OpenLDAP returns a "No such object" error. I tried to do a test using ldapsearch without passing the base, and I got the same error. Also, the error did not occur when I passed the base parameter to ldapsearch. I am trying to trace through this problem in the source, but meanwhile, would like some help in figuring out whether my configuration is wrong, or if someone has encountered a similar problem before. Regards, Milan... ---------------------------------------------------------------------------- ------------------------------------------------------- Xwiki.cfg - LDAP Section ---------------------------------------------------------------------------- -------------------------------------------------------- #-# new LDAP authentication service xwiki.authentication.authclass=com.xpn.xwiki.user.impl.LDAP.XWikiLDAPAuthSer viceImpl #-# Turn LDAP authentication on - otherwise only XWiki authentication #-# 0: disable #-# 1: enable xwiki.authentication.ldap=1 #-# LDAP Server (Active Directory, eDirectory, OpenLDAP, etc.) xwiki.authentication.ldap.server=ldap-slave xwiki.authentication.ldap.port=389 #-# base DN for searches xwiki.authentication.ldap.base_DN=dc=<mycompany>,dc=<mycountry> #-# LDAP login, empty = anonymous access, otherwise specify full dn #-# {0} is replaced with the username, {1} with the password #xwiki.authentication.ldap.bind_DN=cn=cname#,department=USER,department=INFO RMATIK,department=1230,o=MP #xwiki.authentication.ldap.bind_DN=cn=Manager,department=USER,department=INF ORMATIK,department=1230 xwiki.authentication.ldap.bind_DN=cn=Manager,dc=<mycompany>,dc=<mycountry> xwiki.authentication.ldap.bind_pass=<dummy> #-# Force to check password after LDAP connection #-# 0: disable #-# 1: enable xwiki.authentication.ldap.validate_password=0 #-# only members of the following group will be verified in the LDAP #-# otherwise only users that are found after searching starting from the base_DN # xwiki.authentication.ldap.user_group=cn=developers,ou=groups,o=MegaNova,c=US #xwiki.authentication.ldap.user_group=ou=People,dc=<mycompany>,dc=<mycountry > #-# [SINCE 1.5RC1, XWikiLDAPAuthServiceImpl] #-# only users not member of the following group can autheticate # xwiki.authentication.ldap.exclude_group=cn=admin,ou=groups,o=MegaNova,c=US #-# Specifies the LDAP attribute containing the identifier to be used as the XWiki name (default=cn) xwiki.authentication.ldap.UID_attr=uid #-# [SINCE 1.5M1, XWikiLDAPAuthServiceImpl] #-# Specifies the LDAP attribute containing the password to be used "when xwiki.authentication.ldap.validate_password" is set to 1 xwiki.authentication.ldap.password_field=userPassword #-# [SINCE 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential LDAP groups classes. Separated by commas. xwiki.authentication.ldap.group_classes=posixGroup #-# [SINCE 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential names of the LDAP groups fields containings the members. Separated by commas. xwiki.authentication.ldap.group_memberfields=memberUid #-# retrieve the following fields from LDAP and store them in the XWiki user object (xwiki-attribute=ldap-attribute) #-# ldap_dn=dn -- dn is set by class, caches dn in XWiki.user object for faster access #xwiki.authentication.ldap.fields_mapping=last_name=sn,first_name=givenName, fullname=cn,email=mail,ldap_dn=dn #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# on every login update the mapped attributes from LDAP to XWiki otherwise this happens only once when the XWiki account is created. xwiki.authentication.ldap.update_user=1 #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# mapps XWiki groups to LDAP groups, separator is "|" # xwiki.authentication.ldap.group_mapping=XWiki.XWikiAdminGroup=cn=AdminRole,o u=groups,o=MegaNova,c=US|\ # XWiki.Organisation=cn=testers,ou=groups,o=MegaNova,c=US #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# time in s after which the list of members in a group is refreshed from LDAP (default=3600*6) # xwiki.authentication.ldap.groupcache_expiration=21800 #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# - create : synchronize group membership only when the user is first created #-# - always: synchronize on every login xwiki.authentication.ldap.mode_group_sync=always #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# if ldap authentication fails for any reason, try XWiki DB authentication with the same credentials xwiki.authentication.ldap.trylocal=1 #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# SSL connection to LDAP server #-# 0: normal #-# 1: SSL xwiki.authentication.ldap.ssl=0 #-# [SINCE 1.3M2, XWikiLDAPAuthServiceImpl] #-# The keystore file to use in SSL connection # xwiki.authentication.ldap.ssl.keystore= #-# [SINCE 1.5M1, XWikiLDAPAuthServiceImpl] #-# The java secure provider used in SSL connection # xwiki.authentication.ldap.ssl.secure_provider=com.sun.net.ssl.internal.ssl.P rovider ---------------------------------------------------------------------------- ------------------------------------------------------- OpenLDAP Log output (invoked from xwiki) ---------------------------------------------------------------------------- -------------------------------------------------------- => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=<mycompany>,dc=<mycountry>)=0 <<< dnPrettyNormal: <cn=Manager,dc=<mycompany>,dc=<mycountry>>, <cn=manager,dc=<mycompany>,dc=<mycountry>> do_bind: version=3 dn="cn=Manager,dc=<mycompany>,dc=<mycountry>" method=128 ==> bdb_bind: dn: cn=Manager,dc=<mycompany>,dc=<mycountry> do_bind: v3 bind: "cn=Manager,dc=<mycompany>,dc=<mycountry>" to "cn=Manager,dc=<mycompany>,dc=<mycountry>" send_ldap_result: conn=5 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=13 tag=97 err=0 ber_flush: 14 bytes to sd 19 connection_get(19) connection_get(19): got connid=5 connection_read(19): checking for input on id=5 ber_get_next ber_get_next: tag 0x30 len 14 contents: ber_get_next do_extended ber_scanf fmt ({m) ber: do_extended: unsupported operation "0.0.0.0" send_ldap_result: conn=5 op=1 p=3 send_ldap_result: err=2 matched="" text="unsupported extended operation" send_ldap_response: msgid=14 tag=120 err=2 ber_flush: 44 bytes to sd 19 connection_get(19) connection_get(19): got connid=5 connection_read(19): checking for input on id=5 ber_get_next ber_get_next: tag 0x30 len 40 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 2 0 1000 0 0 begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: end get_filter 0 filter: (uid=mmehta) ber_scanf fmt ({M}}) ber: attrs: send_ldap_result: conn=5 op=2 p=3 send_ldap_result: err=10 matched="" text="" send_ldap_response: msgid=15 tag=101 err=32 ---------------------------------------------------------------------------- ------------------------------------------------------- OpenLDAP Log output (invoked by ldapsearch with base parameter specified) ---------------------------------------------------------------------------- -------------------------------------------------------- <<< dnPrettyNormal: <cn=Manager,dc=<mycompany>,dc=<mycountry>>, <cn=manager,dc=<mycompany>,dc=<mycountry>> do_bind: version=3 dn="cn=Manager,dc=<mycompany>,dc=<mycountry>" method=128 ==> bdb_bind: dn: cn=Manager,dc=<mycompany>,dc=<mycountry> do_bind: v3 bind: "cn=Manager,dc=<mycompany>,dc=<mycountry>" to "cn=Manager,dc=<mycompany>,dc=<mycountry>" send_ldap_result: conn=10 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 21 connection_get(21) connection_get(21): got connid=10 connection_read(21): checking for input on id=10 ber_get_next ber_get_next: tag 0x30 len 58 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=<mycompany>,dc=<mycountry>> => ldap_bv2dn(dc=<mycompany>,dc=<mycountry>,0) <= ldap_bv2dn(dc=<mycompany>,dc=<mycountry>)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=<mycompany>,dc=<mycountry>)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=<mycompany>,dc=<mycountry>)=0 <<< dnPrettyNormal: <dc=<mycompany>,dc=<mycountry>>, <dc=<mycompany>,dc=<mycountry>> SRCH "dc=<mycompany>,dc=<mycountry>" 2 0 0 0 0 ************** This is the place where the base is available ********************** begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: end get_filter 0 filter: (uid=mmehta) ber_scanf fmt ({M}}) ber: attrs: => bdb_search bdb_dn2entry("dc=<mycompany>,dc=<mycountry>") entry_decode: "dc=<mycompany>,dc=<mycountry>" <= entry_decode(dc=<mycompany>,dc=<mycountry>) search_candidates: base="dc=<mycompany>,dc=<mycountry>" (0x00000001) scope=2 => bdb_dn2idl("dc=<mycompany>,dc=<mycountry>") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30990) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [b5212845] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=37, last=37 <= bdb_filter_candidates: id=1 first=37 last=37 <= bdb_list_candidates: id=1 first=37 last=37 <= bdb_filter_candidates: id=1 first=37 last=37 <= bdb_list_candidates: id=1 first=37 last=37 <= bdb_filter_candidates: id=1 first=37 last=37 bdb_search_candidates: id=1 first=37 last=37 => test_filter EQUALITY <= test_filter 6 => send_search_entry: conn 10 dn="uid=mmehta,ou=People,dc=<mycompany>,dc=<mycountry>" ber_flush: 769 bytes to sd 21 <= send_search_entry: conn 10 exit. send_ldap_result: conn=10 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=101 err=0

16 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2008