You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Jeff Lansing <jl...@spawar.navy.mil> on 2005/12/13 00:16:42 UTC
[ApacheDS]
Hi,
We are using ApacheDS as an embedded LDAP in our web application as a way to
manage and persist configuration information. We have been using the three
0.9.3 jar files (core, main, and shared).
Recently we tried deploying on a more powerful 4-processor server, and we
started running into serious problems that we hadn't seen before (see below
for stack trace). We found this:
http://issues.apache.org/jira/browse/DIRLDAP-70
which seemed to be very close to the problem we're seeing, so we thought we
could perhaps check out the source and make an intermediate build.
Unfortunately, we couldn't check out the source from svn. The Tortoise
client says this:
...
Added:
C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\
ldap\common\name\DnParserTest.java
Error: In directory
'C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache
\ldap\common\name'
Error: Can't copy
Error:
'C:\directory\shared\ldap\branches\DN-refactorin...\DnParserTest.java.svn-ba
se'
Error: to
Error:
'C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apach.
..\
Error: The system cannot find the file specified.
Surely there must be something that we don't understand. Could someone
provide a bit of guidance?
Thanks,
Jeff
PS: The real error is this:
2005-12-07 14:54:16,722 ERROR ldap.MutableLinkRef
[http-80-Processor24,dereference:82]
cn=home,cn=SubscriptionManagerService,cn=services,cn=env,cn=comp,ou=j2ee->ja
va:comp/env/subscriptionHome (ou=system)
org.apache.ldap.server.interceptor.InterceptorException: Unexpected
exception. [Root exception is java.lang.IllegalArgumentException: first
argument was not a distinguished name]
at
org.apache.ldap.server.interceptor.InterceptorChain.throwInterceptorExceptio
n(InterceptorChain.java:1368)
at
org.apache.ldap.server.interceptor.InterceptorChain.access$700(InterceptorCh
ain.java:49)
at
org.apache.ldap.server.interceptor.InterceptorChain$2.hasEntry(InterceptorCh
ain.java:1240)
at
org.apache.ldap.server.exception.ExceptionService.assertHasEntry(ExceptionSe
rvice.java:373)
at
org.apache.ldap.server.exception.ExceptionService.lookup(ExceptionService.ja
va:159)
at
org.apache.ldap.server.interceptor.InterceptorChain.lookup(InterceptorChain.
java:767)
at
org.apache.ldap.server.partition.DirectoryPartitionNexusProxy.lookup(Directo
ryPartitionNexusProxy.java:405)
at
org.apache.ldap.server.authz.AuthorizationService.lookup(AuthorizationServic
e.java:646)
at
org.apache.ldap.server.interceptor.InterceptorChain$2.lookup(InterceptorChai
n.java:1192)
at
org.apache.ldap.server.authn.AuthenticationService.lookup(AuthenticationServ
ice.java:252)
at
org.apache.ldap.server.interceptor.InterceptorChain$2.lookup(InterceptorChai
n.java:1192)
at
org.apache.ldap.server.normalization.NormalizationService.lookup(Normalizati
onService.java:203)
at
org.apache.ldap.server.interceptor.InterceptorChain.lookup(InterceptorChain.
java:767)
at
org.apache.ldap.server.partition.DirectoryPartitionNexusProxy.lookup(Directo
ryPartitionNexusProxy.java:405)
at
org.apache.ldap.server.partition.DirectoryPartitionNexusProxy.lookup(Directo
ryPartitionNexusProxy.java:394)
at
org.apache.ldap.server.jndi.ServerContext.lookup(ServerContext.java:581)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
xtcf.jeod.jndi.ldap.J2EEInitialContext.lookup(J2EEInitialContext.java:95)
at
xtcf.jeod.jndi.ldap.J2EEInitialContext.lookup(J2EEInitialContext.java:75)
at
xtcf.jeod.jndi.ldap.MutableLinkRef.dereference(MutableLinkRef.java:76)
at
xtcf.jeod.jndi.ldap.J2EEInitialContext.lookup(J2EEInitialContext.java:105)
at
xtcf.jeod.jndi.ldap.J2EEInitialContext.lookup(J2EEInitialContext.java:75)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at org.apache.naming.SelectorContext.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at
org.globus.wsrf.impl.ResourceContextImpl.getResourceHome(ResourceContextImpl
.java:119)
at
org.globus.wsrf.impl.lifetime.SetTerminationTimeProvider.setTerminationTime(
SetTerminationTimeProvider.java:79)
...
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
OK, I've seen this after writing the response. Normall that should
have worked but there is another jar issue there :) Just wait for jar
deployment please.
Thanks.
On 12/14/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ersin,
>
> > As a temporary solution, you can maven multiproject:install the
> > directory/shared/ldap/trunk project and then ...
>
> When I do that the tests won't compile:
>
> test:compile:
> [javac] Compiling 29 source files to
> C:\apacheds\directory\shared\ldap\trunk\common\target\test-classes
> C:\apacheds\directory\shared\ldap\trunk\common\src\test\org\apache\ldap\comm
> on\filter\FilterParserImplTest.java:182: cannot find symbol
> symbol : method utf8ToString(byte[])
> location: class org.apache.asn1.codec.util.StringUtils
> assertEquals( "dummyAssertion\\23\\ac", StringUtils.utf8ToString(
> node.getValue() ) );
> ^
> ... 10 more errors.
>
> Jeff
>
>
>
--
Ersin
Re: [ApacheDS] checkout problem
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>>>Another possibility is that we try to get trunks that can be compiled
>>>online, without any problems for the user. That means we have to deploy
>>>everytime we check-in some code. Pretty expensive.
>>>
>>>
>>>
>>>
>>IMO I think we should all be deploying changes with every check in. Yes
>>it is expensive :( but we have to or no one will be able to build properly.
>>
>>
>
>Last time I deployed everything, it took more than half an hour. This is
>simply impossible to accept this, as long as we are working on trunks.
>Working in branches is something that is not always necessary and it's
>not free, too.
>
>We have to consider that either we deliver releases more often (let say
>everytime a blocker or major bug is corrected), or we must have some
>kind of nightly build. Any other solution is simply too costly, IMHO.
>
>
Yes I like this idea of nightly builds. And it does save us.
>btw, I've a server that does nothing which can be used to build nighty
>builds if needed.
>
>Again, this is just MHO.
>
>
No you are right. I have always build stuff by hand and prevented
breakage that way. This though took my time considerably.
ALex
Re: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
> >Another possibility is that we try to get trunks that can be compiled
> >online, without any problems for the user. That means we have to deploy
> >everytime we check-in some code. Pretty expensive.
> >
> >
> IMO I think we should all be deploying changes with every check in. Yes
> it is expensive :( but we have to or no one will be able to build properly.
Last time I deployed everything, it took more than half an hour. This is
simply impossible to accept this, as long as we are working on trunks.
Working in branches is something that is not always necessary and it's
not free, too.
We have to consider that either we deliver releases more often (let say
everytime a blocker or major bug is corrected), or we must have some
kind of nightly build. Any other solution is simply too costly, IMHO.
Or maybe we have a building system that is not that expensive (1 or 2
minutes seems acceptable). We have to keep in mind that uploading all
jars will cost at least 1 min if we have a 1Mbs upload capacity, and 10
mins if it's only 128Mbs, and deploying a single jars is a question of
10 to 20 seconds.
btw, I've a server that does nothing which can be used to build nighty
builds if needed.
Again, this is just MHO.
-- Emmanuel
>
> Alex
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
--
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] checkout problem
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>I may be wrong, but generally we assume that people that want to build
>the full project from the trunk are not doing it online (thus, they are
>not downloading the jars - maven -o -).
>
We should presume both online and offline builds.
>Another possibility is that we try to get trunks that can be compiled
>online, without any problems for the user. That means we have to deploy
>everytime we check-in some code. Pretty expensive.
>
>
IMO I think we should all be deploying changes with every check in. Yes
it is expensive :( but we have to or no one will be able to build properly.
Alex
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
Other questions :
- maven version? ( *MUST* be 1.0.2 )
- java version ( *MUST* be 1.5.x)
--Emmanuel
On Thu, 2005-12-15 at 08:20 -0800, Jeff Lansing wrote:
> Ersin,
>
> > It works fine here. Please try this:
>
> > maven -Dgoal=clean,install multiproject:goal
>
> I tried this from directory/apacheds/trunk and quickly got:
> ...
> +----------------------------------------
> | Executing clean,install ApacheDS Shared
> | Memory: 4M/6M
> +----------------------------------------
> Attempting to download ldap-common-0.9.4-SNAPSHOT.jar.
>
> multiproject:goal:
> build:start:
>
> clean:clean:
> [delete] Deleting directory
> C:\apacheds\directory\apacheds\trunk\shared\target
>
> BUILD FAILED
> File...... C:\Documents and
> Settings\jlansing.XTCF\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.j
> elly
> Element... maven:reactor
> Line...... 217
> Column.... 9
> Unknown goal "install"
> Total time: 17 seconds
>
> I'm going to try deleting everything, and starting over from scratch.
>
> Jeff
>
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
--
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
On 12/16/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ersin,
>
> > Now what I'm doing is:
> >
> > $ wget
> http://cvs.apache.org/repository/directory-asn1/jars/asn1-codec-0.3.4-SNAPSH
> OT.jar
> >
> > $ jar -xf asn1-codec-0.3.4-SNAPSHOT.jar
> >
> > $ javap org.apache.asn1.codec.util.StringUtils
> ....
> > As you see there is a method "public static java.lang.String
> > utf8ToString(byte[]);".
> >
> > And also, after a successful build of apacheds/trunk I do this:
> >
> > $ cd $HOME/.maven/repository/directory-asn1/jars
> >
> > javap -classpath asn1-codec-0.3.4-SNAPSHOT.jar
> > org.apache.asn1.codec.util.StringUtils
> >
> > and the output is again the same:
> ....
> > What happens when you follow a procedure like above?
>
> When I follow the above procedure it works. The utf8ToString method is there
> both before and after the build, which now completes sucessfully.
>
> For me the question is *why* is the build successful in this case, and not
> previously?
>
> I try deleting the class files that were left around by the above procedure.
> It still builds ok.
> Then I try deleting the asn1 codec jar from the repository, that came from
> the 'wget' step above. It still builds ok.
> Then I try deleting the entire maven repository and recreating it.
> (install_repo.bat C:\Documents and Settings\jlansing.XTCF\.maven\repository)
> The build is still successful. So I conclude that it has nothing to do with
> the above procedure.
>
> Now I delete the entire directory tree and do a fresh checkout. I also
> delete the .maven/repository again and recreate it. And then do a build.
> Still successful.
>
> So the outcome is that things that absolutely failed yesterday are
> successful today.
>
> There is no way for me to know what has changed, but I am fairly confident
> that asn1-codec-0.3.4-SNAPSHOT.jar is now different. Maybe somebody has
> changed it. Or, I know that in the past Apache had two versions of cvs, one
> for developers and one for the general public, with a one-day delay in
> moving changes from one to the other. Maybe something like that has happened
> here.
I really do not know what has changed. I'm sure that the jar is the
same as yesterday's. You may have somewhat chaching issues. I'm glad
it's ok now.
If you find any problem from our side, let us know.
> Jeff
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ersin,
> Now what I'm doing is:
>
> $ wget
http://cvs.apache.org/repository/directory-asn1/jars/asn1-codec-0.3.4-SNAPSH
OT.jar
>
> $ jar -xf asn1-codec-0.3.4-SNAPSHOT.jar
>
> $ javap org.apache.asn1.codec.util.StringUtils
....
> As you see there is a method "public static java.lang.String
> utf8ToString(byte[]);".
>
> And also, after a successful build of apacheds/trunk I do this:
>
> $ cd $HOME/.maven/repository/directory-asn1/jars
>
> javap -classpath asn1-codec-0.3.4-SNAPSHOT.jar
> org.apache.asn1.codec.util.StringUtils
>
> and the output is again the same:
....
> What happens when you follow a procedure like above?
When I follow the above procedure it works. The utf8ToString method is there
both before and after the build, which now completes sucessfully.
For me the question is *why* is the build successful in this case, and not
previously?
I try deleting the class files that were left around by the above procedure.
It still builds ok.
Then I try deleting the asn1 codec jar from the repository, that came from
the 'wget' step above. It still builds ok.
Then I try deleting the entire maven repository and recreating it.
(install_repo.bat C:\Documents and Settings\jlansing.XTCF\.maven\repository)
The build is still successful. So I conclude that it has nothing to do with
the above procedure.
Now I delete the entire directory tree and do a fresh checkout. I also
delete the .maven/repository again and recreate it. And then do a build.
Still successful.
So the outcome is that things that absolutely failed yesterday are
successful today.
There is no way for me to know what has changed, but I am fairly confident
that asn1-codec-0.3.4-SNAPSHOT.jar is now different. Maybe somebody has
changed it. Or, I know that in the past Apache had two versions of cvs, one
for developers and one for the general public, with a one-day delay in
moving changes from one to the other. Maybe something like that has happened
here.
Jeff
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
Now what I'm doing is:
$ wget http://cvs.apache.org/repository/directory-asn1/jars/asn1-codec-0.3.4-SNAPSHOT.jar
$ jar -xf asn1-codec-0.3.4-SNAPSHOT.jar
$ javap org.apache.asn1.codec.util.StringUtils
and the output is:
Compiled from "StringUtils.java"
public class org.apache.asn1.codec.util.StringUtils extends java.lang.Object{
public static final boolean[] ALPHA;
public static final boolean[] CHAR;
public static final boolean[] DIGIT;
public static final int NOT_EQUAL;
public static final java.lang.String EMPTY;
public org.apache.asn1.codec.util.StringUtils();
public static java.lang.String dumpByte(byte);
public static java.lang.String dumpBytes(byte[]);
public static char bytesToChar(byte[]);
public static int countBytesPerChar(byte[], int);
public static int countNbBytesPerChar(char);
public static int countBytes(char[]);
public static char bytesToChar(byte[], int);
public static int countChars(byte[]);
public static int areEquals(byte[], int, java.lang.String);
public static int areEquals(char[], int, java.lang.String);
public static int areEquals(char[], int, char[]);
public static int areEquals(byte[], int, byte[]);
public static boolean isCharASCII(byte[], int, char);
public static boolean isCharASCII(char[], int, char);
public static boolean isHex(byte[], int);
public static boolean isHex(char[], int);
public static boolean isDigit(byte[]);
public static boolean isAlphaASCII(byte[], int);
public static boolean isAlphaASCII(char[], int);
public static boolean isDigit(byte[], int);
public static boolean isDigit(char[], int);
public static boolean isDigit(char[]);
public static boolean isAlphaDigitMinus(byte[], int);
public static boolean isAlphaDigitMinus(char[], int);
public static boolean isEmpty(java.lang.String);
public static boolean isNotEmpty(java.lang.String);
public static java.lang.String trim(java.lang.String);
public static java.lang.String trimLeft(java.lang.String);
public static int trimLeft(char[], int);
public static int trimLeft(byte[], int);
public static java.lang.String trimRight(java.lang.String);
public static int trimRight(char[], int);
public static int trimRight(byte[], int);
public static java.lang.String upperCase(java.lang.String);
public static java.lang.String lowerCase(java.lang.String);
public static boolean equals(java.lang.String, java.lang.String);
public static java.lang.String utf8ToString(byte[]);
public static byte[] getBytesUtf8(java.lang.String);
static {};
}
As you see there is a method "public static java.lang.String
utf8ToString(byte[]);".
And also, after a successful build of apacheds/trunk I do this:
$ cd $HOME/.maven/repository/directory-asn1/jars
javap -classpath asn1-codec-0.3.4-SNAPSHOT.jar
org.apache.asn1.codec.util.StringUtils
and the output is again the sama:
Compiled from "StringUtils.java"
public class org.apache.asn1.codec.util.StringUtils extends java.lang.Object{
public static final boolean[] ALPHA;
public static final boolean[] CHAR;
public static final boolean[] DIGIT;
public static final int NOT_EQUAL;
public static final java.lang.String EMPTY;
public org.apache.asn1.codec.util.StringUtils();
public static java.lang.String dumpByte(byte);
public static java.lang.String dumpBytes(byte[]);
public static char bytesToChar(byte[]);
public static int countBytesPerChar(byte[], int);
public static int countNbBytesPerChar(char);
public static int countBytes(char[]);
public static char bytesToChar(byte[], int);
public static int countChars(byte[]);
public static int areEquals(byte[], int, java.lang.String);
public static int areEquals(char[], int, java.lang.String);
public static int areEquals(char[], int, char[]);
public static int areEquals(byte[], int, byte[]);
public static boolean isCharASCII(byte[], int, char);
public static boolean isCharASCII(char[], int, char);
public static boolean isHex(byte[], int);
public static boolean isHex(char[], int);
public static boolean isDigit(byte[]);
public static boolean isAlphaASCII(byte[], int);
public static boolean isAlphaASCII(char[], int);
public static boolean isDigit(byte[], int);
public static boolean isDigit(char[], int);
public static boolean isDigit(char[]);
public static boolean isAlphaDigitMinus(byte[], int);
public static boolean isAlphaDigitMinus(char[], int);
public static boolean isEmpty(java.lang.String);
public static boolean isNotEmpty(java.lang.String);
public static java.lang.String trim(java.lang.String);
public static java.lang.String trimLeft(java.lang.String);
public static int trimLeft(char[], int);
public static int trimLeft(byte[], int);
public static java.lang.String trimRight(java.lang.String);
public static int trimRight(char[], int);
public static int trimRight(byte[], int);
public static java.lang.String upperCase(java.lang.String);
public static java.lang.String lowerCase(java.lang.String);
public static boolean equals(java.lang.String, java.lang.String);
public static java.lang.String utf8ToString(byte[]);
public static byte[] getBytesUtf8(java.lang.String);
static {};
}
What happens when you follow a procedure like above?
On 12/16/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Emmanuel,
>
> > Or may be we can put the jars somewhere you can download them?
>
> I thought "Hey, I already have the jars somewhere. They are right there in
> .maven\repository\directory\jars."
>
> So I tried to install those jars in our application. But (I guess not so
> surprisingly) I got exactly the same NoSuchMethod error in StringUtils when
> the server started up.
>
> So maybe I could just download them from somewhere?
>
> Jeff
>
> I tried using these:
> 12/15/2005 03:22 PM 683,356 apacheds-core-0.9.4-SNAPSHOT.jar
> 12/15/2005 03:29 PM 5,208,813 apacheds-server-main-0.9.4-SNAPSHOT.jar
> 12/15/2005 03:21 PM 9,766 apacheds-shared-0.9.4-SNAPSHOT.jar
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
> Or may be we can put the jars somewhere you can download them?
I thought "Hey, I already have the jars somewhere. They are right there in
.maven\repository\directory\jars."
So I tried to install those jars in our application. But (I guess not so
surprisingly) I got exactly the same NoSuchMethod error in StringUtils when
the server started up.
So maybe I could just download them from somewhere?
Jeff
I tried using these:
12/15/2005 03:22 PM 683,356 apacheds-core-0.9.4-SNAPSHOT.jar
12/15/2005 03:29 PM 5,208,813 apacheds-server-main-0.9.4-SNAPSHOT.jar
12/15/2005 03:21 PM 9,766 apacheds-shared-0.9.4-SNAPSHOT.jar
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
Maybe not so crazy.
Yes, that jar exists in that directory in the repository. Yes, the
StringUtils.class file exists in that jar. But there is not a method called
utf8toString in that class (see attached).
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Thursday, December 15, 2005 4:19 PM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] checkout problem
That's totally crazy...
In the trace you attached, I see that :
[junit] java.lang.NoSuchMethodError:
org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
[junit] at
org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindName
Rule.java:73)
This utf8ToString exists in this jar :
asn1-codec-0.3.4-SNAPSHOT.jar
If you look into your maven repo, you should find it in
.maven/repository/directory-asn1/jars
just do a jar tvf and you will see that this class exists.
Do you have CygWin working? Is it possible that you compile the project
on a linux server?
Or may be we can put the jars somewhere you can download them?
--Emmanuel
On Thu, 2005-12-15 at 15:58 -0800, Jeff Lansing wrote:
> Ersin,
>
> > Can you please try once again the normal way?
>
> > First a check out and then the maven multiproject:install.
>
> Well, I am starting to loose track of what "normal" might mean in this
> setting, but anyway I did the following:
>
> 1) Leave the repository as it was (after the previous deleting and
> regenerating).
> 2) Delete the entire directory checkout.
> 3) Run checkout-directory-new.bat.
> 4) Cd into directory\apacheds\trunk.
> 5) Do maven multiproject:install.
>
> The result (see attached) is not so different from the last time.
>
> Jeff
>
>
----------------------------------------------------------------------------
-----------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
--
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
That's totally crazy...
In the trace you attached, I see that :
[junit] java.lang.NoSuchMethodError:
org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
[junit] at
org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindNameRule.java:73)
This utf8ToString exists in this jar :
asn1-codec-0.3.4-SNAPSHOT.jar
If you look into your maven repo, you should find it in
.maven/repository/directory-asn1/jars
just do a jar tvf and you will see that this class exists.
Do you have CygWin working? Is it possible that you compile the project
on a linux server?
Or may be we can put the jars somewhere you can download them?
--Emmanuel
On Thu, 2005-12-15 at 15:58 -0800, Jeff Lansing wrote:
> Ersin,
>
> > Can you please try once again the normal way?
>
> > First a check out and then the maven multiproject:install.
>
> Well, I am starting to loose track of what "normal" might mean in this
> setting, but anyway I did the following:
>
> 1) Leave the repository as it was (after the previous deleting and
> regenerating).
> 2) Delete the entire directory checkout.
> 3) Run checkout-directory-new.bat.
> 4) Cd into directory\apacheds\trunk.
> 5) Do maven multiproject:install.
>
> The result (see attached) is not so different from the last time.
>
> Jeff
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
--
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ersin,
> Can you please try once again the normal way?
> First a check out and then the maven multiproject:install.
Well, I am starting to loose track of what "normal" might mean in this
setting, but anyway I did the following:
1) Leave the repository as it was (after the previous deleting and
regenerating).
2) Delete the entire directory checkout.
3) Run checkout-directory-new.bat.
4) Cd into directory\apacheds\trunk.
5) Do maven multiproject:install.
The result (see attached) is not so different from the last time.
Jeff
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
Can you please try once again the normal way?
First a check out and then the maven multiproject:install.
On 12/15/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ersin,
>
> Actually, bad luck. Same problem.
>
> See attached log file.
>
> Thanks,
>
> Jeff
>
>
> -----Original Message-----
> From: Ersin Er [mailto:ersin.er@gmail.com]
> Sent: Thursday, December 15, 2005 10:52 AM
> To: Apache Directory Developers List
> Subject: Re: [ApacheDS] checkout problem
>
> Well, this is really odd. As seems in the log the problem occurs in
> Server unit testing code when using MINA jar. This should be a jar
> problem. The MINA source code does not contain the any utf8ToString
> like stuff, here:
>
> http://svn.apache.org/viewcvs.cgi/directory/network/trunk/src/java/org/apach
> e/mina/filter/codec/ProtocolCodecFilter.java?rev=354382&view=markup
>
> OK now what I can offer:
>
> First delete your maven repo:
>
> del %HOMEDRIVE%%HOMEPATH%\.maven\repository
>
> (or delete it in some Window$ way..)
>
> then install a fresh maven repo (as stated at the maven site):
>
> %MAVEN_HOME%\bin\install_repo.bat %HOMEDRIVE%%HOMEPATH%\.maven\repository
>
> Good luck!
>
>
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ersin,
Actually, bad luck. Same problem.
See attached log file.
Thanks,
Jeff
-----Original Message-----
From: Ersin Er [mailto:ersin.er@gmail.com]
Sent: Thursday, December 15, 2005 10:52 AM
To: Apache Directory Developers List
Subject: Re: [ApacheDS] checkout problem
Well, this is really odd. As seems in the log the problem occurs in
Server unit testing code when using MINA jar. This should be a jar
problem. The MINA source code does not contain the any utf8ToString
like stuff, here:
http://svn.apache.org/viewcvs.cgi/directory/network/trunk/src/java/org/apach
e/mina/filter/codec/ProtocolCodecFilter.java?rev=354382&view=markup
OK now what I can offer:
First delete your maven repo:
del %HOMEDRIVE%%HOMEPATH%\.maven\repository
(or delete it in some Window$ way..)
then install a fresh maven repo (as stated at the maven site):
%MAVEN_HOME%\bin\install_repo.bat %HOMEDRIVE%%HOMEPATH%\.maven\repository
Good luck!
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
Well, this is really odd. As seems in the log the problem occurs in
Server unit testing code when using MINA jar. This should be a jar
problem. The MINA source code does not contain the any utf8ToString
like stuff, here:
http://svn.apache.org/viewcvs.cgi/directory/network/trunk/src/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java?rev=354382&view=markup
OK now what I can offer:
First delete your maven repo:
del %HOMEDRIVE%%HOMEPATH%\.maven\repository
(or delete it in some Window$ way..)
then install a fresh maven repo (as stated at the maven site):
%MAVEN_HOME%\bin\install_repo.bat %HOMEDRIVE%%HOMEPATH%\.maven\repository
Good luck!
On 12/15/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Emmanuel,
>
> c:\>java -version
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
>
> c:\>maven --version
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0.2
>
> My attempt to delete the directory directory tree and the maven repository,
> then check everything out again, and then rebuild with
>
> maven multiproject:install
>
> resulted in the same compile problem involving StringUtils.utf8ToString.
>
> Trying your new recommendation:
>
> maven -Dgoal=clean multiproject:goal SUCCESS
>
> maven multiproject:install FAILURE (same place. See attached log file).
>
> Jeff
>
>
> -----Original Message-----
> From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
> Sent: Thursday, December 15, 2005 8:51 AM
> To: Apache Directory Developers List
> Subject: RE: [ApacheDS] checkout problem
>
> Maven ...
>
> Ok, what about :
>
> maven -Dgoal=clean multiproject:goal
>
> then
>
> maven multiproject:install
>
> ?
>
> --Emmanuel
>
> On Thu, 2005-12-15 at 08:20 -0800, Jeff Lansing wrote:
> > Ersin,
> >
> > > It works fine here. Please try this:
> >
> > > maven -Dgoal=clean,install multiproject:goal
> >
> > I tried this from directory/apacheds/trunk and quickly got:
> > ...
> > +----------------------------------------
> > | Executing clean,install ApacheDS Shared
> > | Memory: 4M/6M
> > +----------------------------------------
> > Attempting to download ldap-common-0.9.4-SNAPSHOT.jar.
> >
> > multiproject:goal:
> > build:start:
> >
> > clean:clean:
> > [delete] Deleting directory
> > C:\apacheds\directory\apacheds\trunk\shared\target
> >
> > BUILD FAILED
> > File...... C:\Documents and
> >
> Settings\jlansing.XTCF\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.j
> > elly
> > Element... maven:reactor
> > Line...... 217
> > Column.... 9
> > Unknown goal "install"
> > Total time: 17 seconds
> >
> > I'm going to try deleting everything, and starting over from scratch.
> >
> > Jeff
> >
> >
> >
> ----------------------------------------------------------------------------
> -----------
> > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
>
> > Aucun virus connu a ce jour par nos services n'a ete detecte.
> >
> >
> >
> --
> Emmanuel Lécharny
> www.iktek.com
>
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
c:\>java -version
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
c:\>maven --version
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
My attempt to delete the directory directory tree and the maven repository,
then check everything out again, and then rebuild with
maven multiproject:install
resulted in the same compile problem involving StringUtils.utf8ToString.
Trying your new recommendation:
maven -Dgoal=clean multiproject:goal SUCCESS
maven multiproject:install FAILURE (same place. See attached log file).
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Thursday, December 15, 2005 8:51 AM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] checkout problem
Maven ...
Ok, what about :
maven -Dgoal=clean multiproject:goal
then
maven multiproject:install
?
--Emmanuel
On Thu, 2005-12-15 at 08:20 -0800, Jeff Lansing wrote:
> Ersin,
>
> > It works fine here. Please try this:
>
> > maven -Dgoal=clean,install multiproject:goal
>
> I tried this from directory/apacheds/trunk and quickly got:
> ...
> +----------------------------------------
> | Executing clean,install ApacheDS Shared
> | Memory: 4M/6M
> +----------------------------------------
> Attempting to download ldap-common-0.9.4-SNAPSHOT.jar.
>
> multiproject:goal:
> build:start:
>
> clean:clean:
> [delete] Deleting directory
> C:\apacheds\directory\apacheds\trunk\shared\target
>
> BUILD FAILED
> File...... C:\Documents and
>
Settings\jlansing.XTCF\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.j
> elly
> Element... maven:reactor
> Line...... 217
> Column.... 9
> Unknown goal "install"
> Total time: 17 seconds
>
> I'm going to try deleting everything, and starting over from scratch.
>
> Jeff
>
>
>
----------------------------------------------------------------------------
-----------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
--
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
Maven ...
Ok, what about :
maven -Dgoal=clean multiproject:goal
then
maven multiproject:install
?
--Emmanuel
On Thu, 2005-12-15 at 08:20 -0800, Jeff Lansing wrote:
> Ersin,
>
> > It works fine here. Please try this:
>
> > maven -Dgoal=clean,install multiproject:goal
>
> I tried this from directory/apacheds/trunk and quickly got:
> ...
> +----------------------------------------
> | Executing clean,install ApacheDS Shared
> | Memory: 4M/6M
> +----------------------------------------
> Attempting to download ldap-common-0.9.4-SNAPSHOT.jar.
>
> multiproject:goal:
> build:start:
>
> clean:clean:
> [delete] Deleting directory
> C:\apacheds\directory\apacheds\trunk\shared\target
>
> BUILD FAILED
> File...... C:\Documents and
> Settings\jlansing.XTCF\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.j
> elly
> Element... maven:reactor
> Line...... 217
> Column.... 9
> Unknown goal "install"
> Total time: 17 seconds
>
> I'm going to try deleting everything, and starting over from scratch.
>
> Jeff
>
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
--
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel, Ersin,
Thanks guys for all your patient help.
We have deployed the new jars on our multiprocessor system.
There was a slight problem in our code, due to the fact that formerly
userpassword was a String and now it's a byte[].
Other than that, everything seems to work well. We will leave it running
over the weekend to see what happens.
Thanks again,
Jeff
RE: [ApacheDS] authentication problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
So far no synchronization problems. I don't know about memory leaks; I'll
start watching for that.
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Monday, December 19, 2005 1:01 PM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] authentication problem
Hi Jeff,
btw, what about the test you launched friday? Has it ran ok? No
synchronization problems, no memory leaks?
Thanks for the feedback !
--Emmanuel
RE: [ApacheDS] Race condition in DNParser
Posted by Emmanuel Lecharny <el...@gmail.com>.
Thanks a lot for the feedback !
We are currently working on a new implementation of the DnParser which
will be totally stateless, thus we will not need anymore
synchronization, and which will be 2 times faster than the current one -
may be faster as it does not need synch. -
What kind of performance do you have? Is it possible that you give us
some info on the number of requests per second you have, and which kind
of requests (bind, search, add)? Of course, I'm not asking for a
performance test, but just wanted o know what you can obtain an a 4 proc
serveur !
Thanks a lot, jeff.
On Thu, 2005-12-22 at 09:09 -0800, Jeff Lansing wrote:
> Emmanuel,
>
> FYI, the problem that we were initially experiencing has not reoccurred
> after almost a week of testing. I am now fairly confident that it must have
> been fixed by http://issues.apache.org/jira/browse/DIRLDAP-70.
>
> Thanks,
>
> Jeff
>
> -----Original Message-----
> From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
> Sent: Monday, December 19, 2005 1:01 PM
> To: Apache Directory Developers List
> Subject: RE: [ApacheDS] authentication problem
>
> Hi Jeff,
>
> btw, what about the test you launched friday? Has it ran ok? No
> synchronization problems, no memory leaks?
>
> Thanks for the feedback !
>
> --Emmanuel
>
>
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
--
Emmanuel Lécharny
www.iktek.com
RE: [ApacheDS] Race condition in DNParser
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
FYI, the problem that we were initially experiencing has not reoccurred
after almost a week of testing. I am now fairly confident that it must have
been fixed by http://issues.apache.org/jira/browse/DIRLDAP-70.
Thanks,
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Monday, December 19, 2005 1:01 PM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] authentication problem
Hi Jeff,
btw, what about the test you launched friday? Has it ran ok? No
synchronization problems, no memory leaks?
Thanks for the feedback !
--Emmanuel
RE: [ApacheDS] authentication problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Jeff,
btw, what about the test you launched friday? Has it ran ok? No
synchronization problems, no memory leaks?
Thanks for the feedback !
--Emmanuel
RE: [ApacheDS] authentication problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Stefan,
> How about your other problem? Does it still exist? You told us about a
> code snippet like this:
>
> InitialDirContext ctx = new InitialDirContext();
> LdapName name = new LdapName("ou=users");
> Attributes attributes = new LockableAttributesImpl();
> attributes.put("uid", "jdoe");
> NamingEnumeration ne = ctx.search(name, attributes);
>
> Can you provide information about the JNDI config you use (file
> jndi.properties, for instance)? Is it the LDAP provider from Sun, and
> are you talking about the network with plain LDAP?
The other problem was my fault. I didn't realize that the password attribute
was now returned as a byte[]. (I think formerly it was a String.)
We have embedded ApacheDS in our application. We could use the Sun provider,
but by embedding the directory, it starts up and stops at the same time as
our other services. Of course we can also talk to the directory itself with
an LDAP client (JXplorer, say).
Our application is based on the Globus ws-core, which uses JNDI for all of
its configuration, based on (lots of) jndi-config.xml files. We added an
additional layer by writing a custom InitialContextFactory that returns
InitialContexts that wrap the LDAP ones, but translate J2EE style names to
LdapNames (i.e., java:/comp/env/foo gets translated to dn=foo, dn=env,
dn=comp, ou=j2ee, ou=system), and vice-versa. In this way we keep all of the
Globus configuration in the directory, where it can be dynamically modified,
persisted, etc. without changing any of their code.
Jeff
Re: [ApacheDS] authentication problem
Posted by Stefan Zoerner <sz...@apache.org>.
Jeff Lansing wrote:
>
> I am using Windows XP with openldap 2.2.19. If I change the quotes as you
> suggest then the examples work ok.
>
Thank you for your valuable feedback, Jeff. In order to prevent others
from this trap I have modified the type of quotes in the LDAP command
line tool examples here:
http://directory.apache.org/subprojects/apacheds/users/authentication.html
How about your other problem? Does it still exist? You told us about a
code snippet like this:
InitialDirContext ctx = new InitialDirContext();
LdapName name = new LdapName("ou=users");
Attributes attributes = new LockableAttributesImpl();
attributes.put("uid", "jdoe");
NamingEnumeration ne = ctx.search(name, attributes);
Can you provide information about the JNDI config you use (file
jndi.properties, for instance)? Is it the LDAP provider from Sun, and
are you talking about the network with plain LDAP?
If so, I do not understand why you use class LockableAttributesImpl,
which is not part of JNDI. In order to create portable client code,
class javax.naming.directory.BasicAttributes should work for you.
Greetings, Stefan
RE: [ApacheDS] authentication problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Stephan,
> Which OS and LDAP clients do you use? I was able to reproduce it on
> Windows XP with the IBM TivoliDS LDAP client:
...
> Tell us whether it works for you now when you use -D "...". If yes, we
> should update the examples.
I am using Windows XP with openldap 2.2.19. If I change the quotes as you
suggest then the examples work ok.
Thanks,
Jeff
Re: [ApacheDS] authentication problem
Posted by Stefan Zoerner <sz...@apache.org>.
Jeff Lansing wrote:
> ...
> However, none of the examples on the page
> http://directory.apache.org/subprojects/apacheds/users/authentication.html
> will work. For example:
>
> C:\openldap>ldapsearch -D 'uid=admin,ou=system' -h localhost -p 10389 -x -w
> secret -s one -b 'ou=users,ou=system' '(uid=jdoe)'
> ldap_bind: Invalid credentials (49)
> additional info: Bind failed
>
> ...
>
> Any suggestions?
>
Hi Jeff!
At least for this one. I was able to reproduce this error and recommend
not to use '...' for the -D argument, but "..." (actually, for all of
the args!).
Which OS and LDAP clients do you use? I was able to reproduce it on
Windows XP with the IBM TivoliDS LDAP client:
C:\>ldapsearch -h magritte -p 10389 -b "ou=users,ou=system" -s base -D
'uid=admin,ou=system' -w secret "(objectclass=*)"
ldap_simple_bind: Invalid credentials
C:\>ldapsearch -h magritte -p 10389 -b "ou=users,ou=system" -s base -D
"uid=admin,ou=system" -w secret "(objectclass=*)"
ou=users,ou=system
objectClass=organizationalUnit
objectClass=top
ou=users
The same effect does not happen e.g. on Solaris9/bash with Suns own
ldapsearch. Here it doesn't matter whether one uses -D '...' or -D "..."
(this is why the example docs probably worked for the author, s/he used
a different environment).
Tell us whether it works for you now when you use -D "...". If yes, we
should update the examples.
Greetings from Hamburg,
Stefan
[ApacheDS] authentication problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Hi,
I am having problems connecting to the ldap server. (I am using an 0.9.4
SNAPSHOT build created today. I did not have these problems with 0.9.3)
I can connect with JXplorer, as admin, and add a user, for instance with the
newuser.ldif example. I can see the new user in JXplorer. I can then
disconnect and reconnect as uid=jdoe,ou=users,ou=system with JXplorer.
However, none of the examples on the page
http://directory.apache.org/subprojects/apacheds/users/authentication.html
will work. For example:
C:\openldap>ldapsearch -D 'uid=admin,ou=system' -h localhost -p 10389 -x -w
secret -s one -b 'ou=users,ou=system' '(uid=jdoe)'
ldap_bind: Invalid credentials (49)
additional info: Bind failed
More importantly (to me), I can no longer search programmatically for users,
as in:
InitialDirContext ctx = new InitialDirContext();
LdapName name = new LdapName("ou=users");
Attributes attributes = new LockableAttributesImpl();
attributes.put("uid", "jdoe");
NamingEnumeration ne = ctx.search(name, attributes);
which returns nothing.
I know the user is there because I can connect as that user with JXplorer.
Surely I am doing something stupid, but I just don't see what.
Any suggestions?
Jeff
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ersin,
> It works fine here. Please try this:
> maven -Dgoal=clean,install multiproject:goal
I tried this from directory/apacheds/trunk and quickly got:
...
+----------------------------------------
| Executing clean,install ApacheDS Shared
| Memory: 4M/6M
+----------------------------------------
Attempting to download ldap-common-0.9.4-SNAPSHOT.jar.
multiproject:goal:
build:start:
clean:clean:
[delete] Deleting directory
C:\apacheds\directory\apacheds\trunk\shared\target
BUILD FAILED
File...... C:\Documents and
Settings\jlansing.XTCF\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.j
elly
Element... maven:reactor
Line...... 217
Column.... 9
Unknown goal "install"
Total time: 17 seconds
I'm going to try deleting everything, and starting over from scratch.
Jeff
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
It works fine here. Please try this:
maven -Dgoal=clean,install multiproject:goal
On 12/15/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Emmanuel,
>
> Sorry for the delay. The build gets to this point and then hangs for a very
> long time.
>
> test:compile:
> [javac] Compiling 8 source files to
> C:\apacheds\directory\apacheds\trunk\server-unit\target\test-classes
>
> test:test:
> [junit] Running org.apache.ldap.server.AddObjectClassesToEntryTest
> [junit] [17:52:40] ERROR [org.apache.asn1.ber.digester.BERDigester] -
> Error while triggering rule org.apache.ldap.common.berlib.asn1.dec
> oder.bind.BindNameRule@132ae7 with digester
> org.apache.asn1.ber.digester.BERDigester@65b738: Rule.finish() threw error
> [junit] java.lang.NoSuchMethodError:
> org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
> [junit] at
> org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindName
> Rule.java:73)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester.fireFinishEvent(BERDigester.java:11
> 49)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester$DigesterCallback.decodeOccurred(BER
> Digester.java:213)
> [junit] at
> org.apache.asn1.ber.BERDecoder.fireDecodeOccurred(BERDecoder.java:399)
> [junit] at
> org.apache.asn1.ber.BERDecoder.decodeValue(BERDecoder.java:226)
> [junit] at
> org.apache.asn1.ber.BERDecoder.decode(BERDecoder.java:159)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester.decode(BERDigester.java:158)
> [junit] at
> org.apache.ldap.common.berlib.asn1.SnickersDecoder.decode(SnickersDecoder.ja
> va:100)
> [junit] at
> org.apache.ldap.common.message.MessageDecoder.decode(MessageDecoder.java:200
> )
> [junit] at
> org.apache.asn1.codec.mina.Asn1CodecDecoder.decode(Asn1CodecDecoder.java:37)
> [junit] at
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
> ecFilter.java:56)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
> (AbstractIoFilterChain.java:494)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoF
> ilterChain.java:52)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece
> ived(AbstractIoFilterChain.java:761)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:6
> 65)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPoolFilte
> r.java:421)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.java:376
> )
> [junit] [17:52:40] ERROR
> [org.apache.ldap.server.protocol.LdapProtocolProvider$LdapProtocolHandler] -
> [/127.0.0.1:2782] EXCEPTION:
> [junit] org.apache.mina.filter.codec.ProtocolDecoderException:
> java.lang.NoSuchMethodError: org.apache.asn1.codec.util.StringUtils.utf8T
> oString([B)Ljava/lang/String; (Hexdump: 80 06 73 65 63 72 65 74)
> [junit] at
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
> ecFilter.java:68)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
> (AbstractIoFilterChain.java:494)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoF
> ilterChain.java:52)
> [junit] at
> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece
> ived(AbstractIoFilterChain.java:761)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:6
> 65)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPoolFilte
> r.java:421)
> [junit] at
> org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.java:376
> )
> [junit] Caused by: java.lang.NoSuchMethodError:
> org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
> [junit] at
> org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindName
> Rule.java:73)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester.fireFinishEvent(BERDigester.java:11
> 49)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester$DigesterCallback.decodeOccurred(BER
> Digester.java:213)
> [junit] at
> org.apache.asn1.ber.BERDecoder.fireDecodeOccurred(BERDecoder.java:399)
> [junit] at
> org.apache.asn1.ber.BERDecoder.decodeValue(BERDecoder.java:226)
> [junit] at
> org.apache.asn1.ber.BERDecoder.decode(BERDecoder.java:159)
> [junit] at
> org.apache.asn1.ber.digester.BERDigester.decode(BERDigester.java:158)
> [junit] at
> org.apache.ldap.common.berlib.asn1.SnickersDecoder.decode(SnickersDecoder.ja
> va:100)
> [junit] at
> org.apache.ldap.common.message.MessageDecoder.decode(MessageDecoder.java:200
> )
> [junit] at
> org.apache.asn1.codec.mina.Asn1CodecDecoder.decode(Asn1CodecDecoder.java:37)
> [junit] at
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
> ecFilter.java:56)
> [junit] ... 6 more
>
> Jeff
>
> -----Original Message-----
> From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
> Sent: Wednesday, December 14, 2005 10:49 AM
> To: Apache Directory Developers List
> Subject: RE: [ApacheDS] checkout problem
>
> Jeff,
>
> I have redeployed all the needed jars.
>
> Could you try again to build the project?
>
> -- Emmanuel
>
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
Sorry for the delay. The build gets to this point and then hangs for a very
long time.
test:compile:
[javac] Compiling 8 source files to
C:\apacheds\directory\apacheds\trunk\server-unit\target\test-classes
test:test:
[junit] Running org.apache.ldap.server.AddObjectClassesToEntryTest
[junit] [17:52:40] ERROR [org.apache.asn1.ber.digester.BERDigester] -
Error while triggering rule org.apache.ldap.common.berlib.asn1.dec
oder.bind.BindNameRule@132ae7 with digester
org.apache.asn1.ber.digester.BERDigester@65b738: Rule.finish() threw error
[junit] java.lang.NoSuchMethodError:
org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
[junit] at
org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindName
Rule.java:73)
[junit] at
org.apache.asn1.ber.digester.BERDigester.fireFinishEvent(BERDigester.java:11
49)
[junit] at
org.apache.asn1.ber.digester.BERDigester$DigesterCallback.decodeOccurred(BER
Digester.java:213)
[junit] at
org.apache.asn1.ber.BERDecoder.fireDecodeOccurred(BERDecoder.java:399)
[junit] at
org.apache.asn1.ber.BERDecoder.decodeValue(BERDecoder.java:226)
[junit] at
org.apache.asn1.ber.BERDecoder.decode(BERDecoder.java:159)
[junit] at
org.apache.asn1.ber.digester.BERDigester.decode(BERDigester.java:158)
[junit] at
org.apache.ldap.common.berlib.asn1.SnickersDecoder.decode(SnickersDecoder.ja
va:100)
[junit] at
org.apache.ldap.common.message.MessageDecoder.decode(MessageDecoder.java:200
)
[junit] at
org.apache.asn1.codec.mina.Asn1CodecDecoder.decode(Asn1CodecDecoder.java:37)
[junit] at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
ecFilter.java:56)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
(AbstractIoFilterChain.java:494)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoF
ilterChain.java:52)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece
ived(AbstractIoFilterChain.java:761)
[junit] at
org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:6
65)
[junit] at
org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPoolFilte
r.java:421)
[junit] at
org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.java:376
)
[junit] [17:52:40] ERROR
[org.apache.ldap.server.protocol.LdapProtocolProvider$LdapProtocolHandler] -
[/127.0.0.1:2782] EXCEPTION:
[junit] org.apache.mina.filter.codec.ProtocolDecoderException:
java.lang.NoSuchMethodError: org.apache.asn1.codec.util.StringUtils.utf8T
oString([B)Ljava/lang/String; (Hexdump: 80 06 73 65 63 72 65 74)
[junit] at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
ecFilter.java:68)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
(AbstractIoFilterChain.java:494)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoF
ilterChain.java:52)
[junit] at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece
ived(AbstractIoFilterChain.java:761)
[junit] at
org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:6
65)
[junit] at
org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPoolFilte
r.java:421)
[junit] at
org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.java:376
)
[junit] Caused by: java.lang.NoSuchMethodError:
org.apache.asn1.codec.util.StringUtils.utf8ToString([B)Ljava/lang/String;
[junit] at
org.apache.ldap.common.berlib.asn1.decoder.bind.BindNameRule.finish(BindName
Rule.java:73)
[junit] at
org.apache.asn1.ber.digester.BERDigester.fireFinishEvent(BERDigester.java:11
49)
[junit] at
org.apache.asn1.ber.digester.BERDigester$DigesterCallback.decodeOccurred(BER
Digester.java:213)
[junit] at
org.apache.asn1.ber.BERDecoder.fireDecodeOccurred(BERDecoder.java:399)
[junit] at
org.apache.asn1.ber.BERDecoder.decodeValue(BERDecoder.java:226)
[junit] at
org.apache.asn1.ber.BERDecoder.decode(BERDecoder.java:159)
[junit] at
org.apache.asn1.ber.digester.BERDigester.decode(BERDigester.java:158)
[junit] at
org.apache.ldap.common.berlib.asn1.SnickersDecoder.decode(SnickersDecoder.ja
va:100)
[junit] at
org.apache.ldap.common.message.MessageDecoder.decode(MessageDecoder.java:200
)
[junit] at
org.apache.asn1.codec.mina.Asn1CodecDecoder.decode(Asn1CodecDecoder.java:37)
[junit] at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod
ecFilter.java:56)
[junit] ... 6 more
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Wednesday, December 14, 2005 10:49 AM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] checkout problem
Jeff,
I have redeployed all the needed jars.
Could you try again to build the project?
-- Emmanuel
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
Jeff,
I have redeployed all the needed jars.
Could you try again to build the project?
-- Emmanuel
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
> Well, you are experiencing the "Apache way" and the "Maven magic"...
> Sorry about that.
Believe me, it's not just the "Apache way" and the "Maven magic". All
development projects (including even mine) have these kinds of problems
frequently.
I really appreciate all the help that I am getting from you guys.
Thanks again,
Jeff
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
On Tue, 2005-12-13 at 15:01 -0800, Jeff Lansing wrote:
> ... 10 more errors.
Well, you are experiencing the "Apache way" and the "Maven magic"...
Sorry about that.
As there are some modifications in the different subprojects, you may
have problems building them if you don't do it in the correct order (and
of course off line), or if you are using maven online (and if the jars
are not deployed).
I may be wrong, but generally we assume that people that want to build
the full project from the trunk are not doing it online (thus, they are
not downloading the jars - maven -o -). In this case, of course, you
should *know* what has to be compiled first. This is not obvious.
You can have a look to http://wiki.apache.org/directory/IdeHome, but
this is clearly outdated. However, the compilation order should not have
changed a lot
(http://wiki.apache.org/directory/IdeHome#head-469379613431ffb7f1e5deff034ad7beb607a657)
Another possibility is that we try to get trunks that can be compiled
online, without any problems for the user. That means we have to deploy
everytime we check-in some code. Pretty expensive.
At this point, we hit a wall. Either we have a
maven -o multiproject:install
that build all the projects in the correct order, or we we should find
another way to work out that kind of problem.
What I can say is that even if you are suffering of it, you are not
alone. We all do. And that's not good.
Again, I'm sorry, and more than that, I'm ashamed of this situation.
This is obviously something that should be fixed *really* quickly.
I have no solution right now. I tried to build each subprojects using
maven -o, but, damn, some jars are not in my personal repository
(commons-lang is used in 2.0 and 2.1 versions, which is *BAD*)
I promise that we are going to work this out in the next few days, we
are doing our best. I'm lucky enough to be able to dedicate full time on
this right now, just be patient and notice that it's just a HEAD, not a
delivered version, so this is the kind of problem you may encounter.
Fyi, I'm in France, so I'm GMT+1, and I'm in front of my computer form
9AM GMT to 1AM GMT, with breaks for lunch (2 hours in France ;) and
dinner (2 more hours ;)
I wil try to handle this situation tomotrow morning as soon as I have my
coffee, I promise !
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ersin,
> As a temporary solution, you can maven multiproject:install the
> directory/shared/ldap/trunk project and then ...
When I do that the tests won't compile:
test:compile:
[javac] Compiling 29 source files to
C:\apacheds\directory\shared\ldap\trunk\common\target\test-classes
C:\apacheds\directory\shared\ldap\trunk\common\src\test\org\apache\ldap\comm
on\filter\FilterParserImplTest.java:182: cannot find symbol
symbol : method utf8ToString(byte[])
location: class org.apache.asn1.codec.util.StringUtils
assertEquals( "dummyAssertion\\23\\ac", StringUtils.utf8ToString(
node.getValue() ) );
^
... 10 more errors.
Jeff
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
I've just checked now, yes, it's a jar issue. The deployed packages
does not reflect the current trunk. It will be fixed as soon as
possible. Sorry for inconvinience.
As a temporary solution, you can maven multiproject:install the
directory/shared/ldap/trunk project and then make a maven -o
multiproject:install in apacheds/trunk (which will make an offline
build and use your installed ldap-common.jar).
On 12/13/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ok. I do maven multiproject:install instead (in directory/apacheds/trunk).
> But I still get the same compile error.
>
> I see that LdapName.EMPTY_LDAP_NAME is defined in the LdapName.java source,
> so there might be some jar in the way, containing an older version of
> LdapName.
>
> Unfortunately, I don't understand enough about the way the build works to
> fix this myself.
>
> Any suggestions would be greatly appreciated.
>
> Thanks,
>
> Jeff
>
>
> -----Original Message-----
> From: Ersin Er [mailto:ersin.er@gmail.com]
> Sent: Tuesday, December 13, 2005 11:45 AM
> To: Apache Directory Developers List
> Subject: Re: [ApacheDS] checkout problem
>
> On 12/13/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> > Ok, the script works on Windows as advertised.
> >
> > Now what I think I'm supposed to do is to cd into directory/apacheds/trunk
> > and run maven.
>
> apacheds is a multi part project. So you should invoke maven as:
>
> maven multiproject:install
>
> ("install" will build a jar in your repository for you.)
>
> > When I do that I get a compile error:
> >
> > ...
> > [echo] Compiling to
> > C:\apacheds\directory\apacheds\trunk\core/target/classes
> > [javac] Compiling 410 source files to
> > C:\apacheds\directory\apacheds\trunk\core\target\classes
> >
> C:\apacheds\directory\apacheds\trunk\core\src\main\java\org\apache\ldap\serv
> > er\jndi\ServerContext.java:573: cannot find symbol
> > symbol : variable EMPTY_LDAP_NAME
> > location: class org.apache.ldap.common.name.LdapName
> > return lookup( LdapName.EMPTY_LDAP_NAME );
> > ^
> > 1 error
> >
> > BUILD FAILED
> >
> > What am I missing?
> >
> > Jeff
> >
> >
> >
>
>
> --
> Ersin
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ok. I do maven multiproject:install instead (in directory/apacheds/trunk).
But I still get the same compile error.
I see that LdapName.EMPTY_LDAP_NAME is defined in the LdapName.java source,
so there might be some jar in the way, containing an older version of
LdapName.
Unfortunately, I don't understand enough about the way the build works to
fix this myself.
Any suggestions would be greatly appreciated.
Thanks,
Jeff
-----Original Message-----
From: Ersin Er [mailto:ersin.er@gmail.com]
Sent: Tuesday, December 13, 2005 11:45 AM
To: Apache Directory Developers List
Subject: Re: [ApacheDS] checkout problem
On 12/13/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ok, the script works on Windows as advertised.
>
> Now what I think I'm supposed to do is to cd into directory/apacheds/trunk
> and run maven.
apacheds is a multi part project. So you should invoke maven as:
maven multiproject:install
("install" will build a jar in your repository for you.)
> When I do that I get a compile error:
>
> ...
> [echo] Compiling to
> C:\apacheds\directory\apacheds\trunk\core/target/classes
> [javac] Compiling 410 source files to
> C:\apacheds\directory\apacheds\trunk\core\target\classes
>
C:\apacheds\directory\apacheds\trunk\core\src\main\java\org\apache\ldap\serv
> er\jndi\ServerContext.java:573: cannot find symbol
> symbol : variable EMPTY_LDAP_NAME
> location: class org.apache.ldap.common.name.LdapName
> return lookup( LdapName.EMPTY_LDAP_NAME );
> ^
> 1 error
>
> BUILD FAILED
>
> What am I missing?
>
> Jeff
>
>
>
--
Ersin
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
On 12/13/05, Jeff Lansing <jl...@spawar.navy.mil> wrote:
> Ok, the script works on Windows as advertised.
>
> Now what I think I'm supposed to do is to cd into directory/apacheds/trunk
> and run maven.
apacheds is a multi part project. So you should invoke maven as:
maven multiproject:install
("install" will build a jar in your repository for you.)
> When I do that I get a compile error:
>
> ...
> [echo] Compiling to
> C:\apacheds\directory\apacheds\trunk\core/target/classes
> [javac] Compiling 410 source files to
> C:\apacheds\directory\apacheds\trunk\core\target\classes
> C:\apacheds\directory\apacheds\trunk\core\src\main\java\org\apache\ldap\serv
> er\jndi\ServerContext.java:573: cannot find symbol
> symbol : variable EMPTY_LDAP_NAME
> location: class org.apache.ldap.common.name.LdapName
> return lookup( LdapName.EMPTY_LDAP_NAME );
> ^
> 1 error
>
> BUILD FAILED
>
> What am I missing?
>
> Jeff
>
>
>
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Ok, the script works on Windows as advertised.
Now what I think I'm supposed to do is to cd into directory/apacheds/trunk
and run maven.
When I do that I get a compile error:
...
[echo] Compiling to
C:\apacheds\directory\apacheds\trunk\core/target/classes
[javac] Compiling 410 source files to
C:\apacheds\directory\apacheds\trunk\core\target\classes
C:\apacheds\directory\apacheds\trunk\core\src\main\java\org\apache\ldap\serv
er\jndi\ServerContext.java:573: cannot find symbol
symbol : variable EMPTY_LDAP_NAME
location: class org.apache.ldap.common.name.LdapName
return lookup( LdapName.EMPTY_LDAP_NAME );
^
1 error
BUILD FAILED
What am I missing?
Jeff
Re: [ApacheDS] checkout problem
Posted by Ersin Er <er...@gmail.com>.
On 12/13/05, Emmanuel Lecharny <el...@gmail.com> wrote:
> On Tue, 2005-12-13 at 08:58 -0800, Jeff Lansing wrote:
> Ok. What you can do is just to launch the script that you can find at
> the top level :
>
> http://svn.apache.org/viewcvs.cgi/directory/?root=Apache-SVN
>
>
> it's *nix name is :
>
> checkout-directory-new.sh
>
> I think that you just have to change its name to
> checkout-directory-new.bat
>
> and execute it. It should work as the inner commands are just echo and
> svn.
>
> It will just check out the trunks.
FYI, the script works on Windows. (I've just tested it now.) Just
create a directory named "directory" and execute the script from that
directory. (It will be better if the script is not placed in
"directory" while the copy on the repository will be checked out by
the script.)
> --Emmanuel
--
Ersin
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
On Tue, 2005-12-13 at 08:58 -0800, Jeff Lansing wrote:
> Emmanuel,
>
> Yes. LINUX is able to distinguish DnNParserTest.java from DNParserTest.java.
> Windows is not. Unfortunately all of out development machines are Windows
> machines.
Damn !! I now understand what happens.
Ok. What you can do is just to launch the script that you can find at
the top level :
http://svn.apache.org/viewcvs.cgi/directory/?root=Apache-SVN
it's *nix name is :
checkout-directory-new.sh
I think that you just have to change its name to
checkout-directory-new.bat
and execute it. It should work as the inner commands are just echo and
svn.
It will just check out the trunks.
Just let me know if you have problems with it.
--Emmanuel
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
Yes. LINUX is able to distinguish DnNParserTest.java from DNParserTest.java.
Windows is not. Unfortunately all of out development machines are Windows
machines.
Since I can't check out the whole project, I am not sure how I would check
out the HEAD of each subproject, as you suggest. How would I know what the
subprojects even are?
Thanks,
Jeff
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Monday, December 12, 2005 11:25 PM
To: Apache Directory Developers List
Subject: RE: [ApacheDS] checkout problem
Hi Jeff,
> The Windows svn command line client gets to the same point (see below),
> hangs up for a long time, and then gives an error. Could it be that there
> are two files checked in with very similar names?
I don't think so. I have tested the command line, and it worked ell on
my computer. I did it in a fresh directory ( I just created it for this
test). I also use Linux, and the last version of SVN.
What you can do is to check out the HEAD of each subproject, if it does
not work with the full project. Branches are not to be used at this
point.
--Emmanuel
RE: [ApacheDS] checkout problem
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Jeff,
> The Windows svn command line client gets to the same point (see below),
> hangs up for a long time, and then gives an error. Could it be that there
> are two files checked in with very similar names?
I don't think so. I have tested the command line, and it worked ell on
my computer. I did it in a fresh directory ( I just created it for this
test). I also use Linux, and the last version of SVN.
What you can do is to check out the HEAD of each subproject, if it does
not work with the full project. Branches are not to be used at this
point.
--Emmanuel
RE: [ApacheDS] checkout problem
Posted by Jeff Lansing <jl...@spawar.navy.mil>.
Emmanuel,
Thanks for the quick response.
The Windows svn command line client gets to the same point (see below),
hangs up for a long time, and then gives an error. Could it be that there
are two files checked in with very similar names?
Jeff
A directory\shared\ldap\branches\DN-refactoring\common\src
A directory\shared\ldap\branches\DN-refactoring\common\src\test
A directory\shared\ldap\branches\DN-refactoring\common\src\test\org
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name\LdapNameTest.ja
va
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name\LdapDNTest.java
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name\LdapRDNTest.jav
a
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name\DNParserTest.ja
va
A
directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\lda
p\common\name\DnParserTest.ja
va
svn: In directory
'directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\ld
ap\common\name'
svn: Can't copy
'directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\ld
ap\common\name\.sv
n\tmp\text-base\DnParserTest.java.svn-base' to
'directory\shared\ldap\branches\DN-refactoring\common\src\test\
org\apache\ldap\common\name\DnParserTest.java.tmp': The system cannot find
the file specified.
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Sent: Monday, December 12, 2005 4:20 PM
To: Apache Directory Developers List
Subject: Re: [ApacheDS]
Hi,
On Mon, 2005-12-12 at 15:16 -0800, Jeff Lansing wrote:
> Hi,
>
> We are using ApacheDS as an embedded LDAP in our web application as a way
to
> manage and persist configuration information. We have been using the three
> 0.9.3 jar files (core, main, and shared).
Thanks for using it !
> Recently we tried deploying on a more powerful 4-processor server, and we
> started running into serious problems that we hadn't seen before (see
below
> for stack trace). We found this:
> http://issues.apache.org/jira/browse/DIRLDAP-70
> which seemed to be very close to the problem we're seeing, so we thought
we
> could perhaps check out the source and make an intermediate build.
I think the problem is related to the JIRA issue you mentioned. It has
ben fixed (I hope;)
> Unfortunately, we couldn't check out the source from svn. The Tortoise
> client says this:
> ...
> Added:
>
C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\
> ldap\common\name\DnParserTest.java
> Error: In directory
>
'C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache
> \ldap\common\name'
Ok. This is a branch that is not part of the current project. I'm
refactoring some elements (the DnParser, actually).
However, you should not experience this kind of problem... What if you
just use command line ? :
svn co http://svn.apache.org/repos/asf/directory
> Thanks,
>
> Jeff
You are welcome !
-- Emmanuel
Re: [ApacheDS]
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi,
On Mon, 2005-12-12 at 15:16 -0800, Jeff Lansing wrote:
> Hi,
>
> We are using ApacheDS as an embedded LDAP in our web application as a way to
> manage and persist configuration information. We have been using the three
> 0.9.3 jar files (core, main, and shared).
Thanks for using it !
> Recently we tried deploying on a more powerful 4-processor server, and we
> started running into serious problems that we hadn't seen before (see below
> for stack trace). We found this:
> http://issues.apache.org/jira/browse/DIRLDAP-70
> which seemed to be very close to the problem we're seeing, so we thought we
> could perhaps check out the source and make an intermediate build.
I think the problem is related to the JIRA issue you mentioned. It has
ben fixed (I hope;)
> Unfortunately, we couldn't check out the source from svn. The Tortoise
> client says this:
> ...
> Added:
> C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache\
> ldap\common\name\DnParserTest.java
> Error: In directory
> 'C:\directory\shared\ldap\branches\DN-refactoring\common\src\test\org\apache
> \ldap\common\name'
Ok. This is a branch that is not part of the current project. I'm
refactoring some elements (the DnParser, actually).
However, you should not experience this kind of problem... What if you
just use command line ? :
svn co http://svn.apache.org/repos/asf/directory
> Thanks,
>
> Jeff
You are welcome !
-- Emmanuel