|
Home > Archive > Apache Directory Project > July 2006 > ApacheDS trunk: JDK1.4/unit test/normalisation issues
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ApacheDS trunk: JDK1.4/unit test/normalisation issues
|
|
| Norbet Reilly 2006-07-12, 1:11 am |
| Sorry, forgot to change subject before sending
On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi All,
>
> I haven't done an update to the latest SVN trunk for a while, so I
> thought I'd try one and see if I could take advantage of the speed
> improvements and enhanced LDIF reader support I've been reading about.
> Unfortunately things didn't go so smoothly...
>
> I use JDK1.4 (still the intended target platform, correct ?) as as
> with all of the updates I've done over the last six months or so,
> there were a number of build problems which I had to hack around. Two
> which I can remember were that the StringTools.DEFAULT_CHARSET_JDK_1_5
> constant can't be evaluated under JDK1.4 as it is assigned to a
> JDK1.5-specific method. Another was the LDAP class loader seems to
> refer to a JDK.1.5 compiled class.
>
> After fixing these I then saw a whole raft of unit test failures and
> decided there wasn't going to be time to investigate/resolve them all,
> the list is as follows:
>
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/HighestPrecedenceFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MaxValueCountFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MicroOperationFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificProtectedItemFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificUserClassFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/RestrictedByFilterTest.java.bak
> ./apacheds/core-unit/src/test/java/org/apache/directory/server/core/sp/LdapClassLoaderTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/common/support/FutureTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/transport/socket/nio/SocketBindTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/transport/vmpipe/VmPipeBindTest.java.bak
> ./shared/ldap/src/test/java/org/apache/directory/shared/ldap/ldif/LdifReaderTest.java.bak
>
> After moving these out of the way I had a working JDK1.4 build and
> needed to refactor my code to remove all LdapName refs and replace a
> number javax.naming.Name with LdapDN references: which was fine as I'd
> expected to need to do this work.
>
> However, when I attempted a sanity check reading a small LDIF file at
> ApacheDS start-up I encountered the most worrying set of problems. In
> about ten different places during start-up the core wasn't internally
> able to resolve the system partition (ou=system), as
> DefaultDirectoryPartitionNexus.getBackend(LdapDN) expects the provided
> DN to be normalised (<oid>=value), but was given an unormalised DN. At
> this stage I was quite a few hours into the update and decided to just
> hack in any number of .normalise()s to see if I could get the system
> to start-up.
>
> So my questions are:
> 1. JDK 1.4 is still the target platform, correct?
> 2. I know updating to the trunk usually involves an element of risk,
> but my experiences with this upgrade tend to suggest that the codebase
> currently has some pretty deep-running issues re LdapDN normalisation.
> It's possible that all the problems I saw were due to importing LDIF,
> but I strongly suspect otherwise. I'll do some other testing before
> rolling back to the snapshot I was using previously.
> 3. Am I the only one seeing these problems with unit
> tests/normalisation on the trunk? If not, is there a point in time
> when the stability of the trunk is expected to be restored.
> 4. I tried a few weeks back to move from the trunk back to the 1.0
> branch (which I'd prefer to use ultimately) but had the same JDK1.4
> compatibility issues reported above, so didn't want to invest a lot of
> time in back-porting my customisations until it looked closer to being
> frozen.
> 5. Which codebase would the comitters advise me to concentrate on,
> should I concentrate exclusively on the 1.0 branch and ignore the
> trunk for a while?
>
> Sorry if I sound a bit grumpy, the update led to a very late night.
>
> Any opinions gratefully accepted...
>
> Thanks
>
| |
| Norbet Reilly 2006-07-12, 1:11 am |
| On futher investigation, I may have contributed to the normalisation
problems as I had commented out the normalization service in the dim
distant past (as my interest is primarily using ApacheDS as custom
partition container).
Will comment it back in and uncomment my adhoc .normalise() calls and
report back
On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Sorry, forgot to change subject before sending
>
> On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
| |
| Norbet Reilly 2006-07-12, 1:11 am |
| My apologies, reinstating the normalisation service did remove the
problems resolving ou=system.
I now need to work out how to most efficiently get hold of the
un-normalised name I need to drive my custom partition mapping, will
most probably need to do:
LdapDN origDN = new LdapDN(dn.getUpName());
which doesn't seem that efficient. Would it make sense to have
LdapDN.normalise() cache the original value and make it available via
say LdapDN.getUpDN() to make this case more efficient. Any custom
partitions doing DN mapping will need access to the original text
rather then OIDs.
In particular I've already found LdapDN.getUpNamePrefix()/Suffix()
useful, is there any objection to making them public (they're
currently private)?
Thanks
| |
| Emmanuel Lecharny 2006-07-12, 7:11 am |
| Norbet Reilly a écrit :
> My apologies, reinstating the normalisation service did remove the
> problems resolving ou=system.
> I now need to work out how to most efficiently get hold of the
> un-normalised name I need to drive my custom partition mapping, will
> most probably need to do:
>
> LdapDN origDN = new LdapDN(dn.getUpName());
This will produce the very same DN. LdapDN stores two forms of the DN :
- a normalized DN form
- a user provided DN, and you get this form using dn.getUpName(), but
it's a String.
For instance, if you do :
LdapDN dn = new LdapDN( "Ou = SySteM" )
then
dn.toString() produce "ou=system"
and
dn.getUpName produce "Ou = SySteM"
The LdapDN.normalize() does something a little bit different : it
creates an internal form acceptable by the server, where all attribute
types are transformed into OIDs, and attribute values are mdified in
respect with their MatchingRule.
>
> which doesn't seem that efficient. Would it make sense to have
> LdapDN.normalise() cache the original value and make it available via
> say LdapDN.getUpDN() to make this case more efficient. Any custom
> partitions doing DN mapping will need access to the original text
> rather then OIDs.
Th eoriginal text is available thorugh LdapDN.getUpName().
>
> In particular I've already found LdapDN.getUpNamePrefix()/Suffix()
> useful, is there any objection to making them public (they're
> currently private)?
I didn't wrote thos classes, because there was a problem : doing so mean
you keep a track of each RDN position in UPName in order to truncate the
string correctly :
if UPname : dC = Example, Ou = coM
to get the prefix (ou=com), you will have to 'remember' the position of
the coma. We do not store that information.
If needed, we can extend LdapDN to do so.
However, if you do a getPrefix(), a new UPName will be created from each
RDN UPName stored (we also store UPnames for each RDN, but it may be
trimmed), so doing :
dn.getPrefix() produce : " Ou = coM" I guess.
Emmanuel
| |
| Norbet Reilly 2006-07-12, 7:11 am |
| I have used the one-liner above to restore the original (upName) DNs
for the moment, and it seemed as if my partition was populated with
all the desired data from the LDIF file.
My problem is now that JXplorer has trouble connecting to the started
server, because while doing queries at start-up some LdapDN values are
ending up associated with the "namingContexts" attribute inside a
org.apache.directory.shared.ldap.codec.search.SearchResultEntry, where
this class is expecting only String and binary values. The system
partition value was a string, but other partition values were LdapDNs.
I think the problem is in
DefaultDirectoryPartitionNexus.addContextPartition() where LdapDNs are
added as follows:
430 Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
431 namingContexts.add( partition.getUpSuffix() );
instead of
Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
namingContexts.add( partition.getUpSuffix().toString() );
The same issue impacts DefaultDirectoryPartitionNexus.removeContextPartition().
Making this change allowed me to connect with JXplorer, but I still
can't view the ApacheDS schema in the schema panel so I need to work
out what's happening there.
| |
| Norbet Reilly 2006-07-12, 7:11 am |
| I see this exception in the log, but I don't know what it means yet:
2006-07-12 18:19:59,437 30172 [LeaderFollowerThreadPool-1]
(com.ca.jch.PartitionLoaderService:307) ERROR - exception in
search('2.5.4.3=schema,2.5.4.11=system')
java.lang.IllegalArgumentException: Argument 'an_obj1' is null
at org.apache.directory.shared.ldap.util.BigIntegerComparator.compare(BigIntegerComparator.java:63)
at org.apache.directory.server.core.partition.impl.btree.IndexComparator$1.compare(IndexComparator.java:42)
at java.util.TreeMap.compare(TreeMap.java:1085)
at java.util.TreeMap.getEntry(TreeMap.java:345)
at java.util.TreeMap.containsKey(TreeMap.java:203)
at java.util.TreeSet.contains(TreeSet.java:195)
at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.has(JdbmTable.java:467)
at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.hasValue(JdbmIndex.java:387)
at org.apache.directory.server.core.partition.impl.btree.LeafEvaluator.evalPresence(LeafEvaluator.java:235)
at org.apache.directory.server.core.partition.impl.btree.LeafEvaluator.evaluate(LeafEvaluator.java:124)
at org.apache.directory.server.core.partition.impl.btree.ExpressionEvaluator.evaluate(ExpressionEvaluator.java:100)
at org.apache.directory.server.core.partition.impl.btree.ExpressionEnumerator$2.assertCandidate(ExpressionEnumerator.java:254)
at org.apache.directory.server.core.partition.impl.btree.IndexAssertionEnumeration.prefetch(IndexAssertionEnumeration.java:158)
at org.apache.directory.server.core.partition.impl.btree.IndexAssertionEnumeration.<init>(IndexAssertionEnumeration.java:63)
at org.apache.directory.server.core.partition.impl.btree.ExpressionEnumerator.enumConj(ExpressionEnumerator.java:267)
at org.apache.directory.server.core.partition.impl.btree.ExpressionEnumerator.enumerate(ExpressionEnumerator.java:131)
at org.apache.directory.server.core.partition.impl.btree.DefaultSearchEngine.search(DefaultSearchEngine.java:133)
at org.apache.directory.server.core.partition.impl.btree.BTreeDirectoryPartition.search(BTreeDirectoryPartition.java:257)
at org.apache.directory.server.core.partition.DefaultDirectoryPartitionNexus.search(DefaultDirectoryPartitionNexus.java:677)
at org.apache.directory.server.core.interceptor.InterceptorChain$1.search(InterceptorChain.java:133)
at org.apache.directory.server.core.interceptor.InterceptorChain$2.search(InterceptorChain.java:1257)
at org.apache.directory.server.core.subtree.SubentryService.search(SubentryService.java:200)
at org.apache.directory.server.core.interceptor.InterceptorChain$2.search(InterceptorChain.java:1257)
at org.apache.directory.server.core.schema.SchemaService.search(SchemaService.java:170)
at org.apache.directory.server.core.interceptor.InterceptorChain$2.search(InterceptorChain.java:1257)
at org.apache.directory.server.core.authn.AuthenticationService.search(AuthenticationService.java:390)
at org.apache.directory.server.core.interceptor.InterceptorChain$2.search(InterceptorChain.java:1257)
at org.apache.directory.server.core.normalization.NormalizationService.search(NormalizationService.java:226)
at org.apache.directory.server.core.interceptor.InterceptorChain$2.search(InterceptorChain.java:1257)
at com.ca.jch.PartitionLoaderService.search(PartitionLoaderService.java:718)
at org.apache.directory.server.core.interceptor.InterceptorChain.search(InterceptorChain.java:822)
at org.apache.directory.server.core.partition.DirectoryPartitionNexusProxy.search(DirectoryPartitionNexusProxy.java:478)
at org.apache.directory.server.core.partition.DirectoryPartitionNexusProxy.search(DirectoryPartitionNexusProxy.java:423)
at org.apache.directory.server.core.jndi.ServerDirContext.search(ServerDirContext.java:527)
at org.apache.directory.server.ldap.support.SearchHandler.messageReceived(SearchHandler.java:266)
at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:128)
at org.apache.directory.server.ldap. LdapProtocolProvider$LdapProtocolHandler
.messageReceived(LdapProtocolProvider.java:431)
at org.apache.mina.common.support.AbstractIoFilterChain$2.messageReceived(AbstractIoFilterChain.java:189)
at org.apache.mina.common.support.AbstractIoFilterChain. callNextMessageReceived(AbstractIoFilter
Chain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.LoggingFilter.messageReceived(LoggingFilter.java:87)
at org.apache.mina.common.support.AbstractIoFilterChain. callNextMessageReceived(AbstractIoFilter
Chain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:91)
at org.apache.mina.common.support.AbstractIoFilterChain. callNextMessageReceived(AbstractIoFilter
Chain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.thread.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:238)
at org.apache.mina.filter.thread.ThreadPoolFilter$ProcessEventsRunnable.run(ThreadPoolFilter.java:300)
at org.apache.mina.filter.thread.LeaderFollowersThreadPool$Worker.run(LeaderFollowersThreadPool.java:319)
| |
| Emmanuel Lecharny 2006-07-12, 7:11 am |
| Yeah, this was a bug that was fixed last week in optimization-trunk. I think
there is a JIRA for this one.
Sorry, I'm on my day job, so I can't really help atm...
On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I have used the one-liner above to restore the original (upName) DNs
> for the moment, and it seemed as if my partition was populated with
> all the desired data from the LDIF file.
>
> My problem is now that JXplorer has trouble connecting to the started
> server, because while doing queries at start-up some LdapDN values are
> ending up associated with the "namingContexts" attribute inside a
> org.apache.directory.shared.ldap.codec.search.SearchResultEntry, where
> this class is expecting only String and binary values. The system
> partition value was a string, but other partition values were LdapDNs.
> I think the problem is in
> DefaultDirectoryPartitionNexus.addContextPartition() where LdapDNs are
> added as follows:
>
> 430 Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
> 431 namingContexts.add( partition.getUpSuffix() );
>
> instead of
>
> Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
> namingContexts.add( partition.getUpSuffix().toString() );
>
> The same issue impacts
> DefaultDirectoryPartitionNexus.removeContextPartition().
>
> Making this change allowed me to connect with JXplorer, but I still
> can't view the ApacheDS schema in the schema panel so I need to work
> out what's happening there.
>
--
Cordialement,
Emmanuel Lécharny
| |
| Norbet Reilly 2006-07-12, 7:11 am |
| Thanks for the feedback Emmanuel.
Was the JIRA you mentioned in regard to a) the SearchResult exception
or b) the schema retrieval problem?
You asked about the unit test problems in an earlier email, they are
all outstanding as far as I am aware. I haven't tried building with
JDK1.5 and running with JDK1.4 but that's the only remaining point of
investigation.
| |
| Emmanuel Lecharny 2006-07-12, 1:11 pm |
| I think it was http://issues.apache.org/jira/browse/DIRSERVER-658
The searchRequest problem is under heavy investigation. It's a nasty bug in
the PDU decoding, and I have already spent around 12 hours trying to fix it,
but I still have one failing test. I hope I will kill it tonite 
Emmanuel
On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Thanks for the feedback Emmanuel.
>
> Was the JIRA you mentioned in regard to a) the SearchResult exception
> or b) the schema retrieval problem?
>
> You asked about the unit test problems in an earlier email, they are
> all outstanding as far as I am aware. I haven't tried building with
> JDK1.5 and running with JDK1.4 but that's the only remaining point of
> investigation.
>
--
Cordialement,
Emmanuel Lécharny
| |
| Norbet Reilly 2006-07-12, 1:11 pm |
| Nice working with the Tour De France on telly in the background
(although it is the wee hours in Australia...again).
The JIRA sounds exactly like the ClassCastException I saw (and also
nice to see the same proposed fix ;-)
By the "search request problem", do you mean the one causing a problem
when searching for the schema?
Thanks
| |
| Norbet Reilly 2006-07-12, 1:11 pm |
| About to sign off as the end of the first mountain stage draws to a close.
I seem to have all of my old functionality back again, except for the
issue about JXplorer failing when searching for the schema.
I tested out LdifReader on a:
changetype:modify
replace: attrid
case and it parsed the entry like a champion (once I moved it into a
separate file from the .ldif doing the initial population). However,
before I could crack open a celebratory beer this code in
LdifFileLoader decided to skip the entry:
if ( entry.isEntry() == false)
{
// If the entry is a modification, just skip it
continue;
}
Is the actual submission of the the entry into a modify request on the
drawing board, and if so, what is the rough expected timeframe?
Thanks
| |
| Alex Karasulu 2006-07-12, 1:11 pm |
| Norbet,
Sorry to catch you on the tail end of this thread. Looks like Emmanuel
took good care of you though.
Norbet Reilly wrote:
> About to sign off as the end of the first mountain stage draws to a close.
>
> I seem to have all of my old functionality back again, except for the
> issue about JXplorer failing when searching for the schema.
Can you confirm this problem with the stock/standalone ApacheDS server
in the optimization branch. If you still see it there I'll dive in.
> I tested out LdifReader on a:
>
> changetype:modify
> replace: attrid
>
> case and it parsed the entry like a champion (once I moved it into a
> separate file from the .ldif doing the initial population). However,
> before I could crack open a celebratory beer this code in
> LdifFileLoader decided to skip the entry:
>
> if ( entry.isEntry() == false)
> {
> // If the entry is a modification, just skip it
> continue;
> }
>
> Is the actual submission of the the entry into a modify request on the
> drawing board, and if so, what is the rough expected timeframe?
Sorry Norbet I'm failing to understand what you're trying to do here or
what you're asking. You want to have the LdifFileLoader handle other
changetypes?
Alex
| |
| Emmanuel Lecharny 2006-07-12, 1:11 pm |
| >
>
> Sorry Norbet I'm failing to understand what you're trying to do here or
> what you're asking. You want to have the LdifFileLoader handle other
> changetypes?
The new version of LdirReader handles all the RFC 2849, including change
operations.
But you can't mix add and change operation (I mean, add of entries, not add
of attributes) and I guess this is what Norbet want to do.
Alex
>
>
--
Cordialement,
Emmanuel Lécharny
| |
| Norbet Reilly 2006-07-13, 1:11 am |
| On 7/13/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> Norbet,
>
> Sorry to catch you on the tail end of this thread. Looks like Emmanuel
> took good care of you though.
>
No problem. Indeed he has!
> Norbet Reilly wrote:
>
> Can you confirm this problem with the stock/standalone ApacheDS server
> in the optimization branch. If you still see it there I'll dive in.
>
I am working off the 1.1 trunk, am I correct in thinking that the
optimization branch is 1.0 based? I have a whole raft of custom
changes I've made to ApacheDS, and thought I'd wait for 1.0 to be
released before backporting them to it.
I'm checking it out anyway, and will test out whether the schema
problem occurs when it is a) vanilla and b) has my extra .schema file
encorporated into the Maven build.
Actually, I wasn't able to "svn checkout
https://svn.apache.org/repos/asf/di...mization-trunks"
as it failed when it tried to get to get the last module
(releases/mina/0.9.4) saying "407 Proxy Authentication Required
(http://svn.apache.org)." I presume what works for the other modules
is supposed to work for MINA too?
>
> Sorry Norbet I'm failing to understand what you're trying to do here or
> what you're asking. You want to have the LdifFileLoader handle other
> changetypes?
>
That is what I was hoping for.
I currently have a raft of LDAP ADD sanity tests for my custom
partition support, so I bootstrap the directory by placing one or more
of these .ldifs into the test.ldif directory and starting ApacheDS up.
There are a number of other cases which I'd like to test (e.g. MODIFYs
(op=ADD/REPLACE/REMOVE) and DELETEs in the same way, which was one of
the primary drivers behind my decision to upgrade to the latest 1.1
trunk. I have been using some manual tests via JXplorer, but there are
many requests I'm interested that it can't formulate (e.g. MODIFY on
multi-valued attribute, with modification op=REPLACE). I'm going to
work on a comprehensive automated test suite shortly, but wanted easy
to execute sanity test script which I can use to drive my debugging
sessions in the interim.
Other then .ldif files, is there another mechanism to send scripted
LDAP requests to a running ApacheDS?
Thanks
| |
| Norbet Reilly 2006-07-13, 1:11 am |
| Note in regard to the latter point, I tried importing a MODIFY .ldif
into JXplorer but when I submitted it it just sent the special
attributes like "changetype: modify" as normal attributes in an ADD
request instead of sending a MODIFY request as I desired.
| |
| Emmanuel Lecharny 2006-07-13, 7:11 am |
| Norbet Reilly a écrit :
> <snip/>
> Actually, I wasn't able to "svn checkout
> https://svn.apache.org/repos/asf/di...mization-trunks"
>
Just try :
http://svn.apache.org/repos/asf/dir...mization-trunks
(do not use https but http : https is for committers, it's slower and
it's eating server CPU)
> as it failed when it tried to get to get the last module
> (releases/mina/0.9.4) saying "407 Proxy Authentication Required
> (http://svn.apache.org)." I presume what works for the other modules
> is supposed to work for MINA too?
Yep, but use http. (Alex, the external stuff may sucks the way we did it
- http instead of https-, btw)
Not sure it will fix your problem...
<snip/>
Emmanuel
| |
| Norbet Reilly 2006-07-13, 7:11 am |
| Thanks, will try.
Also Emmanuel, do you have any thoughts regarding LdifFileLoader
supporting changetypes other then "modify" (refer to my last email to
Alex).
One other note, it is useful in my case to know whether a LdapDN has
been normalised or not as I'm interested in their getUpName() version
but due to an inheritance hierachy I don't know implicitly whether I
have previously done "dn = new LdapDN(dn.getUpName())" to undo the
..normalize() called by the NormalizationService. Hence I added a
boolean and a getter isNormalized() to my version of LdapDN, where the
boolean is set to true in .normalize(). Do you have any objections to
committing this minor change to the official version of LdapDN?
| |
| Norbet Reilly 2006-07-13, 7:11 am |
| Actually MINA was the odd external out in the optimization-trunks (it
had http: whereas all others had https. By changing it to https: I
could then check-out MINA, although I have idea why. From your
previous posting it sounds like an unfortunate result for the SVN
server's CPU...
| |
| Norbet Reilly 2006-07-13, 7:11 am |
| when i try and "mvn install" the vanilla opt branch using JDK1.5 I see:
a) LdifReaderTest fails
b) I get this fatal maven exception in "Building ApacheDS Core Plugin (Maven 2)"
ANTLR Parser Generator Version 2.7.4 1989-2004 jGuru.com
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang
/String;)V
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImp
lementation(Ljava/lang/String;)V
at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
tor. extractParameters(JavaMojoDescriptorExtr
actor.java:431)
at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
tor. createMojoDescriptor(JavaMojoDescriptorE
xtractor.java:303)
at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
tor.execute(JavaMojoDescriptorExtractor.java:500)
at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePlug
inDescriptor(DefaultMojoScanner.java:69)
at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(Abstract
GeneratorMojo.java:99)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:412)
I'm using maven 2.0.4...
| |
| Ersin Er 2006-07-13, 7:11 am |
| That's a problem we have started to have yesterday and it's probably
because of an updated maven plug-in. Our hands are bound about it.
--
Ersin
Norbet Reilly wrote:
> when i try and "mvn install" the vanilla opt branch using JDK1.5 I see:
> a) LdifReaderTest fails
> b) I get this fatal maven exception in "Building ApacheDS Core Plugin
> (Maven 2)"
> ANTLR Parser Generator Version 2.7.4 1989-2004 jGuru.com
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang
> /String;)V
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.plugin.descriptor.Parameter.setImp
> lementation(Ljava/lang/String;)V
> at
> org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
> tor. extractParameters(JavaMojoDescriptorExtr
actor.java:431)
> at
> org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
> tor. createMojoDescriptor(JavaMojoDescriptorE
xtractor.java:303)
> at
> org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtrac
> tor.execute(JavaMojoDescriptorExtractor.java:500)
> at
> org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePlug
> inDescriptor(DefaultMojoScanner.java:69)
> at
> org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(Abstract
> GeneratorMojo.java:99)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:412)
>
> I'm using maven 2.0.4...
>
| |
| Emmanuel Lecharny 2006-07-13, 7:11 am |
| Now, I have another error. I think maven is totally out of control. Here is
what I get (maven -e):
[INFO] Using default encoding to copy filtered resources.
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error copying resources
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error copying
resources
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error copying
resources
at org.apache.maven.plugin.resources.ResourcesMojo.copyResources(
ResourcesMojo.java:187)
at org.apache.maven.plugin.resources.ResourcesMojo.execute(
ResourcesMojo.java:100)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: sun.io.MalformedInputException
at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:278)
at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(
StreamDecoder.java:314)
at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java
:364)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:250)
at java.io.InputStreamReader.read(InputStreamReader.java:212)
at java.io.BufferedReader.fill(BufferedReader.java:157)
at java.io.BufferedReader.read(BufferedReader.java:178)
at
org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(
InterpolationFilterReader.java:201)
at
org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(
InterpolationFilterReader.java:201)
at
org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(
InterpolationFilterReader.java:201)
at
org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(
InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:143)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at org.apache.maven.plugin.resources.ResourcesMojo.copyFile(
ResourcesMojo.java:269)
at org.apache.maven.plugin.resources.ResourcesMojo.copyResources(
ResourcesMojo.java:183)
... 19 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 11 seconds
[INFO] Finished at: Thu Jul 13 12:04:37 CEST 2006
[INFO] Final Memory: 12M/50M
[INFO]
------------------------------------------------------------------------
On 7/13/06, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> That's a problem we have started to have yesterday and it's probably
> because of an updated maven plug-in. Our hands are bound about it.
>
> --
> Ersin
>
> Norbet Reilly wrote:
> (Ljava/lang
>
>
--
Cordialement,
Emmanuel Lécharny
| |
| Norbet Reilly 2006-07-13, 7:11 am |
| Yeah, I'm afraid I agree totally with suspicion about the maven
"auto-update" concept and had a very similar rant about it on the list
previously.
In my mind it's analogous to revision control with Subversion, no one
would ever accept a revision control system that "pushed" changes onto
your working directory. You wait until a moment in time where you
prepared to take a risk, and then you explicitly ask for an update.
It's completely bogus for a system to push random untrusted changes
onto you every time you do a build.
At any rate, I'll wait until the maven plugin problem is resolved and
try querying the ADS schema via JXplorer then...
ciao
| |
| Dale Peakall 2006-07-13, 7:11 am |
| Norbet Reilly wrote:
> Yeah, I'm afraid I agree totally with suspicion about the maven
> "auto-update" concept and had a very similar rant about it on the list
> previously.
>
> In my mind it's analogous to revision control with Subversion, no one
> would ever accept a revision control system that "pushed" changes onto
> your working directory. You wait until a moment in time where you
> prepared to take a risk, and then you explicitly ask for an update.
> It's completely bogus for a system to push random untrusted changes
> onto you every time you do a build.
>
> At any rate, I'll wait until the maven plugin problem is resolved and
> try querying the ADS schema via JXplorer then...
You can mitigate the problems by setting the <updatePolicy> on the
plugin repository to never. This won't help people if the initial
version they retrieve from the maven repository is bust, but will
prevent people with working copies getting a broken version later.
| |
| Emmanuel Lecharny 2006-07-13, 7:11 am |
| Thanks for the trick.
But I think that plugins should be linked with a specific maven version (ie,
with mvn 2.0.4, you get plugin surefire version X, etc), unless you choose
to use newer updates. After all, this is how linux is working, so I don't
think it's bad logic And this <updatePolicy> parameter should be set to
never by default. Enough rant, let's go back to work ;)
Emmanuel
On 7/13/06, Dale Peakall <dale-tpv/Pf3PN0RBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Norbet Reilly wrote:
>
> You can mitigate the problems by setting the <updatePolicy> on the
> plugin repository to never. This won't help people if the initial
> version they retrieve from the maven repository is bust, but will
> prevent people with working copies getting a broken version later.
>
>
--
Cordialement,
Emmanuel Lécharny
| |
| Alex Karasulu 2006-07-13, 1:11 pm |
| Norbet Reilly wrote:
> Note in regard to the latter point, I tried importing a MODIFY .ldif
> into JXplorer but when I submitted it it just sent the special
> attributes like "changetype: modify" as normal attributes in an ADD
> request instead of sending a MODIFY request as I desired.
Hmmm not good at all. You might want to give ldapbrowser a try to see
if that will work or just use the ldapmodify client.
Alex
| |
| Norbet Reilly 2006-07-15, 1:11 am |
| Just reporting back on my experiences with the vanilla optimization branch:
1. should the LdifReaderTest.java unit test be disabled until it
passes, or is it being left present but broken intentionally? It's
just that every time I SVN update I have to remember to ditch this
file or my "mvn install" will break.
2. When I started up ADS using the default log4j.properties I got an
NPE when trying to bind as the admin user from LdapResult.java:549
(started by a debug message .toString()) because it incorrectly
assumed matchedDN will never be null, which appears to be false for
bind responses:
[14:55:16] DEBUG [org.apache.directory.shared.asn1.ber.Asn1Decoder] - <<<=======
===================================
[14:55:16] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] - Decoding
the PDU :
[14:55:16] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] - 0x30 0x2
5 0x02 0x01 0x01 0x60 0x20 0x02 0x01 0x03 0x04 0x13 0x75 0x69 0x64 0x3D 0x61 0x6
4 0x6D 0x69 0x6E 0x2C 0x6F 0x75 0x3D 0x73 0x79 0x73 0x74 0x65 0x6D 0x80 0x06 0x7
3 0x65 0x63 0x72 0x65 0x74
[14:55:16] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] - Decoded
LdapMessage : LdapMessage
message Id : 1
BindRequest
Version : '3'
Name : 'uid=admin,ou=system'
Simple authentication : '[B@1ae90c'
[14:55:16] DEBUG [org.apache.directory.shared.ldap.codec.TwixTransformer] - Tran
sforming LdapMessage <1, BIND_REQUEST> from Twix to Snickers.
[14:55:16] DEBUG [org.apache.directory.server.core.partition.DefaultDirectoryPar
titionNexus] - Check if DN '0.9.2342.19200300.100.1.1=admin,2.5.4.11=system' exi
sts.
[14:55:16] DEBUG [org.apache.directory.shared.ldap.codec.TwixTransformer] - Tran
sforming message type MessageTypeEnum[BINDRESPONSE=1073741825]
[14:55:16] WARN [org.apache.directory.server.ldap.LdapProtocolProvider$LdapProto
colHandler] - [/127.0.0.1:1436] Unexpected exception forcing session to close: s
ending disconnect notice to client.
org.apache.mina.filter.codec.ProtocolEncoderException: java.lang.NullPointerExce
ption
at org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(Protocol
CodecFilter.java:237)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilt
erWrite(AbstractIoFilterChain.java:583)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(Abst
ractIoFilterChain.java:51)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filt
erWrite(AbstractIoFilterChain.java:799)
at org.apache.mina.common.support.AbstractIoFilterChain$2.filterWrite(Ab
stractIoFilterChain.java:212)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilt
erWrite(AbstractIoFilterChain.java:583)
at org.apache.mina.common.support.AbstractIoFilterChain.filterWrite(Abst
ractIoFilterChain.java:574)
at org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketS
essionImpl.java:176)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java
:136)
at org.apache.directory.server.ldap.support.BindHandler.messageReceived(
BindHandler.java:145)
at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(Demux
ingIoHandler.java:128)
at org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHan
dler.messageReceived(LdapProtocolProvider.java:399)
at org.apache.mina.common.support.AbstractIoFilterChain$2.messageReceive
d(AbstractIoFilterChain.java:188)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageR
eceived(AbstractIoFilterChain.java:501)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(Abst
ractIoFilterChain.java:51)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.mess
ageReceived(AbstractIoFilterChain.java:787)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(Prot
ocolCodecFilter.java:187)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageR
eceived(AbstractIoFilterChain.java:501)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(Abst
ractIoFilterChain.java:51)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.mess
ageReceived(AbstractIoFilterChain.java:787)
at org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter
..java:718)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPo
olFilter.java:474)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.j
ava:429)
Caused by: java.lang.NullPointerException
at org.apache.directory.shared.ldap.codec.LdapResult.toString(LdapResult
..java:549)
at org.apache.directory.shared.ldap.codec.LdapResponse.toString(LdapResp
onse.java:129)
at org.apache.directory.shared.ldap.codec.bind.BindResponse.toString(Bin
dResponse.java:173)
at org.apache.directory.shared.ldap.codec.LdapMessage.toString(LdapMessa
ge.java:658)
at java.lang.String.valueOf(String.java:2577)
at java.lang.StringBuffer.append(StringBuffer.java:220)
at org.apache.directory.shared.ldap.codec.TwixTransformer.transform(Twix
Transformer.java:1195)
at org.apache.directory.shared.ldap.message.MessageEncoder.encode(Messag
eEncoder.java:128)
at org.apache.mina.filter.codec.asn1.Asn1CodecEncoder.encode(Asn1CodecEn
coder.java:55)
at org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(Protocol
CodecFilter.java:226)
... 22 more
3. After fixing this NPE I still can't query the ADS schema by going
to JXplorer's schema panel after performing a successful bind. I don't
get the same assertion failure observed on the 1.1 main trunk, but I
do get the same result that JXplorer says "reading..." forever and no
schema information is displayed. Hence I think the same root problem
exists in both the optimization trunks and 1.1 trunk.
I'll open a JIRA.
Thanks
|
|
|
|
|