You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin Er <er...@gmail.com> on 2007/10/02 09:30:39 UTC

[ApacheDS] ServerAttribute - Attribute

Hi all,

I was looking at the proposal for ServerAttribute stuff at the following
page:

http://cwiki.apache.org/confluence/display/DIRxPMGT/Value%2C+ServerEntry

First of all, IMO we should not have anything from JNDI inside the core. So
taking an Attribute as a parameter to ServerAttributeImpl constructor is not
necessary IMO. However we should have utilities to perform conversion
between the two.

And again following the same issue, there is a line in the mentioned
constructor:

public  ServerAttributeImpl( Attribute attribute ) throws  NamingException
    {
        if ( attribute == null )
        {
            log.error(  "Null attribute is not allowed" );
            throw new  NamingException( "Null attribute is not allowed" );
        }
        else if ( attribute instanceof  ServerAttributeImpl )
        {


Neither ServerAttributeImpl nor ServerAttribute implements the Attribute
interface. So this constructor will never work. I guess it may be unintended
error. Not a big problem of course.

But the point is, again, I think it's better not to have Attribute inside
the server. As we'll decouple the JNDI layer, the conversion can be done
inside that adaptor if necessary.

WDYT?

-- 
Ersin Er
http://www.ersin-er.name

Re: [ApacheDS] ServerAttribute - Attribute

Posted by Alex Karasulu <ak...@apache.org>.
I agree with completely keeping JNDI out just to be firm on it.  JNDI is
like stepping in
dog poo, before you know it is spreads all over the place :D.

Alex

On 10/2/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi Ersin,
>
> I kept this constructore for backward compatibility. If you are using
> the server embedded, there is a chance that a user will inject some
> Attribute(s) into the server through JNDI. If we rewrite the JNDI
> layer, we will need to convert Attribute(s) to ServerAttribute and
> ServerEntry, thus the need of such a constructor.
>
> But we can also provide a convertor to do the work, and not polluting
> the new interface.
>
> On 10/2/07, Ersin Er <er...@gmail.com> wrote:
> > Hi all,
> >
> > I was looking at the proposal for ServerAttribute stuff at the following
> > page:
> >
> > http://cwiki.apache.org/confluence/display/DIRxPMGT/Value%2C+ServerEntry
> >
> > First of all, IMO we should not have anything from JNDI inside the core.
> So
> > taking an Attribute as a parameter to ServerAttributeImpl constructor is
> not
> > necessary IMO. However we should have utilities to perform conversion
> > between the two.
> >
> > And again following the same issue, there is a line in the mentioned
> > constructor:
> >
> > public ServerAttributeImpl( Attribute attribute )
> > throws NamingException
> >  {
> >  if ( attribute == null )
> >  {
> >  log.error( "Null attribute is not allowed"
> >  );
> >  throw new NamingException( "Null attribute is not allowed" );
> >  }
> >
> > else if ( attribute instanceof ServerAttributeImpl )
> >  {
> >
> > Neither ServerAttributeImpl nor ServerAttribute implements the Attribute
> > interface. So this constructor will never work. I guess it may be
> unintended
> > error. Not a big problem of course.
> >
> > But the point is, again, I think it's better not to have Attribute
> inside
> > the server. As we'll decouple the JNDI layer, the conversion can be done
> > inside that adaptor if necessary.
> >
> > WDYT?
> >
> > --
> >  Ersin Er
> > http://www.ersin-er.name
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Re: [ApacheDS] ServerAttribute - Attribute

Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Ersin,

I kept this constructore for backward compatibility. If you are using
the server embedded, there is a chance that a user will inject some
Attribute(s) into the server through JNDI. If we rewrite the JNDI
layer, we will need to convert Attribute(s) to ServerAttribute and
ServerEntry, thus the need of such a constructor.

But we can also provide a convertor to do the work, and not polluting
the new interface.

On 10/2/07, Ersin Er <er...@gmail.com> wrote:
> Hi all,
>
> I was looking at the proposal for ServerAttribute stuff at the following
> page:
>
> http://cwiki.apache.org/confluence/display/DIRxPMGT/Value%2C+ServerEntry
>
> First of all, IMO we should not have anything from JNDI inside the core. So
> taking an Attribute as a parameter to ServerAttributeImpl constructor is not
> necessary IMO. However we should have utilities to perform conversion
> between the two.
>
> And again following the same issue, there is a line in the mentioned
> constructor:
>
> public ServerAttributeImpl( Attribute attribute )
> throws NamingException
>  {
>  if ( attribute == null )
>  {
>  log.error( "Null attribute is not allowed"
>  );
>  throw new NamingException( "Null attribute is not allowed" );
>  }
>
> else if ( attribute instanceof ServerAttributeImpl )
>  {
>
> Neither ServerAttributeImpl nor ServerAttribute implements the Attribute
> interface. So this constructor will never work. I guess it may be unintended
> error. Not a big problem of course.
>
> But the point is, again, I think it's better not to have Attribute inside
> the server. As we'll decouple the JNDI layer, the conversion can be done
> inside that adaptor if necessary.
>
> WDYT?
>
> --
>  Ersin Er
> http://www.ersin-er.name


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