Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 99530 invoked from network); 26 Aug 2002 20:08:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Aug 2002 20:08:12 -0000 Received: (qmail 24629 invoked by uid 97); 26 Aug 2002 20:08:43 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 24613 invoked by uid 97); 26 Aug 2002 20:08:42 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 24600 invoked by uid 98); 26 Aug 2002 20:08:42 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) In-Reply-To: To: "Jakarta Commons Developers List" MIME-Version: 1.0 Subject: Re: [discovery II] Ready for next review X-Mailer: Lotus Notes Build V60_M14_08012002 Release Candidate August 01, 2002 From: Richard Sitze Message-ID: Date: Mon, 26 Aug 2002 15:08:06 -0500 X-MIMETrack: Serialize by Router on D03NM145/03/M/IBM(Build V60_M14TT_08092002NP Release Candidate|August 09, 2002) at 08/26/2002 14:08:09, Serialize complete at 08/26/2002 14:08:09 Content-Type: text/plain; charset="US-ASCII" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >But simpler is better: Discover -> DiscoverInfo Distant memories of a late night are starting to emerge. As it stands: ClassDiscovery extends ResourceDiscovery ClassInfo extends ResourceInfo I can pass a ClassDiscovery object to a method that is looking for a ResourceDiscovery parameter.. and the method will be able to retrieve a valid ResourceInfo (alias ClassInfo) [assuming if finds anything]. ServiceDiscovery is broken: it ought to extend ClassDiscovery, NOT ResourceDiscovery. For the sake of symetry and possible future growth, I'll change/add: ServiceDiscovery extends ClassDiscovery ServiceInfo extends ClassInfo Finally, if I merge everything, we have no way to grow/extend without adding addtional method(s). I'm going to make the above changes, and drop the idea of merging for now. >I was thinking about the 'policy' stuff - and I was thinking of >an alternative ( and simpler ?) solutions: Funny you should say that... remember my indiscriminate use of a 9-letter 'F' word? I was heading this direction without the foundation we now have... I had some problems with how to do it, but I think a ResourceInfo hierarchy will alleviate those (PropertyInfo w/ PropertyDiscovery & a ChainedDiscovery or somesuch.. hmm). I'll see what I can do moving forward, but it's likely to be slow with short bursts. ******************************************* Richard A. Sitze IBM WebSphere WebServices Development On Mon, 26 Aug 2002, Richard Sitze wrote: > Do you have an opinion on the value of ClassDiscovery being a subclass of > ResourceDiscovery? This is the only reason why the names of the methods > are 'findResouces' in ClassDiscovery and ServiceDiscovery. I did it that > way originally out of habit. I don't see any real value for this, > particularly since the return types are different... yuch. I'll fix > that. > > Probably go ahead and move everything into one class, and call that > "discover": > > Discover.resources() - returns Enumeration of ResourceInfo > Discover.services() - returns Enumeration of ClassInfo > Discover.classes() - returns Enumeration of ClassInfo > > >A bit asymetric - don't we also need ServiceInfo ? > > What would it represent that isn't already available from ClassInfo? If we merge ClassDiscovery, ResourceDiscovery, ServiceDiscovery - then probably it make sense to also merge ResourceInfo, ServiceInfo, ClassInfo. Some fields will be null where they don't make sense. My comment was only 'cosmetic' - no extra info, just symetric naming. ( i.e. if ClassDiscovery returns ClassInfo, RD -> ResourceInfo, then ServiceDiscovery should return ServiceInfo ). But simpler is better: Discover -> DiscoverInfo I was thinking about the 'policy' stuff - and I was thinking of an alternative ( and simpler ?) solutions: We could implement the 'policy' order by just adding multiple sources to the Discover. Right now we can add loaders as the source of discovery, but you can add a 'addPropertySource', etc. The behavior - each source will be searched. If a property source is added, we'll look for the file and read it if present, etc. The result will be an [] ( or Vector ), with ordering given by the order of sources. For example: Discover jaxpDisc=new Discover(); jaxpDisc.addSystemPropertySource( "javax.xml.parsers...." ); jaxpDisc.addPropertiesSource(javaHome +"lib/jaxp.properties" ); jaxpDisc.addLoaderSource( Discovery.getThreadClassLoader() ); jaxpDisc.addLoaderSource( this.class.getClassLoader() ); DiscoverInfo jaxpInfo[]=jaxpDisc.discoverServices(); ParserFactory=jaxpInfo[0].createClass(); ( alternative: create the factory for each discoverInfo and check if it suports schema - or something like that. ) Costin > > > > ******************************************* > Richard A. Sitze > IBM WebSphere WebServices Development > > > On Fri, 23 Aug 2002, Richard Sitze wrote: > > > OK Costin, you win :-) > > That doesn't happen very often, I should celebrate :-) > > > 1. ClassInfo extends ResourceInfo. > > You can add the getInstance() helpers in ClassInfo, if > you want. > > Just looking at the code: toClassInfo() seems a bit strange, it should > be static or something like that. > > Maybe to avoid confusions and conversion we can just merge ClassInfo into > ResourceInfo - or turn ClassInfo into ClassTools that processes > ResourceInfos. > > BTW, also to keep it simpler: I would move > ClassDiscovery.findResources() to ResourceDiscovery.findClasses() > Same for ServiceDiscovery -> findServices(). > > That's just cosmetics, it doesn't matter too much. > > > 2. All Discovery classes use Enumeration (it's ugly..) > > We can return ResourceInfo[]. Easier for the user to manipulate, > and we can still preserve the 'lazy' evaluation. > > I have no problem with Enumeration. > > > 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not > ResourceInfo) > > through Enumeration. > > A bit asymetric - don't we also need ServiceInfo ? > > > 4. ServicesDiscovery has changes in semantics. Yours returned > > ResourceInfo with the URL & Loader of the META-INF/services/file. I'm > > convinced that what you really wanted was the URL and the loader of the > > classes themselves, so it uses ClassDiscovery internally for each > > 'service' found. > > Well, if that's what I wanted :-) ... > > You're right, the Loader and URL for the class itself is what matters - > I (wrongly) assumed that the descriptor will be in the same .jar with > the classes. This is not allways the case. > > > 5. Services ala Java/Jar document: something like that is in tools > > I think I started to understand ManagedProperties. It's an interesting > idea, but I'm afraid to even think of tomcat's loader hierarchy ( and > the 'reversed' loader order, with child-first ). > > I still feel this is a bit to complex - but if you need it > this way I won't complain. > > > 6. Original 'stuff' moved down into tools, and otherwise cleaned up. > Most > > internal extensions dropped.. you can use the simple tools, or not. > > Great. > > Costin > > > -- > To unsubscribe, e-mail: < > mailto:commons-dev-unsubscribe@jakarta.apache.org> > For additional commands, e-mail: < > mailto:commons-dev-help@jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: < mailto:commons-dev-unsubscribe@jakarta.apache.org> > For additional commands, e-mail: < mailto:commons-dev-help@jakarta.apache.org> > > -- To unsubscribe, e-mail: < mailto:commons-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: < mailto:commons-dev-help@jakarta.apache.org> -- To unsubscribe, e-mail: For additional commands, e-mail: