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
