You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org> on 2005/01/30 15:27:17 UTC
[jira] Created: (DIRLDAP-28) ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
-------------------------------------------------------------------------
Key: DIRLDAP-28
URL: http://issues.apache.org/jira/browse/DIRLDAP-28
Project: Directory LDAP
Type: Bug
Components: Snickers Codec Provider
Versions: 0.8.0
Environment: Not relevant
Reporter: Emmanuel Lecharny
Assigned to: Alex Karasulu
Priority: Blocker
I get a ClassCast exception while running LdapSearch main :
java.lang.ClassCastException
at org.apache.ldap.common.berlib.asn1.SnickersEncoder$OutputCallback.encodeOccurred(SnickersEncoder.java:177)
at org.apache.asn1.codec.stateful.AbstractStatefulEncoder.encodeOccurred(AbstractStatefulEncoder.java:130)
at org.apache.asn1.ber.TupleEncodingVisitor.flush(TupleEncodingVisitor.java:173)
at org.apache.ldap.common.berlib.asn1.encoder.SnickersLdapEncoder.encode(SnickersLdapEncoder.java:209)
at org.apache.ldap.common.berlib.asn1.SnickersEncoder.encodeBlocking(SnickersEncoder.java:66)
at org.apache.ldap.common.message.MessageEncoder.encodeBlocking(MessageEncoder.java:90)
at org.apache.ldap.clients.LdapBind.bind(LdapBind.java:350)
at org.apache.ldap.clients.LdapSearch.main(LdapSearch.java:408)
public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
try
{
channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
Substituing those lines to the one that cause the exception seems to correct it :
public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
try
{
//channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
ByteBuffer[] buffers = (ByteBuffer[])encoded;
// int nbWritten = 0; // for debug sake
for (int i=0; i<buffers.length; i++) {
//nbWritten += channel.write(buffers[i]);
channel.write(buffers[i]);
}
// System.out.println("Bytes written (" + nbWritten + ") :");
...
No more exception, then, but, as far as I went, it does not help the whole thing to work correctly. I do not receive any answer from my favorite OpenLdap server. I'm currently checking the PDU to see if it's FUBR or not (ethereal to the rescue). Takes time...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: Ldap clients
Posted by Vincent Tence <vt...@videotron.ca>.
> NB : bloody Babel tower! It takes me so looooong to write what I have in
> mind in english (and, for sure, a trully bad english :(
I know how it feels ;-) And you're doing good!
- Vincent
Re: Ldap clients
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>The point is that those clients are pretty minimalist actually. The
>question is : do we need them or not?
>
>
The clients may still come in handy for simple manned tests. My
thinking here is sometimes users need simple command line clients the
same way they get OpenLDAP clients. It's expected and the clients are
thin so it completes the picture.
>Talking about performance and protocol tests, that are two different
>subject:
>1) performance : JMeter is - IMHO - a perfect tool to test the server.
>I've used it a few years ago, and it gives good results. I don't like to
>re-invent the wheel (well, from time to time, that could be an
>option ;-), so I would +1 for it against writing specific load test
>tool.
>
>
Cool I agree if we can use it we should. However I always thought it was
an http based tool. The ldap-common library pretty much can be used to
teach JMeter LDAP if we need to do that at all. This is going to be
cool if we can make it work with all the protocols in our stack. This
way we can tune the heck out of MINA. Also we can really see if SEDA
does pay off at a certain level of load.
>2) protocol tests : client are really good to start with, but they need
>some add-ons (automatic tests cases, and so on). But there are others
>options : using a Ldap browser to test EVE, for instance, in combinaison
>with Ethereal, or ldapXXXX scripts, wich can be automated.
>
>
Right I use a combination of Ethereal and LDAP browsers like JExplorer,
GQ and sometimes just plain old code that uses the SUN JNDI LDAP
provider et cetera.
>On the other side, it could be cool to deliver a whole package : EVE +
>JNDI providers + direct clients. Sure, clients script could be wrote
>using a JNDI LDAP provider, but is it necessary? And what about querying
>other servers (replication/synchronisation in mind)?
>
>
Right the clients give us a clean room where we can test specific
features like controls without asking if something is wrong with the SUN
LDAP JNDI provider. It's on less ? to deal with. Also there are things
you just can't do with the SUN LDAP JNDI provider that can be added to
these clients. However this is not that much of a big deal.
>So actually, I've finished with ldap.clients (except standalone, which
>could be put aside), and it compiles. It does not work, because of the
>digester/encoder/decoder problem, but this is NOT a regression.
>
Hmmm so if I understand you the bug did exist before? I still need to
get a fix in for this I guess. Why don't you do this - tar up the code
and don't bother with the diff. The code is tiny and we can just flat
out replace what is there.
>valon is no more needed.
>
>
>
Great!
>So the next step could be the encoder/decoder stuff, with those steps :
>1) eradicate the bugs
>2) rethinking the encoder/decoder things (keeping the actuals one for
>the moment, because it exists !)
>
>
Want me to create a branch to work in just for us?
>3) rewrite it.
>
>
This might even be better. However we can still do this in a branch.
We just start refactoring code and taking what we can use. Then we can
just swap out the trunk for the branch rather than attempt a merge.
However I think external interfaces will also change too. This IMO is
ok nothing here is 1.0 and we can change the code that depends on these
codec APIs.
>And maybe improve the clients to accept the same syntax and options than
>OpendLdap scripts.
>
>
Yeah good call. We should stick to using all the same switches for sure.
>What do you think?
>
>
>
This is good, very good. I just need to start looking at the code. It
might have been good to do a few of the clients at a time but no worries.
>btw, do I push the client code through Jira? A svn diff is 3036 lines
>long...
>
>
Just tarball it up and put it into an attachment. I have the feeling
the actual classes themselves rather than the diff will be smaller so I
can just overlay them rather than patch em.
>NB : bloody Babel tower! It takes me so looooong to write what I have in
>mind in english (and, for sure, a trully bad english :(
>
>
Nahhh your just fine and thanks for the hard work.
>Le mardi 01 février 2005 à 16:33 -0500, Alex Karasulu a écrit :
>
>
>>Emmanuel Lecharny wrote:
>>
>>
>>
>>>Hi,
>>>
>>>is there any functionnal difference between :
>>>org.apache.ldap.clients.standalone
>>>and
>>>org.apache.ldap.clients
>>>?
>>>
>>>Does some unit tests exist for those classes? I don't think so, but I
>>>may be wrong.
>>>
>>>What about org.apache.ldap.clients.ldaptest : is it a kind of UI to test
>>>Ldap clients operations? I've launched it after having crafted a minimal
>>>XML configuration file, but I can't Add tests cases. Any clue?
>>>
>>>
>>>
>>>
>>>
>>Emmanuel, your guess is as good as mine. It's been over a year and a
>>half since I looked at the client code.
>>
>>Jeff Machols (primary guy who was working client code) and I started
>>talking about building an LDAP test suite for both performance and for
>>protocol testing. We were going to use it to collect information about
>>how well ApacheDS performs in relation to other servers. I think some
>>of the XML work was to design test cases around client requests for this
>>purpose. Perhaps if Jeff is listening he can shed some light on this.
>>
>>The stuff in client top pkg look almost exactly the same as the
>>standalone stuff. I have no idea why Jeff may have structured it this
>>way. Perhaps he was going to do some refactoring but descided not to
>>after copying stuff into a new package. That too does not make sense
>>since he would have copied the trunk to branches.
>>
>>Here's my recommendation to you. If you want to totally revamp this go
>>right ahead. Take what ever you can use from it and we'll just replace
>>the trunk with new code (granted if it passes review which I think it
>>will).
>>
>>Is this preferrable for you?
>>
>>Cheers,
>>Alex
>>
>>
>>
>>
>>
>
>
>
>
>
Re: Ldap clients
Posted by Emmanuel Lecharny <el...@iktek.com>.
The point is that those clients are pretty minimalist actually. The
question is : do we need them or not?
Talking about performance and protocol tests, that are two different
subject:
1) performance : JMeter is - IMHO - a perfect tool to test the server.
I've used it a few years ago, and it gives good results. I don't like to
re-invent the wheel (well, from time to time, that could be an
option ;-), so I would +1 for it against writing specific load test
tool.
2) protocol tests : client are really good to start with, but they need
some add-ons (automatic tests cases, and so on). But there are others
options : using a Ldap browser to test EVE, for instance, in combinaison
with Ethereal, or ldapXXXX scripts, wich can be automated.
On the other side, it could be cool to deliver a whole package : EVE +
JNDI providers + direct clients. Sure, clients script could be wrote
using a JNDI LDAP provider, but is it necessary? And what about querying
other servers (replication/synchronisation in mind)?
So actually, I've finished with ldap.clients (except standalone, which
could be put aside), and it compiles. It does not work, because of the
digester/encoder/decoder problem, but this is NOT a regression. And
valon is no more needed.
So the next step could be the encoder/decoder stuff, with those steps :
1) eradicate the bugs
2) rethinking the encoder/decoder things (keeping the actuals one for
the moment, because it exists !)
3) rewrite it.
And maybe improve the clients to accept the same syntax and options than
OpendLdap scripts.
What do you think?
btw, do I push the client code through Jira? A svn diff is 3036 lines
long...
NB : bloody Babel tower! It takes me so looooong to write what I have in
mind in english (and, for sure, a trully bad english :(
Le mardi 01 février 2005 à 16:33 -0500, Alex Karasulu a écrit :
> Emmanuel Lecharny wrote:
>
> >Hi,
> >
> >is there any functionnal difference between :
> >org.apache.ldap.clients.standalone
> >and
> >org.apache.ldap.clients
> >?
> >
> >Does some unit tests exist for those classes? I don't think so, but I
> >may be wrong.
> >
> >What about org.apache.ldap.clients.ldaptest : is it a kind of UI to test
> >Ldap clients operations? I've launched it after having crafted a minimal
> >XML configuration file, but I can't Add tests cases. Any clue?
> >
> >
> >
> Emmanuel, your guess is as good as mine. It's been over a year and a
> half since I looked at the client code.
>
> Jeff Machols (primary guy who was working client code) and I started
> talking about building an LDAP test suite for both performance and for
> protocol testing. We were going to use it to collect information about
> how well ApacheDS performs in relation to other servers. I think some
> of the XML work was to design test cases around client requests for this
> purpose. Perhaps if Jeff is listening he can shed some light on this.
>
> The stuff in client top pkg look almost exactly the same as the
> standalone stuff. I have no idea why Jeff may have structured it this
> way. Perhaps he was going to do some refactoring but descided not to
> after copying stuff into a new package. That too does not make sense
> since he would have copied the trunk to branches.
>
> Here's my recommendation to you. If you want to totally revamp this go
> right ahead. Take what ever you can use from it and we'll just replace
> the trunk with new code (granted if it passes review which I think it
> will).
>
> Is this preferrable for you?
>
> Cheers,
> Alex
>
>
>
Re: Ldap clients
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>Hi,
>
>is there any functionnal difference between :
>org.apache.ldap.clients.standalone
>and
>org.apache.ldap.clients
>?
>
>Does some unit tests exist for those classes? I don't think so, but I
>may be wrong.
>
>What about org.apache.ldap.clients.ldaptest : is it a kind of UI to test
>Ldap clients operations? I've launched it after having crafted a minimal
>XML configuration file, but I can't Add tests cases. Any clue?
>
>
>
Emmanuel, your guess is as good as mine. It's been over a year and a
half since I looked at the client code.
Jeff Machols (primary guy who was working client code) and I started
talking about building an LDAP test suite for both performance and for
protocol testing. We were going to use it to collect information about
how well ApacheDS performs in relation to other servers. I think some
of the XML work was to design test cases around client requests for this
purpose. Perhaps if Jeff is listening he can shed some light on this.
The stuff in client top pkg look almost exactly the same as the
standalone stuff. I have no idea why Jeff may have structured it this
way. Perhaps he was going to do some refactoring but descided not to
after copying stuff into a new package. That too does not make sense
since he would have copied the trunk to branches.
Here's my recommendation to you. If you want to totally revamp this go
right ahead. Take what ever you can use from it and we'll just replace
the trunk with new code (granted if it passes review which I think it
will).
Is this preferrable for you?
Cheers,
Alex
Ldap clients
Posted by Emmanuel Lecharny <el...@iktek.com>.
Hi,
is there any functionnal difference between :
org.apache.ldap.clients.standalone
and
org.apache.ldap.clients
?
Does some unit tests exist for those classes? I don't think so, but I
may be wrong.
What about org.apache.ldap.clients.ldaptest : is it a kind of UI to test
Ldap clients operations? I've launched it after having crafted a minimal
XML configuration file, but I can't Add tests cases. Any clue?
Thanx !
Emmanuel
Re: [jira] Created: (DIRLDAP-28) ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
Posted by Alex Karasulu <ao...@bellsouth.net>.
Shoot I was afraid someone would start using those crappy clients. I
and a fellow named Jeff worked on em. I could not maintain them and the
server at the same time so I left it up to Jeff. Jeff has not been
around for a while. Anyhow these clients are looking for some
attention. #1 on the list is taking anything Avalon out of them.
Anyone interested? Emmanuel?
Cheers,
Alex
Emmanuel Lecharny (JIRA) wrote:
>ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
>-------------------------------------------------------------------------
>
> Key: DIRLDAP-28
> URL: http://issues.apache.org/jira/browse/DIRLDAP-28
> Project: Directory LDAP
> Type: Bug
> Components: Snickers Codec Provider
> Versions: 0.8.0
> Environment: Not relevant
> Reporter: Emmanuel Lecharny
> Assigned to: Alex Karasulu
> Priority: Blocker
>
>
>I get a ClassCast exception while running LdapSearch main :
>java.lang.ClassCastException
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder$OutputCallback.encodeOccurred(SnickersEncoder.java:177)
> at org.apache.asn1.codec.stateful.AbstractStatefulEncoder.encodeOccurred(AbstractStatefulEncoder.java:130)
> at org.apache.asn1.ber.TupleEncodingVisitor.flush(TupleEncodingVisitor.java:173)
> at org.apache.ldap.common.berlib.asn1.encoder.SnickersLdapEncoder.encode(SnickersLdapEncoder.java:209)
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder.encodeBlocking(SnickersEncoder.java:66)
> at org.apache.ldap.common.message.MessageEncoder.encodeBlocking(MessageEncoder.java:90)
> at org.apache.ldap.clients.LdapBind.bind(LdapBind.java:350)
> at org.apache.ldap.clients.LdapSearch.main(LdapSearch.java:408)
>
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
>
>Substituing those lines to the one that cause the exception seems to correct it :
>
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> //channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
> ByteBuffer[] buffers = (ByteBuffer[])encoded;
>
> // int nbWritten = 0; // for debug sake
>
> for (int i=0; i<buffers.length; i++) {
> //nbWritten += channel.write(buffers[i]);
> channel.write(buffers[i]);
> }
>
> // System.out.println("Bytes written (" + nbWritten + ") :");
> ...
>
>No more exception, then, but, as far as I went, it does not help the whole thing to work correctly. I do not receive any answer from my favorite OpenLdap server. I'm currently checking the PDU to see if it's FUBR or not (ethereal to the rescue). Takes time...
>
>
>
[jira] Commented: (DIRLDAP-28) ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-28?page=comments#action_58493 ]
Alex Karasulu commented on DIRLDAP-28:
--------------------------------------
These have been committed and Avalon deps have been removed. New deps for Log4j and Commons CLI were introduced. I guess this is going to piss Gump off.
> ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
> -------------------------------------------------------------------------
>
> Key: DIRLDAP-28
> URL: http://issues.apache.org/jira/browse/DIRLDAP-28
> Project: Directory LDAP
> Type: Bug
> Components: Snickers Codec Provider
> Versions: 0.8.0
> Environment: Not relevant
> Reporter: Emmanuel Lecharny
> Assignee: Alex Karasulu
> Priority: Blocker
> Attachments: clients.tar.gz
>
> I get a ClassCast exception while running LdapSearch main :
> java.lang.ClassCastException
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder$OutputCallback.encodeOccurred(SnickersEncoder.java:177)
> at org.apache.asn1.codec.stateful.AbstractStatefulEncoder.encodeOccurred(AbstractStatefulEncoder.java:130)
> at org.apache.asn1.ber.TupleEncodingVisitor.flush(TupleEncodingVisitor.java:173)
> at org.apache.ldap.common.berlib.asn1.encoder.SnickersLdapEncoder.encode(SnickersLdapEncoder.java:209)
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder.encodeBlocking(SnickersEncoder.java:66)
> at org.apache.ldap.common.message.MessageEncoder.encodeBlocking(MessageEncoder.java:90)
> at org.apache.ldap.clients.LdapBind.bind(LdapBind.java:350)
> at org.apache.ldap.clients.LdapSearch.main(LdapSearch.java:408)
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
> Substituing those lines to the one that cause the exception seems to correct it :
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> //channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
> ByteBuffer[] buffers = (ByteBuffer[])encoded;
>
> // int nbWritten = 0; // for debug sake
>
> for (int i=0; i<buffers.length; i++) {
> //nbWritten += channel.write(buffers[i]);
> channel.write(buffers[i]);
> }
>
> // System.out.println("Bytes written (" + nbWritten + ") :");
> ...
> No more exception, then, but, as far as I went, it does not help the whole thing to work correctly. I do not receive any answer from my favorite OpenLdap server. I'm currently checking the PDU to see if it's FUBR or not (ethereal to the rescue). Takes time...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (DIRLDAP-28) ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-28?page=history ]
Emmanuel Lecharny updated DIRLDAP-28:
-------------------------------------
Attachment: clients.tar.gz
standelone package DOES NOT COMPILE actually. I don't think that this module is usefull anyway...
> ClassCast excpetion in org.apache.ldap.common.berlib.asn1.SnickersEncoder
> -------------------------------------------------------------------------
>
> Key: DIRLDAP-28
> URL: http://issues.apache.org/jira/browse/DIRLDAP-28
> Project: Directory LDAP
> Type: Bug
> Components: Snickers Codec Provider
> Versions: 0.8.0
> Environment: Not relevant
> Reporter: Emmanuel Lecharny
> Assignee: Alex Karasulu
> Priority: Blocker
> Attachments: clients.tar.gz
>
> I get a ClassCast exception while running LdapSearch main :
> java.lang.ClassCastException
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder$OutputCallback.encodeOccurred(SnickersEncoder.java:177)
> at org.apache.asn1.codec.stateful.AbstractStatefulEncoder.encodeOccurred(AbstractStatefulEncoder.java:130)
> at org.apache.asn1.ber.TupleEncodingVisitor.flush(TupleEncodingVisitor.java:173)
> at org.apache.ldap.common.berlib.asn1.encoder.SnickersLdapEncoder.encode(SnickersLdapEncoder.java:209)
> at org.apache.ldap.common.berlib.asn1.SnickersEncoder.encodeBlocking(SnickersEncoder.java:66)
> at org.apache.ldap.common.message.MessageEncoder.encodeBlocking(MessageEncoder.java:90)
> at org.apache.ldap.clients.LdapBind.bind(LdapBind.java:350)
> at org.apache.ldap.clients.LdapSearch.main(LdapSearch.java:408)
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
> Substituing those lines to the one that cause the exception seems to correct it :
> public void encodeOccurred(StatefulEncoder encoder, Object encoded) {
> try
> {
> //channel.write( ( ByteBuffer ) encoded ); <--- Object is supposed to be a ByteBuffer [], not a ByteBuffer
> ByteBuffer[] buffers = (ByteBuffer[])encoded;
>
> // int nbWritten = 0; // for debug sake
>
> for (int i=0; i<buffers.length; i++) {
> //nbWritten += channel.write(buffers[i]);
> channel.write(buffers[i]);
> }
>
> // System.out.println("Bytes written (" + nbWritten + ") :");
> ...
> No more exception, then, but, as far as I went, it does not help the whole thing to work correctly. I do not receive any answer from my favorite OpenLdap server. I'm currently checking the PDU to see if it's FUBR or not (ethereal to the rescue). Takes time...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira