On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny elecha...@gmail.comwrote:
On 6/4/10 12:01 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/3/10 10:51 PM, Stefan Seelmann wrote:
Hi dev,
another easy refactoring is to merge the modules jdbm-store and
jdbm-partiton.
+1.
On Fri, Jun 4, 2010 at 12:27 AM, Stefan Seelmann seelm...@apache.orgwrote:
Felix Knecht wrote:
On 06/03/10 23:04, Stefan Seelmann wrote:
Hi dev,
the core-mock module includes some mock implementations of ApacheDS
core-api classes (CoreSession, DirectoryService, etc.). It is only used
On Fri, Jun 4, 2010 at 12:41 AM, Emmanuel Lecharny elecha...@gmail.comwrote:
On 6/3/10 11:15 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We have a lot of following constructs:
log.error( I18n.err( I18n.ERR_04007 ) );
throw new DecoderException( I18n.err(
+1
On Fri, Jun 4, 2010 at 12:32 AM, Emmanuel Lecharny elecha...@gmail.comwrote:
On 6/3/10 10:47 PM, Stefan Seelmann wrote:
Hi dev,
I'd like to move the only remaining class AvlPartition from module
avl-partition into module xdbm-search. Additional I'd like to rename
xdbm-search to
On Thu, Jun 3, 2010 at 8:36 PM, Emmanuel Lecharny elecha...@gmail.comwrote:
On 6/3/10 7:08 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The constructor accepts a cachesize which is never used. Apart of this I
really can't see, where the caching happens.
Any
On Thu, Jun 3, 2010 at 4:49 PM, Emmanuel Lecharny elecha...@gmail.comwrote:
Hi guys,
just to inform you that in order to get rid of NamingException from the
core server, I'm replacing it by LdapException, and that will lead to some
modification in the core server : every method were throwing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The if {} does the same like the else {} - no matter if it's
'overlapping' or not. If it's not a bug (doing the same) we can skip the
if else.
On 6/4/10 9:08 AM, Alex Karasulu wrote:
On Thu, Jun 3, 2010 at 4:49 PM, Emmanuel Lecharnyelecha...@gmail.comwrote:
Hi guys,
just to inform you that in order to get rid of NamingException from the
core server, I'm replacing it by LdapException, and that will lead to some
modification in
On 6/4/10 9:42 AM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The if {} does the same like the else {} - no matter if it's
'overlapping' or not. If it's not a bug (doing the same) we can skip the
if else.
This is very strange...
I have to review this part of the
On 6/4/10 9:50 AM, fel...@apache.org wrote:
Author: felixk
Date: Fri Jun 4 07:50:56 2010
New Revision: 951314
URL: http://svn.apache.org/viewvc?rev=951314view=rev
Log:
Don't catch RuntimeExceptions accidentally
Good 'catch' :-)
btw, there are many places where we throw
Emmanuel Lecharny wrote:
On 6/4/10 1:03 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/3/10 11:04 PM, Stefan Seelmann wrote:
Hi dev,
the core-mock module includes some mock implementations of ApacheDS
core-api classes (CoreSession, DirectoryService, etc.). It is only
Remove the 'throw new NullPointerException' in the code
---
Key: DIRSERVER-1515
URL: https://issues.apache.org/jira/browse/DIRSERVER-1515
Project: Directory ApacheDS
Issue Type: Bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do we leave it up to third party developers to take care that only
correct values are passed or do we have to take care that otherwise an
exception is thrown? To give an example from shared AttributUtils:
We never check if the object to clone is a
On Fri, Jun 4, 2010 at 12:28 PM, Felix Knecht fe...@otego.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do we leave it up to third party developers to take care that only
correct values are passed or do we have to take care that otherwise an
exception is thrown? To give an example
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 11:36, Kiran Ayyagari wrote:
On Fri, Jun 4, 2010 at 12:28 PM, Felix Knecht fe...@otego.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do we leave it up to third party developers to take care that only
correct values are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To me it would look more logical use everywhere conditional operator
'' in the if restriction [1].
I don't think it's a false positive of findbugs
NS: Potentially dangerous use of non-short-circuit logic
(NS_DANGEROUS_NON_SHORT_CIRCUIT)
This code
On Fri, Jun 4, 2010 at 10:45 AM, Emmanuel Lécharny elecha...@apache.orgwrote:
On 6/4/10 9:08 AM, Alex Karasulu wrote:
On Thu, Jun 3, 2010 at 4:49 PM, Emmanuel Lecharnyelecha...@gmail.com
wrote:
Hi guys,
just to inform you that in order to get rid of NamingException from the
core
On 6/4/10 10:10 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/4/10 1:03 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/3/10 11:04 PM, Stefan Seelmann wrote:
Hi dev,
the core-mock module includes some mock implementations of ApacheDS
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods parameters (pre-conditions).
Should we start using them ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
On 6/4/10 11:28 AM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do we leave it up to third party developers to take care that only
correct values are passed or do we have to take care that otherwise an
exception is thrown? To give an example from shared AttributUtils:
We
Emmanuel Lecharny schrieb:
On 6/4/10 10:10 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/4/10 1:03 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/3/10 11:04 PM, Stefan Seelmann wrote:
Hi dev,
the core-mock module includes some mock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another option that also works: as the mocks are only used by the LDIF
partition tests we can also move them to src/test/java of
ldif-partition. I think that's the better option.
+1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)
On 6/4/10 2:01 PM, Stefan Seelmann wrote:
So where should we put the mocks ? Core-API as you suggested ? (IMO, if
that solve the problem, then +1)
Yes, this would solve the problem.
Another option that also works: as the mocks are only used by the LDIF
partition tests we can also move
Emmanuel Lecharny wrote:
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods parameters (pre-conditions).
Should we start using them ?
I never used them before.
For me assert is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 12:15, Emmanuel Lecharny wrote:
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods parameters (pre-conditions).
Should we
Stefan Seelmann wrote:
Kasun Lakpriya wrote:
Hi all,
I have added some description about each and every component to make
the diagram descriptive. Please add your suggestions and modifications
need to added to this. It can be found in the same link [1] below.
[1] -
On 6/4/10 2:10 PM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods parameters (pre-conditions).
Should we start using them ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reading http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html#usage
I have to withdraw my +1 and agree with Stefans objections
On 06/04/10 14:16, Felix Knecht wrote:
On 06/04/10 12:15, Emmanuel Lecharny wrote:
Hi guys,
currently (and
On 6/4/10 2:16 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 12:15, Emmanuel Lecharny wrote:
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods
Stefan Seelmann wrote:
Hi dev,
I'd like to move the only remaining class AvlPartition from module
avl-partition into module xdbm-search. Additional I'd like to rename
xdbm-search to xdbm-partition.
The xdbm-partition module than contains everything that is related to
XDBM partitions:
-
On 6/4/10 2:21 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reading http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html#usage
I have to withdraw my +1 and agree with Stefans objections
Ok, not a big deal :)
--
Regards,
Cordialement,
Emmanuel Lécharny
Emmanuel Lecharny wrote:
On 6/4/10 2:01 PM, Stefan Seelmann wrote:
So where should we put the mocks ? Core-API as you suggested ? (IMO, if
that solve the problem, then +1)
Yes, this would solve the problem.
Another option that also works: as the mocks are only used by the LDIF
On Jun 3, 2010, at 2:15 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We have a lot of following constructs:
log.error( I18n.err( I18n.ERR_04007 ) );
throw new DecoderException( I18n.err( I18n.ERR_04007 ) );
What about logging the exception within the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A NPE may be thrown at line 280 if 'entry==null'. As the method doesn't
declares a thrown exception I suppose that a default length (like -1)
should be returned if the coumputing fails?
The method endProtocolOp lacks the same problem (entry==null)
[
https://issues.apache.org/jira/browse/DIRSERVER-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRSERVER-1515:
Assignee: Emmanuel Lecharny
Remove the 'throw new
On 6/4/10 2:53 PM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/4/10 2:01 PM, Stefan Seelmann wrote:
So where should we put the mocks ? Core-API as you suggested ? (IMO, if
that solve the problem, then +1)
Yes, this would solve the problem.
Another option
On Jun 4, 2010, at 5:10 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
Hi guys,
currently (and probably because nobody uses them, due to some Java 1.3
habits we have), we don't use asserts to do simple things like checking
methods parameters (pre-conditions).
Should we start using
Emmanuel Lecharny wrote:
On 6/4/10 2:58 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A NPE may be thrown at line 280 if 'entry==null'. As the method doesn't
declares a thrown exception I suppose that a default length (like -1)
should be returned if the coumputing
On 6/4/10 2:55 PM, Alan D. Cabrera wrote:
Finally, what the heck is ERR_04007? :) I thought there already was a
discussion and community consensus about how there is little to negative value
in using numbers as error messages. Maybe I missed the conversation where this
opinion was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
No worries. :) Why do they all have numbers in them?
Because there's also a request to build a knowledgebase [1]. It's easier
having numbers to lookup something in a knowledgebase than having a text
which may occur multiple times and for different
On 6/4/10 3:44 PM, Alan D. Cabrera wrote:
On Jun 4, 2010, at 6:13 AM, Emmanuel Lecharny wrote:
On 6/4/10 2:55 PM, Alan D. Cabrera wrote:
Finally, what the heck is ERR_04007? :) I thought there already was a
discussion and community consensus about how there is little to negative
[
https://issues.apache.org/jira/browse/DIRSERVER-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1515.
--
Resolution: Fixed
Fixed with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I suppose this is either always true or false, right?
if ( attributeType.getSyntax().getSyntaxChecker().isValidSyntax( null ) )
http://people.apache.org/~felixk/shared-docs/xref/org/apache/directory/shared/ldap/entry/DefaultEntryAttribute.html#916
This will always match for the else clause - we now the attributeType is
null (line 1469). Probably dead code?
http://people.apache.org/~felixk/shared-docs/xref/org/apache/directory/shared/ldap/entry/DefaultEntryAttribute.html#1475
On 6/4/10 4:10 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I suppose this is either always true or false, right?
No. It depends on the AttributeType. Some accept null values, some
don't. This is the reason we have such a test.
--
Regards,
Cordialement,
Emmanuel
On 6/4/10 4:14 PM, Felix Knecht wrote:
This will always match for the else clause - we now the attributeType is
null (line 1469). Probably dead code?
http://people.apache.org/~felixk/shared-docs/xref/org/apache/directory/shared/ldap/entry/DefaultEntryAttribute.html#1475
Dohhh ! Good catch
Felix Knecht wrote:
I suppose this is either always true or false, right?
if ( attributeType.getSyntax().getSyntaxChecker().isValidSyntax( null ) )
http://people.apache.org/~felixk/shared-docs/xref/org/apache/directory/shared/ldap/entry/DefaultEntryAttribute.html#916
No. For example the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 16:32, Stefan Seelmann wrote:
Felix Knecht wrote:
I suppose this is either always true or false, right?
if ( attributeType.getSyntax().getSyntaxChecker().isValidSyntax( null ) )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 16:32, Emmanuel Lecharny wrote:
On 6/4/10 4:14 PM, Felix Knecht wrote:
This will always match for the else clause - we now the attributeType is
null (line 1469). Probably dead code?
[
https://issues.apache.org/jira/browse/DIRSERVER-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875614#action_12875614
]
Emmanuel Lecharny commented on DIRSERVER-1252:
--
It's even a bit more
Hi guys,
this module is broken since, pfeww, september 11 2008 (what a
coincidence ! Bad things always happen on 11/09...)
The question is : should we keep going and fix this module or should we
move it to the deceased projects ? A thrd option would be to make this
module a separate project
On Jun 4, 2010, at 6:58 AM, Emmanuel Lecharny wrote:
No worries. :) Why do they all have numbers in them?
Grep is your friend when you have accurate elements to work on :) Numbers are
less versatile than textual descriptions.
/me remember a 5 days debugging session on a production
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The question is : should we keep going and fix this module or should we
move it to the deceased projects ? A thrd option would be to make this
module a separate project we can release separately from ADS 2.0.
- From an administrators POV (who
On 6/4/10 4:37 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 16:32, Stefan Seelmann wrote:
Felix Knecht wrote:
I suppose this is either always true or false, right?
if ( attributeType.getSyntax().getSyntaxChecker().isValidSyntax( null ) )
On 6/4/10 4:40 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 16:32, Emmanuel Lecharny wrote:
On 6/4/10 4:14 PM, Felix Knecht wrote:
This will always match for the else clause - we now the attributeType is
null (line 1469). Probably dead code?
On 6/4/10 4:56 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The question is : should we keep going and fix this module or should we
move it to the deceased projects ? A thrd option would be to make this
module a separate project we can release separately from ADS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I *do* look at the reports, but not as frenquently as you do. Probably
because I consider that we have many other serious issues to fix in the
server, and I wrongly assume that they are more important than the one
you are pointing out.
I didn't
On 6/4/10 5:09 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I *do* look at the reports, but not as frenquently as you do. Probably
because I consider that we have many other serious issues to fix in the
server, and I wrongly assume that they are more important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It all depends on which command we are talking about here. On any linux
box, you have many tools like ldapadd or ldapsearch existing. No need to
rewite those guys (just because starting a command which spawns a JVM is
too freaking slow).
Aren't
On 6/4/10 5:17 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It all depends on which command we are talking about here. On any linux
box, you have many tools like ldapadd or ldapsearch existing. No need to
rewite those guys (just because starting a command which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/10 17:25, Emmanuel Lecharny wrote:
On 6/4/10 5:17 PM, Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It all depends on which command we are talking about here. On any linux
box, you have many tools like ldapadd or
Done.
Emmanuel Lecharny wrote:
On 6/4/10 2:53 PM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/4/10 2:01 PM, Stefan Seelmann wrote:
So where should we put the mocks ? Core-API as you suggested ?
(IMO, if
that solve the problem, then +1)
Yes, this would
Improve antlr generated code [shared-ldap]
--
Key: DIRSHARED-62
URL: https://issues.apache.org/jira/browse/DIRSHARED-62
Project: Directory Shared
Issue Type: Improvement
Environment: All
Hi dev,
the following POMs define the maven-source-plugin and create a source
jar during a local build:
apacheds/http-integration/pom.xml
apacheds/core-api/pom.xml
apacheds/protocol-shared/pom.xml
apacheds/xbean-spring/pom.xml
apacheds/core/pom.xml
apacheds/protocol-changepw/pom.xml
So I'm going to keep the jdbm-partition module.
Alex Karasulu wrote:
On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny elecha...@gmail.com
mailto:elecha...@gmail.com wrote:
On 6/4/10 12:01 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
On 6/3/10
Hi Stefan,
I have absolutely no idea what it is used for.
Looking at the SVN history, it has been introduced by David Djenks at revision
643768 [1] on April 2008.
Personally, I've never used it and I thing it can be removed.
Now, about the definiton of the maven-source-plugin from all the
On Fri, Jun 4, 2010 at 7:21 PM, Pierre-Arnaud Marcelot p...@marcelot.net
wrote:
Hi Stefan,
I have absolutely no idea what it is used for.
Looking at the SVN history, it has been introduced by David Djenks at
revision 643768 [1] on April 2008.
Personally, I've never used it and I thing it can
[
https://issues.apache.org/jira/browse/DIRSHARED-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875658#action_12875658
]
Emmanuel Lecharny commented on DIRSHARED-62:
I'm afraid we won't be able to
Felix Knecht wrote:
Hi Pierre-Arnaud
I'm currently reviewing the dependency tree of each project in Apache DS.
When generating the installers I've found a lot of new dependencies (since
the last release) in the generated lib folder, and especially this one:
findbugs:annotations.
Are
Hi Stefan,
Kiran had the same build problem.
Strangely, the problem disappeared when he removed his maven repository and
tried again.
Kiran, can you confirm?
Maybe we could ask artifacts under org/apache/directory to be removed on the
Continuum machine.
Regards,
Pierre-Arnaud
On 4 juin
On Fri, Jun 4, 2010 at 7:54 PM, Pierre-Arnaud Marcelot p...@marcelot.net
wrote:
Hi Stefan,
Kiran had the same build problem.
Strangely, the problem disappeared when he removed his maven repository and
tried again.
Kiran, can you confirm?
yeah the same problem went away when I tried
Kiran Ayyagari wrote:
On Fri, Jun 4, 2010 at 7:54 PM, Pierre-Arnaud Marcelot p...@marcelot.net
wrote:
Hi Stefan,
Kiran had the same build problem.
Strangely, the problem disappeared when he removed his maven repository and
tried again.
Kiran, can you confirm?
yeah the same problem
Hi Stefan,
I got it last week ya I have checked out and looked at it. but did not
work on that last whole week as I got to complete some tasks in my
training place. Its over now and I'm now starting working on this.
And also just now I got my fixed internet connection :).
Thanks,
Kasun
On Fri,
On Fri, Jun 4, 2010 at 8:56 PM, fel...@apache.org wrote:
Author: felixk
Date: Fri Jun 4 17:56:57 2010
New Revision: 951512
URL: http://svn.apache.org/viewvc?rev=951512view=rev
Log:
Probably vice versa
Modified:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can please some cross check this? It doesn't has a testcase to verify it.
Thanks
Felix
On 06/04/10 20:07, fel...@apache.org wrote:
Author: felixk
Date: Fri Jun 4 18:07:07 2010
New Revision: 951513
URL:
Done.
So I'm going to keep the jdbm-partition module.
Alex Karasulu wrote:
On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny elecha...@gmail.com
mailto:elecha...@gmail.com wrote:
On 6/4/10 12:01 AM, Stefan Seelmann wrote:
Emmanuel Lecharny wrote:
Hi,
two other small modules we have are core-constants and core-avl.
I think we can move the 4 relevant files of core-contants to core-api
and delete core-constants.
For core-avl I'm not sure if we should merge it into another module or
keep it as its own module. It is only used by the AVL
On Sat, Jun 5, 2010 at 1:19 AM, Stefan Seelmann seelm...@apache.org wrote:
Hi,
two other small modules we have are core-constants and core-avl.
I think we can move the 4 relevant files of core-contants to core-api
and delete core-constants.
For core-avl I'm not sure if we should merge it
78 matches
Mail list logo
