Extending Smart Translator via Property Editors

I've been working with Hivemind for a couple of months and I'm very happy with it, so I would like to contribute my 2 cents. I came across a situation where I was using a service that has getters/setters that were of type Class and every time it would exception out on trying to get/set the values from these methods. So I took it upon myself in open source fashion and dug into the code. I found where the exception was coming from and I knew a way to fix it in the source code, but was this the most correct way? NO!

I'd rather add startup code to register a proper Property Editor with the Java Beans framework. There's an extension point for this purpose (hivemind.Startup). Once the Property Editor is defined, it should "just work".

-- Howard Lewis Ship

Back to the drawing board. With the hint from Howard Lewis Ship, the light clicked on and I was back in business. I knew the Smart Translator uses Property Editors to work with types, but only primitive types in java are supported without having to create an editor. I needed one for type java.lang.Class, so I created one.

Using a configuration point for the PropertyEditors gives me the capability of implementing any number of PropertyEditors I want.

Conclusion

The Property Editor is created and registered with hivemind and the Smart Translator is now aware of type "java.lang.Class" and my problems are solved. It just works

HowardLewisShip: This is very good, however I have one criticsm. The PropertyEditorLoader service should implement java.lang.Runnable and be contributed into the hivemind.Startup configuration. Even as coded here, the methods setPropertyEditors() and register() can be part of the service implementation but not the service interface, because it doesn't make sense for other code to call these methods.