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)...
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 :-(
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
