Thank you, this is really helpful information, exactly what I was looking for.
The code to my limit "patch" will be posted in that thread. Best regards, Pontus > -----Original Message----- > From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 18, 2005 1:18 PM > To: 'Slide Users Mailing List' > Subject: RE: Another performance question > > > > Hello, > > We have been using openldap as an authentication server > without any issues > so far (windows distribution). As far as I learned it's a > relatively active > open-source unix project, and you probably should already > know about those > unix-geeks: they are perfectionists: P. > I haven't made any performance tests on the openldap server, > but I feel > confident it should handle quite well, at least comparable > with commercial > implementations. Anyway, it's better than parsing XML > documents (like it is > done by slide) and if the openldap performance isn't good > enough, you can > still migrate to a commercial implementation (good thing about using > standards!). Last remark... OpenLdap is GPL. > > Now, the instructions of slide configuration to take advantage of an > LDAP/Active directory server are already on the slide > documentation, witch > also makes some references to the tomcat documentation pages. > It's all about > org.apache.catalina.realm.JNDIRealm realm on the web container side > (server.xml) and > org.apache.slide.store.txjndi.JNDIPrincipalStore on the > slide webapp (domain.xml). > > Although it has been quite discussed in this mailing list, > I'm attaching my > domain.xml and server.xml as examples. Also, when adding user > info to the > LDAP server, I found quite useful the JExplorer tool. > Finally, this are only > tips from where you can start learning. > > Best Regards, > Miguel Figueiredo > > PS: Is it possible to post your code patches for the 'limit' > feature? Many > Thanks! > > ____ > > > -----Original Message----- > From: Pontus Strand [mailto:[EMAIL PROTECTED] > Sent: terça-feira, 18 de Janeiro de 2005 11:34 > To: 'Slide Users Mailing List' > Subject: RE: Another performance question > > Hello Miguel, > > Thank you for you response. The problem with LDAP is that > none of us in the > project has worked with LDAP. We will look into it, of course, so any > pointers you may have would be useful to us. For instance, is > OpenLDAP any > good or should we look at a commercial LDAP-server? How > should we setup > Slide to use LDAP? > > Regards, > Pontus > > > -----Original Message----- > > From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 18, 2005 11:04 AM > > To: 'Slide Users Mailing List' > > Subject: RE: Another performance question > > > > > > > > Hello Pontus, > > > > First of all, many thanks for your performance enquiries > to the slide > > mailing list: I've been consuming them avidly. > > For user aggregation on groups, and group2user or user2group > > traversal for > > authentication/authorization purposes, I would suggest to > publish that > > information in a LDAP or Active Directory servers. These > > kinds of servers > > are optimized for just doing that work and the biggest > > performance cost > > associated with requesting a service to these authentication > > servers, would > > be the establishment of a tcp connection. Hope this helps. > > > > Best regards, > > Miguel Figueiredo > > > > -----Original Message----- > > From: Pontus Strand [mailto:[EMAIL PROTECTED] > > Sent: terça-feira, 18 de Janeiro de 2005 9:21 > > To: Slide Users Mailing List (E-mail) > > Subject: Another performance question > > > > Hello again, > > > > This time I want to ask about users. Are there any known > > problems with large > > numbers of users and/or groups? And are there any nice > > parameters that we > > should know about that improves user management? We haven't > > tested this yet, > > mostly because the somewhat complex user management in Slide. > > My fear is > > that adding large numbers of users to a group could lead to > > slow user access > > verifications, is that a correct assumption? > > > > Regards, > > Pontus > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
