|
Home > Archive > Apache Directory Project > October 2005 > [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap
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][Release] Remaining JIRA issues for 0.9.3 roadmap
|
|
|
|
| Trustin Lee 2005-10-25, 7:45 am |
| Hi Alex,
2005/10/25, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>:
>
> [0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
> My take on these issues:
>
> 0 - not worried about it since change can be made any time: we can push
> it out
I've found our implementation (apacheds-core) throws an LdapNamingException
with LDAP-specific error codes such as ALIASPROBLEM. I thought we can stop
all classes from throwing LdapNamingException and make them throw
NamingException instead, and then ExceptionService can convert them to
corresponding LdapNamingExceptions 1:1. But it's not 1:1 right now. So I
cannot divide ExceptionService into IntegrityService and ExceptionService
currently.
I guess we need to standardize which type of exceptions we should throw for
consistency. NamingException or LdapNamingException? I think
LdapNamingException is the way to go.
Once decided, I'll modify the core ASAP.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Trustin Lee 2005-10-25, 7:45 am |
| 2005/10/25, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> Hi Alex,
>
> 2005/10/25, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>:
>
>
> I've found our implementation (apacheds-core) throws an
> LdapNamingException with LDAP-specific error codes such as ALIASPROBLEM. I
> thought we can stop all classes from throwing LdapNamingException and make
> them throw NamingException instead, and then ExceptionService can convert
> them to corresponding LdapNamingExceptions 1:1. But it's not 1:1 right now.
> So I cannot divide ExceptionService into IntegrityService and
> ExceptionService currently.
>
> I guess we need to standardize which type of exceptions we should throw
> for consistency. NamingException or LdapNamingException? I think
> LdapNamingException is the way to go.
>
> Once decided, I'll modify the core ASAP.
>
I've marked DIREVE-164 as 'INVALID'.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Emmanuel Lecharny 2005-10-25, 7:45 am |
| Yo,
> [2] http://issues.apache.org/jira/browse/DIREVE-163 (Emmanuel)
>
> 2 - JPEG corruption issue: this is an ugly one so we'll need status on it
> [2] I think is involved and can be pushed out if it's not going to be done
> within the next 24 hours.
This is really a simple but ugly one. After more or lmess two month of
"evaluation", here is its status :
- the reason why Jpeg (and any other binary element) are not well
handled is that the decoders are transforming every value to a String.
This is, of course, not the right thing to do
- it leads to another correlated problem, Strings are encoded as simple
Strings, not UTF-8 Strings. This is also a problem
- then, we need to control the HR tags (Human Readable) into the
SchemaService methods before doing any transformation of any value that
are OctetString (see RFC 2251)
- Last, but not least, we have to deal with DN normalization, if any
binary attribute is to be used - I bet this is possible -. As those
attributes will be encoded with a # followed by the hexadecimal String,
we have to check that this attribute is binary or not.
Not to mention that a huge regression test has to be done...
I've currently created a new branch (called xxx-utf8) to deal with all
those problems, and the impact on the code will be huge.
I really don't think that it will be a simple and easy patch, so I just
suggest that this 0.9.3 release should be delivered without it.
PS: I learnt the hard way that this kind of patch need a very deep
knowledge of the whole system, this is one of the reason it took so
long. The positive point is that I understand much more parts or
ApacheDS, but this is still a rough trip ;). We really need more people
being involved in the guts of ApacheDS !
-- Emmanuel
| |
| Stefan Zoerner 2005-10-25, 7:45 am |
| Hi all!
How about DIREVE-264?
http://issues.apache.org/jira/browse/DIREVE-264
I like the idea of having a userfriendly standalone release. Especially
for people who are new to ApacheDS (and even new to LDAP, perhaps).
Reasonable default logging configuration, server configuration and so on.
An off-the-shelf ACI default configuration (e.g. for a sample partition)
which makes sens (e.g. persons are allowed to modify there own passwords)
would also be nice ... We will probably not do that for the 0.9.3, be we
should at least spent some time to improve a standalone deliverable later
on.
Greetings, Stefan
| |
| Trustin Lee 2005-10-25, 7:45 am |
| 2005/10/25, Stefan Zoerner <SZOERNER-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>:
>
> How about DIREVE-264?
> http://issues.apache.org/jira/browse/DIREVE-264
>
> I like the idea of having a userfriendly standalone release. Especially
> for people who are new to ApacheDS (and even new to LDAP, perhaps).
> Reasonable default logging configuration, server configuration and so on.
> An off-the-shelf ACI default configuration (e.g. for a sample partition)
> which makes sens (e.g. persons are allowed to modify there own passwords)
> would also be nice ... We will probably not do that for the 0.9.3, be we
> should at least spent some time to improve a standalone deliverable later
> on.
I agree with you. Eventually, we'll need to provide a user friendly
administration UI and JMX interface just like Tomcat project team has done.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Nick Faiz 2005-10-25, 7:45 am |
| Hi,
DIREVE-264 is important from another perspective - logging. We want
to ensure that the *only* time we release an actual slf4j
implementation is for the standalone. In other words, we shouldn't
bundle a slf4j logger in the main jar.
This is important for embedding ApacheDS - some loggers clash. If you
are using the plain jar, you will need to choose which slf4j
implementation you want to run.
I was going to work on improving the current standalone maven goal
(in main) in two steps:
1st step: move the maven standalone goal up to the apacheds/
maven.xml . This way we can have a top level standalone goal which
can also bundle documentation.
2nd step: make sure the standalone was complimentary to Enrique's
OSGi standalone project.
If we want to complete the 1st step I can work on it this weekend. If
we need it before then I'm quite happy to work with someone to do it.
Cheers,
Nick
On 25/10/2005, at 9:24 PM, Stefan Zoerner wrote:
>
> Hi all!
>
> How about DIREVE-264?
> http://issues.apache.org/jira/browse/DIREVE-264
>
> I like the idea of having a userfriendly standalone release.
> Especially for people who are new to ApacheDS (and even new to
> LDAP, perhaps).
> Reasonable default logging configuration, server configuration and
> so on. An off-the-shelf ACI default configuration (e.g. for a
> sample partition) which makes sens (e.g. persons are allowed to
> modify there own passwords) would also be nice ... We will probably
> not do that for the 0.9.3, be we should at least spent some time to
> improve a standalone deliverable later on.
>
> Greetings, Stefan
| |
| Alex Karasulu 2005-10-25, 5:45 pm |
| Emmanuel Lecharny wrote:
>Yo,
>
>
>
>
>This is really a simple but ugly one. After more or lmess two month of
>"evaluation", here is its status :
>- the reason why Jpeg (and any other binary element) are not well
>handled is that the decoders are transforming every value to a String.
>This is, of course, not the right thing to do
>- it leads to another correlated problem, Strings are encoded as simple
>Strings, not UTF-8 Strings. This is also a problem
>- then, we need to control the HR tags (Human Readable) into the
>SchemaService methods before doing any transformation of any value that
>are OctetString (see RFC 2251)
>- Last, but not least, we have to deal with DN normalization, if any
>binary attribute is to be used - I bet this is possible -. As those
>attributes will be encoded with a # followed by the hexadecimal String,
>we have to check that this attribute is binary or not.
>
>Not to mention that a huge regression test has to be done...
>
>I've currently created a new branch (called xxx-utf8) to deal with all
>those problems, and the impact on the code will be huge.
>
>I really don't think that it will be a simple and easy patch, so I just
>suggest that this 0.9.3 release should be delivered without it.
>
>
No problem we'll just push this over to 0.9.4.
Alex
| |
| Alex Karasulu 2005-10-25, 5:45 pm |
| Trustin Lee wrote:
> Hi Alex,
>
> 2005/10/25, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org
> <mailto:aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>>:
>
> [0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
> My take on these issues:
>
> 0 - not worried about it since change can be made any time: we can
> push
> it out
>
>
> I've found our implementation (apacheds-core) throws an
> LdapNamingException with LDAP-specific error codes such as
> ALIASPROBLEM. I thought we can stop all classes from throwing
> LdapNamingException and make them throw NamingException instead, and
> then ExceptionService can convert them to corresponding
> LdapNamingExceptions 1:1. But it's not 1:1 right now. So I cannot
> divide ExceptionService into IntegrityService and ExceptionService
> currently.
>
> I guess we need to standardize which type of exceptions we should
> throw for consistency. NamingException or LdapNamingException? I
> think LdapNamingException is the way to go.
>
> Once decided, I'll modify the core ASAP.
Well keep in mind that this is internal refactoring so it can be done
anytime. No need to rush on this. We can push this up to next release.
Alex
| |
| Alex Karasulu 2005-10-25, 5:45 pm |
| Stefan Zoerner wrote:
>
> Hi all!
>
> How about DIREVE-264?
> http://issues.apache.org/jira/browse/DIREVE-264
>
> I like the idea of having a userfriendly standalone release.
> Especially for people who are new to ApacheDS (and even new to LDAP,
> perhaps).
> Reasonable default logging configuration, server configuration and so
> on. An off-the-shelf ACI default configuration (e.g. for a sample
> partition) which makes sens (e.g. persons are allowed to modify there
> own passwords) would also be nice ... We will probably not do that for
> the 0.9.3, be we should at least spent some time to improve a
> standalone deliverable later on.
Sure we can include this but someone has to make sure the packaging is
done right. Nick if you can figure this out along with the logging
stuff we can roll it into 0.9.3.
Let me know.
Alex
| |
| Nick Faiz 2005-10-25, 8:45 pm |
| Hi,
On 26/10/2005, at 1:13 AM, Alex Karasulu wrote:
>
> Sure we can include this but someone has to make sure the packaging
> is done right. Nick if you can figure this out along with the
> logging stuff we can roll it into 0.9.3.
> Let me know.
>
>
I'll do it within the next three or four days and will notify you then.
Cheers,
Nick
> Alex
>
>
>
|
|
|
|
|