> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > At 09:19 AM 6/7/2002 -0400, you wrote: > > > public interface ServiceManager > > > { > > > void lookup(String name) throws ComponentException; > > > boolean exists( String name ); > > > } > > > >I never said a Role should be an Object, but that we should have a > >method for a String role and an Object hint for more complex queries. > > hint then - why is that an Object - no other directory > service I know of > has such a "feature" and given that the same info can be > represented via a > single string then seems like flexability syndrome.
No it looks like cleaning up code. You don't like Object, fine. I don't really care. Come up with something different. It is semantically more clear to lookup a role, with a hint if you need to give more clarity as to what you are looking for. For instance, it is semantically more clear to do this: lookup(ConnectionManager.ROLE, "SSL"); than it is to do this: lookup(ConnectionManger.ROLE + "/SSL"); What we are talking about here is *still* a ConnectionManager. However, we are stating our preference for one that supports the SSL _feature_. Same role--not a different one. FS? I don't really think so. Two strings would work for me. The Object allows for experimentation with a Query object, or using a Locale to obtain an internationalized version of a component... > > Note that I kept the ComponentException as it should only be > > > raised in > > > error condition. > > > >Yeah, but it needs to be tested for. > > > Why ? The only thing thta should be catching it is the container I'm lost on this one. I am in favor of removing the ComponentException from the COmponentManager--the component should assume the component is there. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
