Is org.apache.directory.server;core.prefs still usefull?

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

while working on SyntaxCheckers, I get caught in a nasty problem with the
classes of this package. The question is : do we need it?
I see no places in the server where we use or instanciate those classes, so
a blind guess is that those classes are remaining for historical reasons
(may be they were used years ago).

The problem I currently have is that when you store a byteArray into a
Preferences, it is transformed to a base64 String, which is not accepted by
the server.

Right now, I have commented the failing test ( testCreateAndSetByteArray ) -
which was incorrect anyway, because we didn't stored a byteArray but a
String in this test - so that the regression tests can work.

I'm waiting for some heads up before going for more drastic solution s(like
removing the package), because I may have missed something important (I
don't know this part oif the server)

Thanks !

-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Is org.apache.directory.server;core.prefs still usefull?

[Alex Karasulu <ak...@apache.org>]

This is actually good because I want to review the code before we merge.
I'll try to make some time to do this after a 1.0.2 release is out the door.

Alex

On 4/18/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 4/17/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > BTW, as 1.5.0 is out, you can now push all the SASL back to trunks, if
> you
> > feel likes it's ready.
>
> I'm travelling much of the next 10 days, so I'd personally rather wait
> on merging.  But, if you've reviewed and are comfortable getting
> clients working, you're welcome to merge the SASL branch yourself.
> Don't forget I did some doco for SASL and related config that could
> also use a review and eventually be put somewhere better for 1.5.1:
>
> http://cwiki.apache.org/confluence/display/DIRxSBOX/Protocol+Providers
>
> Otherwise, I'll hold off on merging until I hear an ACK in case you
> wanted to review and until I settle back around 29-APR.
>
> Enrique
>

Re: Is org.apache.directory.server;core.prefs still usefull?

[Enrique Rodriguez <en...@gmail.com>]

On 4/17/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> BTW, as 1.5.0 is out, you can now push all the SASL back to trunks, if you
> feel likes it's ready.

I'm travelling much of the next 10 days, so I'd personally rather wait
on merging.  But, if you've reviewed and are comfortable getting
clients working, you're welcome to merge the SASL branch yourself.
Don't forget I did some doco for SASL and related config that could
also use a review and eventually be put somewhere better for 1.5.1:

http://cwiki.apache.org/confluence/display/DIRxSBOX/Protocol+Providers

Otherwise, I'll hold off on merging until I hear an ACK in case you
wanted to review and until I settle back around 29-APR.

Enrique

Re: Is org.apache.directory.server;core.prefs still usefull?

[Alex Karasulu <ak...@apache.org>]

Emmanuel, Enrique,

On 4/17/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> BTW, as 1.5.0 is out, you can now push all the SASL back to trunks, if you
> feel likes it's ready.


I would like to review this before it is merged back in the trunks unless
Emmanuel you reviewed it already and feel this is fine.

Alex

Re: Is org.apache.directory.server;core.prefs still usefull?

[Emmanuel Lecharny <el...@gmail.com>]

Thanks Enrique,

we will keep the prefs here a little while until we have set a decent
roadmap for OSGi (it would be the perfect timing now that 1.5.0 is out to
start working on OSGi for 1.6).

The only problem I see with prefs is the way it stores data, using some king
of base64 encoding which is not at all supported by the server natively. We
have to figure out a solution for that if we are to keep prefs into the
server.

I gonna create a JIRA about this piece of code to keep it in our radar.

BTW, as 1.5.0 is out, you can now push all the SASL back to trunks, if you
feel likes it's ready.

Regards,
-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Is org.apache.directory.server;core.prefs still usefull?

[Enrique Rodriguez <en...@gmail.com>]

On 4/13/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> while working on SyntaxCheckers, I get caught in a nasty problem with the
> classes of this package. The question is : do we need it?
> I see no places in the server where we use or instanciate those classes, so
> a blind guess is that those classes are remaining for historical reasons
> (may be they were used years ago).

We added Prefs support back when it looked like it might become a
useful way to handle config in a JDK-standard way.  The idea of having
system- and user-specific config in a DIT makes a lot of sense and
similar mechanisms exist in Windows and Linux.  To answer your
question, it would be useful if Prefs ever became widely used.

At the same time that Prefs hit the JDK, there was a push to add Prefs
as a standard service to the OSGi Service Platform.  So, we add Prefs
to the core of ApacheDS and there is a Prefs OSGi service in my
sandbox, which pretty much just wraps the ApacheDS core prefs with the
OSGi Prefs API.

I don't think it should be part of the core.  If possible it could be
its own module or even rolled into the OSGi Prefs with ApacheDS as a
pluggable back-end.  But, going back to the fact that Prefs hasn't
taken off, I also wouldn't be opposed to just removing it.

Enrique

Re: Is org.apache.directory.server;core.prefs still usefull?

[Alex Karasulu <ak...@apache.org>]

Hi Emmanuel,

This package was created a long time ago at Enrique's request to build a
prefs OSGi service where the preferences are backed by the DIT.

BTW this implements a Preferences object which is the in the
java.util.prefspackage.  I think this stuff might come in handy for
unstructured pref
storage.

However we need to determine exactly what our course will be for the usage
of the DIT for configuration information.  Also we need to figure out how
useful this is for the OSGi effort.

HTH,
Alex

On 4/13/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi,
>
> while working on SyntaxCheckers, I get caught in a nasty problem with the
> classes of this package. The question is : do we need it?
> I see no places in the server where we use or instanciate those classes,
> so a blind guess is that those classes are remaining for historical reasons
> (may be they were used years ago).
>
> The problem I currently have is that when you store a byteArray into a
> Preferences, it is transformed to a base64 String, which is not accepted by
> the server.
>
> Right now, I have commented the failing test ( testCreateAndSetByteArray )
> - which was incorrect anyway, because we didn't stored a byteArray but a
> String in this test - so that the regression tests can work.
>
> I'm waiting for some heads up before going for more drastic solution
> s(like removing the package), because I may have missed something important
> (I don't know this part oif the server)
>
> Thanks !
>
> --
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com