http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23924 Hi, can you provide a diff instead of a colored version of your server.xml ? Colors were removed while the mail transited from your mailer to the apache mailing list ... Thanks ! Emmanuel Lecharny 2008-12-04T16:12:57 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23923 Hi I am using Apache DS version 1.5.1. Now I would like to upgrade to version 1.5.4 but I can not find a server.xml file example. Below you can find the old server.xml(1.5.1). The red coloured sections are my modifications. *1 Authenticator *1 Interceptor *1 Partition How can I configure that in the new server.xml 1.5.4. Can you please give me a hint? Greetings from Switzerland (Bad weather and cold) Dominic Stampfli <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="environment" class="org.springframework.beans.factory.config.PropertiesFactoryBean"> <property name="properties"> <props> <!-- JNDI security properties used to get initial contexts. --> <prop key="java.naming.security.authentication">simple</prop> <prop key="java.naming.security.principal">uid=admin,ou=system</prop> <prop ke Dominic Stampfli 2008-12-04T13:55:56 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23922 You have to store some session information in any case. So assuming we implement the second option, we just store the number of entries we already transmitted. Yes, this is exactly what I have in mind :) There are no such guarantee, either with option 1 or option 2, as stated by RFC 2696 : "A client may safely assume that all entries that satisfy a given search query are returned once and only once during the set of paged Search requests/responses necessary to enumerate the entire result set, unless the result set for that query has changed since the searchRequest starting the request/response sequence was processed." The problem is certainly not well behaved client. but there are many case when even a well behaved client might be troublesome. Typically, Apache Studio (a well behaved client, that's for sure :), when it comes to load thousands of entries, uses this control to get the entries little by little. It present the entries in a list of N sub-entries, and when you open a block, then a new Emmanuel Lecharny 2008-12-04T01:13:08 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23921 Hi, I don't know the core code like you, but given my current understanding (pardon me if my understanding is woefully inadequate :-) I'm not sure your option 2 is really viable. After the first page is returned, how are you going to initialize the cursor for the next page? Wouldn't you have to remember where you were up to (using some sort of unique per-result key) and rerun the search, skipping results up to this key value (if so then it's unworkable no?). BTW Is there guaranteed to be a stable sorting order for search results internally, and is the sort control supported by AD so that it may be posed externally etc. At any rate I don't think keeping a cursor open is that big a deal, although there probably needs to be a server-side timeout so that if the cursor is not accessed for a long time (say an hour for argument) it is automatically closed. Well behaved clients should explicitly close their NamingEnumerations which I would hope would allow the cursor to be discarded immediately. Cheers On Thu, D Norval Hope 2008-12-03T23:46:31 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23920 Hi guys, I'm trying to implement this control for 1.5.5, and I'm a bit stuck in the way we should handle it in the core server. Right now, the control is decoded (the ASN.1 decoder has been written and tested, it works fine). The SearchHandler has been modified so that we can implement the control in only one case : the doSimpleSearch() method. The problem I have is the following : we have to remember the pointer to the last entry we have sent back to the client How should we do ? My first approach was pretty naive : we are using a cursor, so it's easy, we simply store the cursor into the session, and the next request will just have to get back this cursor from the session, and get the N next elements from this cursor. This has the advantage of being simple, but there are some very important cons : - it's memory consuming, as we may keep those cursor in the session for a very long time - we will have to close all the cursors when the session is closed (for whatever reason) - if some data has b Emmanuel Lecharny 2008-12-03T23:25:21 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23919 [ https://issues.apache.org/jira/browse/DIRSERVER-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-583. --------------------------------- Norval Hope (JIRA 2008-12-03T23:19:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23918 [ https://issues.apache.org/jira/browse/DIRSERVER-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-618. --------------------------------- Norval Hope (JIRA 2008-12-03T23:17:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23917 [ https://issues.apache.org/jira/browse/DIRSERVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-585. --------------------------------- Norval Hope (JIRA 2008-12-03T23:17:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23916 [ https://issues.apache.org/jira/browse/DIRSERVER-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-604. --------------------------------- Norval Hope (JIRA 2008-12-03T23:17:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23915 [ https://issues.apache.org/jira/browse/DIRSERVER-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-771. --------------------------------- Norval Hope (JIRA 2008-12-03T23:15:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23914 [ https://issues.apache.org/jira/browse/DIRSERVER-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-748. --------------------------------- Norval Hope (JIRA 2008-12-03T23:15:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23913 [ https://issues.apache.org/jira/browse/DIRSERVER-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-626. --------------------------------- Norval Hope (JIRA 2008-12-03T23:15:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23912 [ https://issues.apache.org/jira/browse/DIRSERVER-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-1161. ---------------------------------- Norval Hope (JIRA 2008-12-03T23:13:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23911 [ https://issues.apache.org/jira/browse/DIRSERVER-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-796. --------------------------------- Norval Hope (JIRA 2008-12-03T23:13:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23910 [ https://issues.apache.org/jira/browse/DIRSERVER-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-1274. ---------------------------------- Norval Hope (JIRA 2008-12-03T23:11:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23909 [ https://issues.apache.org/jira/browse/DIRSERVER-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-1257. ---------------------------------- Norval Hope (JIRA 2008-12-03T23:11:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23908 [ https://issues.apache.org/jira/browse/DIRSERVER-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norval Hope closed DIRSERVER-1292. ---------------------------------- Norval Hope (JIRA 2008-12-03T23:11:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23907 Hi Alex, if we exclude the 72 hours for a vote on MINA 2.0.0-M4, we currently have 7 issues for this version, 3 of them being bugs. One affects the statemachine, and as we received no answer from the guy who wrote this part, I think we can differ its resolution (https://issues.apache.org/jira/browse/DIRMINA-604), another one is about the TraficClass usage (https://issues.apache.org/jira/browse/DIRMINA-539) : totally useless IMHO, and the last one is a bit more annoying, but we may have a way to workaround it (https://issues.apache.org/jira/browse/DIRMINA-632). If we postpone the 4 other issues, which are not really important, then we can have a version by monday. Emmanuel Lecharny 2008-12-03T22:33:17 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23906 Hi guys, What's the timeframe on this merge? Thanks, Alex On Sun, Nov 30, 2008 at 3:31 PM, Stefan Zoerner <stefan-EQq9qWhC7IA< at >public.gmane.org> wrote: Alex Karasulu 2008-12-03T22:22:47 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23905 Simple property files fits well in many cases. This what we had before ads 1.0, and we switch to Spring (and alter to Spring+xbeans) for bad reasons . (and frankly, xbeans is not really the problem. Spring is.) This is true _if_ you are working on a plugin oriented system. ADS is first a LDAP server, second it's embeddable. This is were I don't see the fit with Spring. Well, it's a bit like Maven : you like it or not, but at least, it does the job. The question when it comes to Spring-xbean is much more : is it usefull for our need ? (I don't want to enter into a long discussion about the xbean weaknesses, as it's totally irrelevant : I'm totally confident that with a few more months of work, it's a good companion for those who are using Spring a lot) In other words : design your components with configuration in mind, regardless what they do. Or at least, don't forget that the configuration organization will be a direct consequences of your design choices. *I* just don't like the idea. To me, it' Emmanuel Lecharny 2008-12-03T18:24:52 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/23904 On Dec 3, 2008, at 5:53 AM, Emmanuel Lecharny wrote: Several people on this list sure like to complain about xbean-spring but I still don't really understand what they would prefer. IMO the idea behind component oriented wiring frameworks like xbean-spring is that all the exposed configuration knobs and wires are things that reasonable users will want to turn or rewire. xbean-spring gives you a machine-syntax-checkable way to turn all the knobs and plug in all the wires. (spring alone is not machine-syntax-checkable). If you don't like it there are several possibilities I can think of.... - too many or too few knobs and wires. This means the components aren't the right size, and is not really a problem with xbean-spring - pointy brackets are too sharp and makes my eyes bleed. xml really sucks, but its widely understood, syntax-checkable, and doesn't require compilation. Wiring in java is very clear but requires compilation. Groovy builders are really nice but AFAIK don't rea David Jencks 2008-12-03T17:41:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.incubator.directory.devel