That's not a gotcha; service interfaces should generally not have anything that looks like a property; autowiring concerns the implementation class, not the interface.
HiveMind is about the static configuration of the application. If you want to store additional, dynamic configuration, then the right approach is to have a service that mixes and matches configuration data in HiveMind with configuration data stored externally in a database. On Sun, 10 Oct 2004 18:29:47 -0500, Paul Hawke <[EMAIL PROTECTED]> wrote: > I've been actively investigating (and blogging) Hivemind : > > > http://paul.caffeinatedbliss.com/2004_10_01_blog_archive.php#109666359960821959 > > http://paul.caffeinatedbliss.com/2004_10_01_blog_archive.php#109729195442872620 > > http://paul.caffeinatedbliss.com/2004_10_01_blog_archive.php#109744592640387156 > > It's been a fascinating ride so far - I have my own plugin scanner > creating the classpath and hivemodule XML files therefore being found > dynamically at runtime for any JAR / ZIP files that happen to be > laying around. > > I ran into a "gotcha" with auto-wiring: it appears that the auto > wiring scans the class itself for properties, rather than using the > declared interface from the module description - is this by design? > > The other question - were configuration points meant to only be for > static configuration? I have the situation where users will configure > the application at runtime and it struck me that the format of the > configuration written at that point could / should be handled by > Hivemind as it's what is read and used by the various services. > Unfortunately it didnt appear to be possible to declare the > configuration point and its associated schema, then interact with a > service that loaded and saved it at runtime outside of the module > description. Is that planned or beyond the scope of what you were > looking at? > > Thanks, > > --- Paul. > > > > On Tue, 28 Sep 2004 15:48:09 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> > wrote: > > It was envisioned, it just isn't how I (get to) use it. > > > > Your startup code could easily create a HiveMind Registry. You can > > have HiveMind scan multiple ClassLoaders when it builds the Registry > > (they get wrapped up as a ClassResolver object). HiveMind takes it > > from there. > > > > You can also provide your own ModuleDescriptorProviders, which > > proviide ModuleDescriptors and don't mandate where they come from. > > The default impl, XMLModuleDescirptorProvicder, is used to locate > > HiveMind descriptors on a classpath. > > > > > > > > > > On Tue, 28 Sep 2004 13:06:41 -0500, Paul Hawke <[EMAIL PROTECTED]> wrote: > > > I've read through the archives of both the user and developer mailing > > > lists and I'm still not totally clear, so I hope you dont mind me > > > asking you the question directly! > > > > > > I'm the author of an open source Java Swing application ("Chronicle > > > Lite" - under a BSD style license) - a blogging client application > > > that began life as a client talking to just Blogger and broadenned out > > > to interact with a variety of different blog servers through the use > > > of runtime plugins. > > > > > > On startup the application scans its execution directory for JAR files > > > and incorporates them dynamically into its classpath used for the rest > > > of the application (custom classloader, nothing earth shaking there). > > > Internally the application defines service interfaces, separating the > > > code and making it testable, and reducing depenancy. (a mix of > > > constructor and setter style dependency injection) Users are able to > > > add functionality to Chronicle Lite by simply dropping a JAR file into > > > its execution directory - giving the ability to communicate with > > > different server types, for instance, or adding tools to the > > > application. > > > > > > All that said, I was looking at possibly using an IoC kernel - > > > Hivemind / pico container - as the core of the next version of the > > > application to fully separate and decouple the various parts of the > > > application. PicoContainer simply doesnt do enough, not a rich enough > > > framework to be useful. The "rub" is that Hivemind appears to use > > > just the existing classpath, and not scan for JAR files containing > > > services on startup. Am I reading this wrongly and missing something? > > > > > > At the present time Chronicle Lite plugin descriptors are code based - > > > an extension of the standard Java BeanDescriptor concept. I wanted to > > > move toward a more data-driven approach, which lends itself toward the > > > Hivemind service / module descriptors. > > > > > > Hivemind on "the client side" - possibly something that was never > > > envisaged (especially since it was announced on theserverside.com)! > > > > > > Thanks for your time, > > > > > > --- Paul S. Hawke, > > > Chronicle Lite, > > > http://chronicle.caffeinatedbliss.com/lite > > > > > > > > > -- > > Howard M. Lewis Ship > > Independent J2EE / Open-Source Java Consultant > > Creator, Jakarta Tapestry > > Creator, Jakarta HiveMind > > http://howardlewisship.com > > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
