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.
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 <email@example.com> wrote:
> Hi all,
> I was looking at the proposal for ServerAttribute stuff at the following
> 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
> 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.
> Ersin Er