Ok,
thanks a lot for the informations. This will help me a lot, I will be able
to create a test case to cover this problem, and be sure it will be added
as a non regression tests in the future.
May I ask you to fill a JIRA so that we don't forget to fix this error (if
we have to take some time to fix it)? This is important for us, because JIRA
does not vansihes when mails get buried under thousands of other mails after
a few days ...
Emmanuel
On 5/2/07, B G <[EMAIL PROTECTED]> wrote:
I am using the MutableServerStartupConfiguration so the code I am
using to set the ldif directory is something like
MutableServerStartupConfiguration cfg = new
MutableServerStartupConfiguration();
cfg.setLdifDirectory(new File("../my/relative/path/ldif"));
This File path is getting resolved to something like
C:\dev\my\relative\path\ldif.
Take a look at ServerContextFactory.addFileEntry method. This calls
getCanonical on the file path and / gets turned to \. As far as I can
tell there is no work
around for this issue on a windows platform where the absolute path
cannot be controlled in a manner to ensure that no possible hex values
follow a file seperator.
Given this, it is probably important to get this addressed.
This is also the case if you use server.xml to enter this path.
If you see that I am not understanding or doing something wrong please
let me know.
Thanks for the response...
>
> Hi,
>
> Have you tried to escape the escape character ?
>
> Something like : c:\\dev\\...
>
> Can you paste the piece of code you ar using to inject the ldif file, so
> that we have a clear idea about what happens ?
>
>
> Thanks !
On 5/2/07, B G <[EMAIL PROTECTED]> wrote:
>
> Hi...
>
> I am trying to use a ldif file to import schema into an embedded 1.5.0ds.
>
> The issue I found has to do with what is configured for the path to the
> ldif
> directory on a windows machine. If this path contains any characters
that
> are possible hex values after the file seperator ( '\' on windows)
things
> are totally screwed.
> This is because the DefaultStringNormalizer interprets the presence of
any
> '\' characters as an escape for a hex sequence and tries to convert the
> following 2 bytes as hex. This is not a problem if the path has no
> possible
> hex values after the file seperator, but big problem otherwise.
>
> For example: C:\dev\ldif\myldif.ldif willl never work.
>
> Stack trace looks like this:
> javax.naming.NamingException: Invalid value : C:?v\ldif\myldif.ldif
> at
>
>
org.apache.directory.shared.ldap.schema.DeepTrimToLowerNormalizer.normalize
> (
> DeepTrimToLowerNormalizer.java:65)
> at
org.apache.directory.shared.ldap.schema.CachingNormalizer.normalize
> (
> CachingNormalizer.java:95)
> at org.apache.directory.shared.ldap.name.LdapDN.rdnOidToName(
> LdapDN.java
> :1402)
> at org.apache.directory.shared.ldap.name.LdapDN.normalize(
LdapDN.java
> :1459)
> at
> org.apache.directory.server.core.normalization.NormalizationService.add(
> NormalizationService.java:116)
> at org.apache.directory.server.core.interceptor.InterceptorChain.add
(
> InterceptorChain.java:708)
> at
org.apache.directory.server.core.partition.PartitionNexusProxy.add(
> PartitionNexusProxy.java:341)
> at
org.apache.directory.server.core.partition.PartitionNexusProxy.add(
> PartitionNexusProxy.java:329)
> at
> org.apache.directory.server.core.jndi.ServerDirContext.createSubcontext(
> ServerDirContext.java:428)
> at
> org.apache.directory.server.core.jndi.ServerDirContext.createSubcontext(
> ServerDirContext.java:374)
> at
org.apache.directory.server.jndi.ServerContextFactory.addFileEntry(
> ServerContextFactory.java:258)
> at org.apache.directory.server.jndi.ServerContextFactory.loadLdifs(
> ServerContextFactory.java:383)
> at
org.apache.directory.server.jndi.ServerContextFactory.afterStartup(
> ServerContextFactory.java:209)
> at org.apache.directory.server.core.DefaultDirectoryService.startup(
> DefaultDirectoryService.java:268)
> at
>
>
org.apache.directory.server.core.jndi.AbstractContextFactory.getInitialContext
> (AbstractContextFactory.java:123)
>
>
> Does anyone know of a work around for this?
>
> Thanks...
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
