Howard Lewis Ship has written a nice document that attempts to compare HiveMind with Spring (and a little of PicoContainer). The comparison is mainly about the Dependency Injection
portions or Spring of course.
HiveMind is the new-comer to the recent lightweight container game. In fact it has been held up due to some legal issues, but that is all getting cleaned up, and it will hopefully be on CVS (or Subversion?) servers soon :)
It will be great to see the likes of Spring, PicoContainer, HiveMind, and others grow and mature. As more people use them in large projects we will learn a lot.
Read Howard Lewis Ship
Comparing HiveMind to Spring
Also read more about HiveMind's recent news:
HiveMind grant is a go!
HiveMind developers ... Please check in!
HiveMind still isn't quite back at Apache ... the software grant has been faxed, but not yet acknowledged, so the HiveMind home page is still not back up.
I have (slightly out of date) version of the home page at:
for those who want more background on HiveMind.
I read your comparison. And from what I see - both frameworks (IoC part) share 90% of same features.
I'm using spring for some time now. And to tell you frankly, I'm not going to switch to anything else, unless there's principal difference. This is also true for most of spring users. So I will not benefit from your great work with HiveMind.
By the way the rest of the different functionality in HiveMind could have been implemented as a extention of spring. It is a pity thet insted of collaboration and reusing we see talented developers spend their valuable time writing twin frameworks. And instead of having one great framework with lot's of components, GUI tools, documentation we see many absolutely identical with just the core functionality and lack of any usablity tools, docs etc.
That's where MS wins the fight over developers. Because easy to use tools with nice GUI, lot's of samples, documentation, books - this is as important as advanced design principles your frameworks built on.
I'm developing with vs.net at work, and I can tell you there is no tool support for ORM. What MS has in vs.net for ORM support is terrible! I'm doing another project with Tapestry/Spring/Hibernate and there is alot less code in that app, and no handcoded sql. So MS is not winning me over, what they have is tedious, boring, graphical tools.
I don't believe that HiveMind and Spring are so similar that Spring could be extended into HiveMind. HiveMind addresses a particular set of needs and reflects a particular set of priorities. The distributed nature of HiveMind (that is, that many modules may contribute to each other to form the overall Registry of services and configurations) is pretty alien to Spring. Spring's ApplicationContext is more hiearchical, where child contexts can reference beans they define, or those defined in a parent.
The distributed aspect is the main reason for HiveMind. I would ask that you review a sample use of distributed configurations: http://home.comcast.net/~hlship/case1.html
Now I certainly wouldn't want anyone to abandon Spring for HiveMind at my whim; which is why providing gateways, where Spring could manage a HiveMind Registry, or HiveMind could manage a Spring ApplicationContext, is a more viable approach.
I would say that Spring will maintain an advantage in terms of IoC support and a headstart on integration (with JTA, Hibernate, iBatis, etc.).
I think you may be missing the point of competitive cooperation. For example, the Spring team has become very interested in HiveMind's line precise error reporting (adapted from Tapestry). What I can't imagine is a new developer to the Spring team coming in and making such a disruptive set of changes (it took many days of work to bring line precise error reporting to Tapestry ... it was built into HiveMind from day one). But by proving the value of such changes (in Tapestry and HiveMind), we are inspiring the Spring team to catch up. Likewise, many features of Spring are desirable, and may eventually be replicated in some fashion into HiveMind (and Avalon, and PicoContainer, and ...).
I have to admit that error reporting in Tapestry is one of the most exciting features I've seen in various frameworks.
From the other side - debug logging in spring is quite detailed and helps me spot problems quickly, although it is not as advanced and cool looking as in Tapestry.
I'd like to understand better Hivemind's support for flexible configuration schemas for configuring different types of services. How does it compare with Eclipse's plugin model (how is it better?) Is it centered around a user-definable xml-schema? Is there a concept of a 'host-plugin' which processes the configuration information at runtime using an api analagous to Eclipse generic ConfigurationElement? Can configuration information be updated and written out at runtime by management clients? I never really got how configuration gets injected into the services so they can take it and run with it...
Something I would like is the ability to define custom configuration schemas for particular services so configuration information can be tailored in a way that is concise, simple, and 'makes the most sense' for that type of service. I'd also like users to be able to tweak configuration information directly without losing their mind, and potentially by using a eye-candy management client (maybe powered by JMX.) Javabeans based configuration is great, but is somewhat limiting in that respect. I would think configuration and management is one area where Hivemind and Spring could integrate.
I blogged on more detail on this topic at http://www.jroller.com/page/kdonald
if you're interested.
What I would like you do to, is to take a good look at Shadowfax, the .NET banking reference implementation, and give your honest comment on the benefit of using Hivemind (if translated to c#) in such a scenario.
It seems to me that forcing a Boeing 707 into a match-box would be easier.
"Making things as simple as possible, but no simpler."
Ah Rolf, so long, so long since last we were blasted with the holy writ of .NET....
Though off topic, what does the .NET world offer in terms of frameworks like HiveMind, Spring, Pico, etc., not to mention Hibernate, iBatis, JDO, etc.?
As before, I'm working 50% in both worlds, and most of that 50% that I'm working in the .NET world, I'm wishing I had even 1/4 of the useful tools I have at my disposal in the .Java world.
As far as HiveMind is concerned, one thing that I agree with over Spring (not to disparage Spring in any way) is the fact that services provided by HiveMind do get quantified as an interface rather than as any old generic Java object. I think that if you're taking the time to use a framework to provide controlled access to a certain object, it should be described and quantified as an interface, or else you introduce far too many opportunities for loose contracts about which classes do what. Otherwise, what do you need a framework for? Just instantiate your object! It's all fine and good to set up a standard set of code conventions that you would use, and which can be exposed via Spring, but if there is no compiler-level enforcement of those standards, as there is when interfaces are involved, you're introducing the opportunity for your conventions to be circumvented by the less diligent members of your team. Or even you, when time is short.
Oh, and though I love the impetus behind Spring (a lot of what I do involves a homemade service framework based on Johnson's book prior to Spring), I absolutely abhor the continuing use of the word "BEAN" (e.g. BeanFactory). What in the name of all that is holy does "BEAN" mean to anyone outside of the Java world? And for those in it, does it have any real, intrinsic meaning of any value? It's a legacy of Sun marketing that is confusing to some and useless to others. If you're provide a service through your framework, call it a service. If you're providing a generic object through your framework, call it an object. But a "bean"? There's got to be a better word.
Drew:"so long, so long since last we were blasted.."
Sorry if I offended you but I didn't mean to say that we have something better than Spring, Pico, Hibernate, iBatis et al. We haven't!
But 2 or 3 new frameworks everyday? ShadowFax doesn't depend on any frameworks at all.. What I would like to see is a "review"- critique of some sort of Shadowfax from the J2EE side. Maybe it is not the frameworks that is something wrong with but the way to write applications.
I'm investigation this "Shadowfax" of yours (still dealing with 10 minutes of trying to get to the SCC). But it seems like it's just a collection of best practices. As I understand it (and this is based on limited knowledge thus far), Shadowfax is an attempt to establish a set of service-oriented architecture (SOA) best practices. The concept of a "service" in that context is very different than the services that are provided by HiveMind and similar frameworks. A service in a service-oriented architecture is an outward facing service, providing its wares to external components. The services provided by hivemind and other similar frameworks are more internal to the workings of an application, so I don't know that you can compare them (are you trying to? I'm not sure.).
By the way, these "frameworks" are not an evil thing, and their proliferation is actually good rather than bad. The useful frameworks will survive and the less useful ones will go away, but in the end, we're left with a choice. Take the example of ORM: there are a lot of choices and you're free to choose one that works for you, that follows most closely how you view the problem space. Same with the IoC and "dependency injection" frameworks. Compare that to the MS world, where you may someday get to use ObjectSpaces, as an example, and if you don't like how it works, you've got to completely write your own framework.
The frameworks in question will be successful if they provide a useful service, their use isn't burdensome, and their functionality is focused. They should do one thing and do it well, and not force developers who use them to completely change the way they work. That's something the heavy frameworks such as those produced by both Microsoft and Sun haven't been able to do. A lot of Sun's J2EE best practices turned out to be disastrous. Most of the demo apps for best practices that I've seen come out of Microsoft have been the same. The problem for the .NET community is that the bulk of developers are so used to just using what Microsoft gives them that there isn't the same sense of a burgeoning developer community, sharing code and ideas, like there is in the Java world. That's not a reflection on .NET itself, either as a framework or as its constituent languages, which are just fine. It's just a fact. Most of the really useful things you see in the .NET world, beyond what Microsoft themselves offer, have been provided by people with experience in the Java world, and in fact most are ports of Java tools.
I would personally love to see the .NET community offer something like HiveMind, or Spring, or Pico. I'd especially like to see something like iBatis or Hibernate, because that's a really important problem space. Unfortunately, it hasn't happened, and I think that's a shame.
Hi Drew, if you are interested in .NET ports of Java open source tools they are really starting to take off. The community is still young but it is growing. You are correct in that it is an uphill battle to get the community to look at solutions not provided by Microsoft.
There is a port of Spring called Spring.NET (http://sourceforge.net/projects/springnet/
) and it has an active developer discussion list that has generated some interesting discussions about what is already available.
On the O/R front there is OJB.NET (http://sourceforge.net/projects/ojb-net/
), Gentle.NET (http://www.mertner.com/projects/gentle/
), NHibernate (http://sourceforge.net/projects/nhibernate
), and the iBatis port called NORM (http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=6bf91dea-dea3-4949-9602-ea1ea32a22b4
). They are all in various stages of stability and development activity.
One of the advantages to IT is that you never risk missing the boat- there is always a new boat coming. Thank to Sun's lawsuit MS missed the J2EE boat but now another is sailing up! I can not see the advantage of O/R in SOA. Does Hibernate do XML serialization and deserialization? Even if it does, what use is it of Objects if I can not see them from my client? How do the typical J2EE frameworks fit in in applications architectures like Shadowfax?
Very soon all the products you did mentioned can go the way of the Dodo, Drew.
If you cannot see the advantage of O/R in SOA, then I don't know what to tell you. No, Hibernate doesn't do XML serialization. It doesn't have to. That's not its job. It does ORM and it does it well. Part of the reason it does it so well is that it doesn't try to do things like XML serialization.
If you have a product you are trying to design using a service-oriented architecture, your xml serialization features are outward facing. They're part of how the service is accessed by service consumers. Internally, if your product requires database access, you still have impendence mismatch problems between your objects and your tables. You could scrap existing ORM tools and say "I don't need these, I'm doing SOA!" but then you'd still have to deal with the mapping somehow.
ORM tools like hibernate will be useful as long as we're using relational databases and object-oriented languages. That won't be forever, but it certainly won't be any different anytime soon. When it does change, new tools will probably be necessary to deal with the new problems introduced by the new architecture. Who knows where Sun and Microsoft will be then? I don't care so long as there is still a community of developers willing to share their good ideas so we're not reliant on whatever tool or language vendors turn out.
I am glad you took the time to check out Shadowfax, it is only pre-alpha but it did compile and run on my box.
It looks very different from a traditional J2EE app. It is a big application, so it will take some time getting to know it but so far, it looks to me like a major paradigm shift. But I am the first to admit that I can be wrong, maybe all the different Java frameworks will fit in somehow. In the meantime I would be delighted if you too would take the time to study it to allow for some interesting discussions. (You said you are doing .NET stuff too).
My working hypothesis is that with Indigo and Shadowfax Microsoft is now taking the lead in enterprise software development.
Can you give me info to track down this Indigo you mentioned? I'm all for something that will make my life easier and better. I just think I'll avoid holding my breath before waiting for it to come from Microsoft.;)
For details go to http://longhorn.msdn.microsoft.com
and do a search for Indigo:
1. Indigo Security Walkthroughs
2. Default Indigo Security
3. Indigo Permission Requirements
4. Indigo Technology Overview
5. Choosing Between Indigo RemoteObject and Web Services
6. Indigo Programming Concepts
7. Securing Applications Built with Indigo
8. Advanced Indigo Architecture
9. Distributed Applications Using Indigo Services
10. Advanced Indigo Security
11. Using Indigo Access Control
12. Using Indigo Access Control with Attributes
13. Using Advanced Indigo Access Control with Attributes
14. Using Indigo to Write a Multinode Application That Uses a Token Server
15. Using Indigo to Write a Multinode Application That Uses a Key Server
16. Indigo Partial Trust Requirements
17. Introduction to Indigo Security
18. Using Indigo Client Security
19. Introduction to the Indigo Security Architecture
20. Understanding Indigo Web Services
Indigo is part of Longhorn but will be released seperatly.
Why do we have to transform this thread into an Indigo evangelization booth ? We'll all learn about it when the a stable version is released (2008 ?), that's for sure. Concerning Indigo's inherent superiority in the SOA world, let's not forget that it will still have to communicate with both legacy apps as well as actual J2EE apps which are in production or under development. It won't be an "Indigo communicating with Indigo communicating with Indigo" world. Somebody will have to integrate all these "other" Java enterprise apps (the vast majority, nowadays) hence the need for better, non-Indigo, frameworks. Why is evolution forbidden outside Indigo, beats me ...
Besides, let's be serious. Even Cobol hasn't went "the way of Dodo", yet. Why make such radical assumptions ?!
Not to mention the fact that SOAs like Indigo and others have absolutely no valid comparison to dependency-injection frameworks like HiveMind and Spring. There's no reason a SOA wouldn't use these frameworks behind the scenes. It's like Rolf is saying that OLE DB will completely obliterate the need for relational databases.
Here comes Rolf trying to hijack another thread with its MS propaganda. I find it funny how MS comes up with these funny names, they have so many of them it looks like they're tring to race with the java framework creators! ;)
And together with Rolf comes those MS magic wands, full of promises based on something that barely exists today. And it will make everything else go the way of the Dodo! It is surely way ahead of anything ever made by mankind! :D
Rolf, how does it feel to be blindly guided by hand?
Henrique: "comes those MS magic wands, full of promises.."
Where have I come up with any MS acronyms before? I you read my posts you will see that I always propagate against something- against over-architecture and complexity for complexity own sake. Never for. (Except maybe smart clients which is uncontroversial). This is the first time I dragged any MS technique into the discussion.
I just can not understand all this new frameworks! I won't undertake to speak for Juergen and Rod but how do you think they feel when they have laid down such enormous amount of (unpaid) work and then come almost immediately an almost similar system appear?
You can not afford all this fragmentation, while you are fighting yourself the new world will pass you by.
Beginning from May, the free software will enter in Campidoglio
The Gramaglia city council member: "political Choice, not against Microsoft"
The Common one of Rome
ahead slowly towards Linux
"We want to give a contribution to the diversification"
of ALESSIO BALBI
ROME - "We put endured in luminosity one what: we ce do not have it with Microsoft ". Mariella Gramaglia, city council member to the Communication of the Common one of Rome, holds to us to place in the just perspective which many see like the nth slap arranged from the movement open source to Bill Gates and associates: beginning from May, Linux will begin to replace Windows in the computers of the administration capitolina, placing Rome on the same road of Monaco and other common ones that, in Europe and the world, they have decided to entrust itself to the free software.
A beautiful blow for Linux and its supporters. And the risk of one ugly botta for the pockets and the image of Microsoft. But that Roman is however only, for hour, a cautious experiment and graduates them: "the first tests will be conduct on the e-mail, on the agenda software and on the sharing platforms", the Gramaglia city council member explains. Also the forum and the newsgroup that the citizens use in order to converse with the Common one through the portale Web will be been involved in the experimentation.
Henrique: "comes those MS magic wands, full of promises.."
> Where have I come up with any MS acronyms before? I you read my posts you will see that I always propagate against something- against over-architecture and complexity for complexity own sake. Never for. (Except maybe smart clients which is uncontroversial). This is the first time I dragged any MS technique into the discussion.
I have seen you pushing unasked for MS propaganda all over this JAVA forum many times before, you want me to list them?
> I just can not understand all this new frameworks! I won't undertake to speak for Juergen and Rod but how do you think they feel when they have laid down such enormous amount of (unpaid) work and then come almost immediately an almost similar system appear?
I guess they must feel relieved, since it simply proves that there is a real need for them, otherwise no one would be working on them. And as it was said a million times before, you just have to use what is best for you, that's something called CHOICE. You can choose your platform, your Java implementation, your Web framework, your Server, it is all about choice. You have to learn to choose, to pick what is better for you. Best of it all: most of it is unpaid and free, so there is no money loss involved. Instead, you invest your time on something that you know solved a similar problem for someone else. It is a proven and working solution, not vapourware to be released in 3 years.
> You can not afford all this fragmentation, while you are fighting yourself the new world will pass you by.
You really don't get it, it is not a fight, it is an election. ;) Do you believe that one single solution will fit every problem out there? Do you think that having different options to solve a problem is a bad thing? I will worry about the future when it comes, meanwhile I will solve today's problems with today's tools, not with promises.
Henrique: "Do you think that having different options to solve a problem is a bad thing?"
Have you heard of the proverb "too much of a good thing"?
Henrique: "Do you think that having different options to solve a problem is a bad thing?"
> Have you heard of the proverb "too much of a good thing"?
Don't worry about it, it is ok to have some dificulties in the begginning, but I am sure you will be up to speed in no time, it just takes some practicing. Soon you will be able to choose between more then 2 options, and then all the doors will open up to you! Just don't give up! :)
Henrique: "Just don't give up!"
Truth is, I given up already! :)
Henrique: "Just don't give up!"
> Truth is, I given up already! :)
We know that: you love MS! ;)
Do you plan on supporting xml schema completely for your configuration point definitions? That might be nice, because it seems you could simplify the rules since a schema provides rules validation built in. And why re-invent the wheel, right?
My original intent was to support something that mimiced more of the W3C schema. I got bogged down figuring out how to do the validation myself ... I was trying to figure out how to create and interpret all sorts of crazy DFAs and such. The code I looked at, out of some XML parsers, was very confusing and ugly (and undocumented) ... it would have been a massive time sink to deal with it all!
Rather than pursue that at the time, I decided to go with what you see today, a much simpler a model, a very, very modest subset of W3C. So far, I haven't felt the need to revisit this area ... HiveMind is more than getting by, it's stylin!
That's cool, I just thought it'd be neat, say if you defined your schema and marked the element as a type "int", there seems no need to specify a translator, the schema specification would determine what translator was used. I guess that was my main point.
XMLBeans - from BEA but now an apache project I believe -- looked intersting...full schema support.
XMLBeans looks extremely promising; but it assumes that you know what your schema looks like ahead of time. Every configuration point has its own schema and the level of mix and match is out of control inside HiveMind; you absolutely don't know that's valid statically (as you would with a DTD or a W3C Schema).
XMLBeans does a lot of work to take in a W3C schema and produce classes and other resources that lead to an efficient parsing and representation of a document ... but I think that kind of build-time control gets in the way of leveraging their work for something as highly dynamic as HiveMind.
I've brought the HiveMind home page back to life:
I may at some point check out this Indigo stuff, but whether it comes from Sun, the JCP or (perhaps especially) Microsoft, I'm very hesitant about any framework that claims to solve all my problems for me (just like all the previous frameworks that claim to solve all my problems for me).
HiveMind doesn't boil the ocean, but what it does do is work against the specific concept of "the framework that solves all my problems for me." No one can solve ALL your problems for you but YOU. HiveMind is about choice, and about glue. It is design to allow you to easily assemble a cohesive solution from the frameworks YOU select, rather than those foisted upon you.
Some of the key concepts in HiveMind ... particularily that you can split the definition of a service (its service interface) from its implementation (which may come from an entirely different module) is all about choice, about plugging together the pieces you understand and are comfortable with.
Ok, Howard, sorry for the Indigo detour. I have said before- and I can say again that Tapestry is high on my list of respected frameworks. But I hate it when my "idols" start to compete which each other. Why do you felt the need to bring HiveMind into the world when there already was Spring? Tapestry and Spring already is a perfect match, or? So why?
I had very specific needs for a microkernel that not only managed services (somewhat like Spring and folk), but also managed configuration data (like Eclipse). Nothing out there, except for the Eclipse plugin API, was even close to what I needed ... and it didn't have a services model.
Many of the ideas in HiveMind germinated in Tapestry; a lot of the configuration ideas are already in there -- Tapestry is a container of far more than just components. Application extensions and helper beans have been part of Tapestry for years; in addition, Tapestry consists of a number of subsystems that are tied together. I've long been frustrated that replacing portions of Tapestry's infrastructure requires create subclasses of the central engine object, because over time I've grown unsatisfied with inheritance based solutions, preferring instead aggregation and delegation.
The end result, the case study referenced earlier, was a big success and has lit a fire under the feet of many at WebCT. However, I can see the big picture ... that combine HiveMind with Tapestry would be a huge win for all. Having the application and the application framework run under the same microkernel is also a very powerful tool that will help many from having to reinvent the wheel.
I'm very focused on developer productivity; I'm often charged with trying to squeeze the most productivity out of developers with less experience, or located remotely, or otherwise operating under a handicap. Therefore, HiveMind includes two key features: line precise error reporting and HiveDoc.
LPER is adapted from Tapestry as is tremendously helpful ... runtime errors are related back to specific lines within specific XML deployment descriptors. I hope variations of this become an industry standard.
HiveDoc, the ability to generate comprehensive, hyperlinked documentation about your application is also critical for applications of the scale and complexity I'm contemplating. Here's an example:
Once you start imagining applications with dozens of modules, hundreds of services and configuration points, and potentially thousands of contributions, having a map will be indespensible ... potentially the difference between project success and failure.
On the time scale I had at the time (last May) to produce something it was not feasible for me to join an existing project (Spring or Avalon), come up to speed with their design, code and community, establish the necessary leadership position necessary to make such sweeping changes (both from a political angle and from a coding angle), and get it all working.
In addition, HiveMind was a chance for me to experiment with a number of techniques. I learned to use Maven as a build tool, and I really embraced TDD (or near TDD; I usually write tests in parallel with the code, rather than writing them first). The end result is very stable code with very high code coverage numbers.
The "microkernel community" generally accepts that no one solution fits all. Petty much all of the containers can be brought up as managed beans/services in one of the other contains, which allows gateways from one microkernel to the other.
It's not a popularity contest, its a meritocracy. Many people (surprisinlg many) are plagued by the same particular set of concerens that led me to create HiveMind. They are anxious to adopt HiveMind. You are belying a "winner takes all" mentality that doesn't exist in the real world. If someone with Spring experience came on to a HiveMind-based project they would either (a) adapt what they knew from Spring to HiveMind or (b) make use of a bridge from HiveMind to Spring. Its a proposition not disimilar from porting an application from one J2EE server to another (given that most people make use of server-specific extensions that must be addressed as part of the port).
I have to say again what looks the most promising about Hivemind IMO is flexible capability for providing service configuration information---1. the schema definition capability makes it nice for users to add new configurations, and 2. the xml->to->java rules-based converter keeps the developer from having to write a lot of BORING custom processing code (I have since read the docs and noticed that's how your configuration model is different than Eclipse's...)
To me though there is just something about the xml format (maybe it's just all the xml in general), primarily with the rules stuff, that just seems difficult to follow. Very Digester like. It's also a bit confusing to me that configuration information can come from configurations, but also be supplied directly to services as well (I would have thought each service would have an associated configuration and that would be injected via IoC - but I'm not sure how that is even done...)
Have you looked at possibly using a scripting solution like Groovy or Beanshell to provide a way of performing the xml->java conversion that is still easy for the developer? I know such an idea was suggested to me as a nice alternative to xml-bloat. But in general, though, I think you've got a good concept.
You can most certainly inject a configuration into a service; that's the intent of HiveMind. I think I abandoned the concept of merging configurations and services because I could easily dream up services that drew on multiple configurations. However, perhaps I simply didn't think in terms of collaboration enough!
The stack-based (Digester) approach to parsing the XML into objects is "hell or genius". Hell because you have to be able to think in terms of a stack of objects, so it takes some getting used to (though, I think, a bit less than Digester). Genius because it is so wonderfully uniform, with location tagging and all sorts of checking built right in seamlessly. A scripting solution might not be so consistent.
Perhaps <rules> is too industrial strength ... it's really set up for hierarchical data. I can imagine other ways to convert the XML to Java objects that can simplify the expression with some loss of power (internally, it can be converted into the same set of Rule objects). For example, something like:
<attribute name="key" required="true"/>
<attribute name="value" required="true"/>
As a shorthand for for a standard set of rules:
<read-attribute name="key" property="key"/>
<read-attribute name="value" property="value"/>
In fact, thinking about implementation, I would just have the <conversion> element expand out to the smae set of Rule objects.
You could even have something kind of intermediate:
<map attribute="key" property="preferenceKey" translator="int"/>
<map attribute="value" property="preferenceValue" translator="service"/>
Using the int and service translators here doesn't make sense, but illustrates an option. The idea is that you can override the default mapping (each attribute mapped to a property of the same name) and indicate the type conversion for the attribute into a property.
I was wondering, have you looked at Eclipse since they started moving towards the OSGi (sp?) model for their runtime? Do you have any comments/opinions on that? Have you looked at applying it to Hivemind? I don't know much about the effort, but I've heard OSGi (if I got the acronym right) is like a standard for building a service-based microkernel.
I'm done some cursory look at OSGi and, of course, if the Eclipse guys are into it, there must be something there. The code samples I've seen for using OSGi reminded me a bit more of Jini. On the one hand, it had a good hot redeploy option, and could do transparent remoting ... on the other hand, you did a LOT of service lookup (not dependency injection); it appears that if you want to connect to the redeployed version of a service, you must obtain a new proxy ... and since you can't tell when a service has been redeployed, you have to constantly reacquire your proxies.
In the J2EE world, redeployment is done at a large scale: the EAR level, which contains any number of WAR and EJB deployments. Hot redeployment redeploys the EAR in its entirety ... the HiveMind Registry will shutdown, as will all the EJBs and web application contexts; then the new version of the EAR is brought up and the HiveMind Registry will be re-instantiated and re-initialized.
Concerning the glue part of both frameworks I would say hivemind is stronger. Hivemind is more powerful in its xml definitons and distingishes already in the core between different concepts (like interceptors, service-modells, extension-points etc). This makes it easier to use and I think to implement tools.
On the other hand Hivemind gives up this advantage as a glue-framework by beeing more intrusive than Spring. It demands that services implement interfaces. This very often means writing glue code for others and also your own classes, which makes a glue-framework not realy attractive.
(OSGi and dependency injection: take a look at http://gravity.sourceforge.net/servicebinder/
I think your points about beans are well taken. However, I don't think HiveMind itself has to change ... I think a standard service for creating beans, but blessed with BuilderFactory type configuration power to link the beans to services and configurations (and even other beans).
I picture this as a BeanFactory service, with a matching Beans configuration point. Contributions to the configuraiton point would be similar to BuilderFactory parameters.
Beans would have a lifecycle: singleton, 'short', threaded, maybe pooled. 'short' is like Spring prototype: fresh create each time. The others would largely match the service models.
I also want to have a "smart" translator as the default, that does a best-guess conversion from string to any particular type, when making assignments. So you would generally use <set> rather than <set-int>, <set-boolean>, <set-double>, <set-float>.
"Be supple as the bamboo, and strong as the oak" (a half remembered Chinese proverb). I think the focus on interfaces makes HiveMind strong, and the focus on XML makes it supple -- or maybe the other way around :-)
BTW ... haven't heard if you are going to sign the CLA and be part of the initial team ... has your e-mail changed?