On Tue, 2011-02-01 at 13:12 -0600, Gregg Wonderly wrote: > > Digging through classes belonging to a service implementation that is > > designed to be encapsulated/not your concern? Does that sound right? I gotta > > say, it sounds horribly invasive, very hacky and speaks of an overly complex > > solution as the result of treating symptoms, not problems. > > Okay, I want to go through the problems that I was dealing with, the > attributes > of the current mechanisms, and how I inserted points of control to manage > these > issues. > > First, let's look at the simple client mechanisms I wanted to have. I have a > desktop environment, which does lookup, and then shows treeviews of services > based on "machine"->"group"->Service Instance structure. The deployed > services > contain Entry objects that provide values for these three name spaces. Since > I > need to look at these, they can not be preferred by the service or I can't > read > them. There may be a subclass that the client has used, and that can be > preferred no problem. There are some other items in the Entrys that I need > too, > such as icons. Any of the Entry objects that I need access to, and any > classes > which they are dependent on, and which are publicly visible > classes/interfaces, > because of that attribute (public) can not be realistically preferred.
I think I'm with Dan here - looks to me like a misuse of LUS. I see it as a more or less dumb bootstrap mechanism - designed for _lookup_ not _browsing_ . Wouldn't a ServiceBrowserService (or a ServiceIndexingService) be a solution? Michal
