Re: OSUser

> > 1) UserManager is still a class.
> 
> It's abstract.  Do you have a problem with abstract classes?  

No, when hidden.
Yes, when part of an API.

> I 
> purposefully made it abstract so that I could have the static factory 
> method getUserManager().  I think extensible singletons are best 
> implemented as abstract classes; not interfaces.

We'll agree to differ :-)

> 
> > 2) interface configurator refers to some item of impl :
> >
> >     void configureUserManager(UserManager.InternalAccess ia);
> 
> UserManager.InternalAccess is an [inner] interface, not a fixed 
> implementation.

It is part of your API (whether you intend it or not, whether you intend it to be fixed or not).
Should not be.
 
> > Observations:
> >
> > 3) no need to specify items from Object, toString(), hashCode(), 
> > equals()
> 
> I think that Entity should indicate how OSUser behaves with respect to 
> these methods.  This is especially important with equality.  Do you 
> disagree?  You're essentially saying you don't like that I went out of 
> my way to document something I didn't /have/ to.

It is a 'should not' issue.  They are specified on Object (which is not an interface).  

> 
> > 4) should not declare 'throws UnsupportedOperationException' in 
> > interface method sig
> 
> [FYI everyone: UnsupportedOperationException extends RuntimeException]
> I chose to do this to let people know that implementations might choose 
> not to implement the method.  How would you do this differently?

I would not declare it in the throws clause.  I might use it in exactly the way you specify.
 
> > 5) would prefer no dependancy on javax.naming.
> 
> [FYI everyone: I use only Exceptions in javax.naming]
> (a) It's in standard java; no external libraries required,
> (b) I found the Exception classes to have very high parity for what was 
> needed and I think "naming" and OSUser have more to do with each other 
> than what a passing glance reveals.  Think about it.

Not a blocker for me, but i'd advise against.  It feels too much like the eternally vague
SQLException to me ;-)
 
> > 6) There is no impl for Orion, Resin etc. Lots missing.
> 
> Very true.

And as such Robert's working spike is massively superior to the sandbox code. Sorry.  
 
> Patrick Lightbody said "Well, having multiple implementations of what 
> is generally the same thing is probably not a good idea."  I agree with 
> him.

Pertaining to what?  
 
> Lets keep in mind that OSUser v-whatever is beta and there's never 
> really been a 1.0.  That means we aren't held down to any interfaces 
> and decisions made in OSUser's early beta incarnation.

Kewl, so nobody will mind a complete interface/impl separation design with teh same package names
as the current shipping version. I'm still voting (non binding) for Robert's code.

- Paul

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01