Re: LDAP access et modification problem

Hi,

Stéphane Croisier a écrit :

>
> But can't you test your LDAP connexion on a fresh Jahia 4.0.6 
> installation, make some basic tests in your environnement with the 
> default templates and see if the problem was solved meanwhile. Then 
> you may decide of upgrading or not (or backporting the LDAP 
> modifications)...

OK, we will maybe do so.

>
> Else what do you want us to make for you? Install your whole 
> environement we do not have to make some tests on a LDAP we do not 
> have? Something looks like quite strange to me in your email :-(

Oh sorry, my messages where misunderstood.

As I do not understand very well the deep consequences of the changes 
briefly described in the Changelog, I just wanted to know if some of the 
LDAP modifications concerns my problem before going into a lot of tests, 
that's all. Isn't here the right place for such a question ?

Regards,

Cédric

>
> Cheers,
> Stéphane
>
> At 12:56 08/07/2005, you wrote:
>
>> Hi,
>>
>> The problem is that we have developped a lot of specific stuff. A 
>> migration would mean a lot of testing and code rewrite, as we made 
>> for the 4.0.4 -> 4.0.5 migration.
>>
>> If we are not sure that the migration will solve our problems, we 
>> won't make it.
>>
>> Regards,
>>
>> Cédric
>>
>> Serge Huber a écrit :
>>
>>>
>>> Hi Cédric,
>>>
>>> May I suggest you test with the latest stable version of Jahia, to 
>>> see if you still have the problem, because there were more LDAP 
>>> improvements after 4.0.5.
>>>
>>> Regards,
>>>  Serge Huber.
>>>
>>> Cédric REYMANN wrote:
>>>
>>>> Hi,
>>>>
>>>> Serge Huber a écrit :
>>>>
>>>>>
>>>>> Hi Cédric,
>>>>>
>>>>> The problem is that Jahia has no way of knowing that you added 
>>>>> user into the LDAP.
>>>>
>>>> OK but as flushing de Jahia caches isn't enough, when we flush all 
>>>> caches, the next connections are very awfully slow, the site is 
>>>> then unusable for several minutes.
>>>> In Jahia 4.0.4, before the migration to 4.0.5, flushing the LDAP 
>>>> caches was OK. What change has caused this in the new version ?
>>>>
>>>>> What is stranger is that it crashes on the following line :
>>>>>
>>>>> 283:             engineMap.put (ENGINE_URL_PARAM, 
>>>>> jParams.composePageUrl (loginPage.getID ()));
>>>>>
>>>>> This is probably because loginPage is null, but it shouldn't be. 
>>>>> Do you have a strange configuration with home pages ?
>>>>
>>>>
>>>>
>>>>
>>>> In fact, all the rights were lost, maybe during the migration : the 
>>>> users lost access to their home page. But then, why was this OK 
>>>> after a cache flush ?
>>>>
>>>>> Regards,
>>>>>  Serge Huber.
>>>>>
>>>>> Cédric REYMANN wrote:
>>>>>
>>>>>> Thanks for your reply.
>>>>>>
>>>>>> Serge Huber a écrit :
>>>>>>
>>>>>>>
>>>>>>> Hi Cédric,
>>>>>>>
>>>>>>> Which version of Jahia are you using ? In 4.0.5 we added a lot 
>>>>>>> of caches in the LDAP implementation, so you shouldn't be seeing 
>>>>>>> this problem anymore.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We use the version 4.0.5 (after migrating from 4.0.4).
>>>>>>
>>>>>> For instance, after adding a user in the LDAP, the login of this 
>>>>>> user crashes (see the error below). But after flushing ALL the 
>>>>>> caches, it seems to work.
>>>>>>
>>>>>> Your Jahia Server has generated an error. Please review the 
>>>>>> details below for additional information:
>>>>>>
>>>>>> Error : null
>>>>>>
>>>>>> URL : http://abw0.astron.biz/cyprion/Jahia/engineName/login/pid/1
>>>>>> Method : POST
>>>>>>
>>>>>> Remote host : null     Remote Address : 192.168.102.100
>>>>>>
>>>>>> Request headers :   x-forwarded-host:extranet.astron.biz
>>>>>>   x-forwarded-for:192.168.204.143
>>>>>>   accept-encoding:gzip, deflate
>>>>>>
>>>>>> referer:https://extranet.astron.biz/cyprion/Jahia/engineName/login/pid/1?matrix=1120124401163&matrix=2111 
>>>>>>
>>>>>>   connection:close
>>>>>>   cookie:JSESSIONID=83B1C521FE80CA034B74F6545FBFF94A
>>>>>>   content-type:application/x-www-form-urlencoded
>>>>>>   content-length:45
>>>>>>   x-forwarded-server:extranet.astron.biz
>>>>>>   cache-control:no-cache
>>>>>>   host:abw0.astron.biz
>>>>>>   accept-language:en-us
>>>>>>   user-agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; 
>>>>>> .NET CLR 1.1.4322)
>>>>>>   accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
>>>>>> application/vnd.ms-excel, application/vnd.ms-powerpoint, 
>>>>>> application/msword, application/x-shockwave-flash, */*
>>>>>>
>>>>>> Stack trace : Cause level : 0 (level 0 is the most precise 
>>>>>> exception) java.lang.NullPointerException
>>>>>>     at 
>>>>>> org.jahia.engines.login.Login_Engine.processScreen(Login_Engine.java:283) 
>>>>>>
>>>>>>     at 
>>>>>> org.jahia.engines.login.Login_Engine.handleActions(Login_Engine.java:126) 
>>>>>>
>>>>>>     at 
>>>>>> org.jahia.operations.OperationManager.handleOperations(OperationManager.java:279) 
>>>>>>
>>>>>>     at org.jahia.bin.JahiaAction.execute(JahiaAction.java:50)
>>>>>>     at 
>>>>>> org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) 
>>>>>>
>>>>>>     at org.jahia.bin.Jahia.process(Jahia.java:1522)
>>>>>>     at org.jahia.bin.Jahia.service(Jahia.java:846)
>>>>>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>>>>>>     at 
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:466) 
>>>>>>
>>>>>>     at 
>>>>>> org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:585)
>>>>>>     at java.lang.Thread.run(Thread.java:534)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cédric REYMANN wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have two problems with the LDAP capabilities of Jahia.
>>>>>>>>
>>>>>>>> The first one is that Jahia gather all the information from the 
>>>>>>>> LDAP server for each visited page. As if the cache weren't 
>>>>>>>> used. By the way, these LDAP requests are very slow if we 
>>>>>>>> compare them to another LDAP client for which it works fine. 
>>>>>>>> What can we do ?
>>>>>>>>
>>>>>>>> The second point is that when we make a modification to LDAP 
>>>>>>>> users or group, this modification isn't seen by Jahia. This is 
>>>>>>>> strange regarding the first problem. And flushing the LDAP 
>>>>>>>> caches isn't sufficient : after the flush of all caches, it 
>>>>>>>> works fine. The question is, how does the LDAP cache work and 
>>>>>>>> is it possible to make the cache expire sometime ? So that the 
>>>>>>>> guy who modify the LDAP doesn't need to refer to the Jahia 
>>>>>>>> administrator.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You can expire the cache manually through the administration 
>>>>>>> ("Server and cache status"). You could also programmatically 
>>>>>>> expire the cache by flusing the corresponding cache. For the 
>>>>>>> moment there is no time-based expiration possible but will be 
>>>>>>> possible in future versions of Jahia (as we will be making the 
>>>>>>> cache implementation pluggeable).
>>>>>>>
>>>>>>> Regards,
>>>>>>>  Serge Huber.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
> - -- --- -----=[ scroisier at jahia dot com ]=---- --- -- -
> CEO - Jahia Ltd, 45 rue de la gare, 1260 Nyon (Switzerland)
> Jahia : The Java Unified Web Platform
> www.jahia.org - The community and product web site
> www.jahia.com - Our commercial services company
> www.collaborativesource.org - The Collaborative Source Initiative
>
>
>


-- 
Cédric Reymann
Consultant Informatique
Actimage