Viktor, First off I'd like to say that this type of constructive critisism is most appreciated.
On 5/10/05, Viktor Szathmary <[EMAIL PROTECTED]> wrote: > > For simple dependencies, it's easy enough to set things up. The first > dubious point is the distinction between services and configurations. > IMHO this distinction really doesn't help at all: it doesn't add any > value to introduce two concepts, where one would be sufficient. Both > services and configurations are objects that get initialized via xml > declarations and have dependencies. It's not clear to me, at what > point a certain dependency should be a service or a config. A > configuration seems to be necessary when I want to create a reasonable > XML syntax (schema) for initializing objects of this kind later on > (and even though you can make the xml for configurations look > reasonable, they remain Lists which is an artifact that impacts the > domain object model). > My first impression of HiveMind was also that this dichotomy of services and configurations was sort of arbitrary. After all they are in the end both mapped to POJOs... But after using HiveMind for a while I got to appreciate this distinction. I define configurations whenever I need to provide an extension point with which other modules can affect the behaviour of "my" services. As you say a configuration is nothing but a collection (in HiveMind 1.1 it can also be represented as a Map), but that only affects your domain model in so far that it corresponds to a one-to-many relationship. > I feel the XML configurations lack the simplicity and consistency > that's crucial for developers to effectively use the framework. What > would have been a few simple lines of java code (not to mention a > scripting language) become tedious pages of XML. I feel HiveMind > reinvents the XML/OO binding wheel once again, estabilishes it's own > schema language, variable substitutions etc. IMHO this is a critical > issue. It would be better to promote the Java based dependency > management APIs and expose them to direct manipulation, scripting > languages and your favorite java/xml binding framework, rather than > trying to reinvent this. Madness lies this way, and you can already > see the numerous dead corpses on the roadside :) - think Jelly, the > numerous wretched xml/oo mappers that would be best to forget, etc.. > IMHO the Hivemind "module descriptor language" is very well conceived in that the descriptors are very concise and crisp. Yet I agree with you that it would be good with a Java API to let you do the same thing in other ways (be they more verbose or more succinct). This topic is being discussed right now on the developer mailing list (see http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1388). Please join in on this if you have any concrete (or vague) ideas / opinions on this topic. > Registry initialization should be more flexible and support different > deployment scenarios that are not one jar/one hivemodule. A common > real-world example is environment-specific configurations. The > approach I implemented was a custom registry initialization sequence, > that after addDefaultModuleDescriptorProvider(), finds a > "hivemind.registry" in the classpath, and loads the further > hivemodules listed there (these are simple resource URIs that look > like classpath:/com/example/foo.xml or > file:/foo/myproject/config.xml), then loads further config resources > that were programmatically added (eg. from a testcase setUp()). I feel > this should be part of the framework - if you're interested I can send > the corresponding code. > Would it help if the META-INF/hivemodule.xml mechanism were supplemented with a system property defining a list of descriptor URIs? I would be hesitant to add another configuration file with its own syntax. I'd also be interested in how your code initializes the registry. > Documentation needs to be more example-based (at the least give more > guidance on where in the reference to look for things). It's a real > headscratcher to figure out some of the functionality that is clearly > there (jndi, ejb remoting, etc). Guidelines/best practices should be > focused on. > This is definitely something we need to improve upon. There are some good examples on the HiveMind site. I think we should promote these to the front page (even in front of the reference documentation) and enrich them with links to specific pages in the reference works. Other thoughts. Regards, --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
