[ http://issues.apache.org/jira/browse/HIVEMIND-124?page=comments#action_65759 ] Richard Hensley commented on HIVEMIND-124: ------------------------------------------
Ok, I got to poking around, and discovered the unit test that was failing because of my patch. You were right, it was a test that relied upon SmartTranslator. Ok, now for a different solution. I looked around at the translator, there are a lot of them... So any change could be big. I don't see how the translator could cache the value because they seem to be stateless objects. So, we will have to be careful about how a isAssignableToType method might work. Here is my analysis of each translator. The follow analysis of how to perform the isAssignableFromType() operation assumes no caching of values by the translator. BooleanTranslator - fixed type of java.lang.Boolean ClassTranslator - The locator string is a class that that is resolved using the ClassResolver. To perform the operation, the class would have to be resolved. ConfigurationTranslator - can either return a Map or a List. The logic could be constructed such that the value would not have to be retrieved from the specification. DoubleTranslator - fixed type of java.lang.Double EnumTranslator - getting the value involves digging around in public static fields of classes, so the cost to get the value is not high. This one would have to get the value to perform the operation. IdListTranslator - fixed type of java.lang.String InstanceTranslator - The class to instance is buried in the locator string, it can be retrieved, resolved, and used for the operation without instancing an object. IntTranslator - fixed type java.lang.Integer LongTranslator - fixed type of java.lang.Long NullTranslator - fixed type of java.lang.String QualifiedIdTranslator - fixed type of java.lang.String ResourceTranslator - fixed type of org.apache.hivemind.Resource ServicePointTranslator - fixed type of org.apache.hivemind.internal.ServicePoint ServiceTranslator - This one is tricky because we would need to dig around and find the interface for the service from the contributing module. SmartTranslator - This one uses property edited to translate the value. This could be done twice to figure out the value without undo overhead. ObjectProvider - This one uses object providers to get a new object. This one would imply added an isAssignableFromType() method to the ObjectProvider interface. The analysis for that follows: Adding an isAssignableFromType() method to ObjectProvider: ClassObjectProvider - See ClassTranslator ContributionObjectProvider - See ContributionTranslator ObjectInstanceObjectProvider - See InstanceTranslator ServiceObjectProvider - See ServiceTranslator ServicePropertyObjectProvider - See ServiceTranslator, plus the code would have to figure out the type of the property. This one might not be easy. Object Providers from the contributed library. BeanFactoryObjectProvider - This one finds a bean factory and then sends the locator off to it. This implies that the BeanFactory now would need an isAssignableFromType() operation. BeanFactoryImpl - The bean class is part of the contributions, so isAssignableFromType() could be implemented without constructing an object. SpringBeanObjectProvider - This one uses spring to look up a spring bean and return it. The spring bean factory supports the method Class getType(String name), so this one is not bad. > Report a proper message when a constructor argument in BuilderFactory is > invalid > -------------------------------------------------------------------------------- > > Key: HIVEMIND-124 > URL: http://issues.apache.org/jira/browse/HIVEMIND-124 > Project: HiveMind > Type: Bug > Components: framework > Reporter: Richard Hensley > Attachments: patch.txt > > My situation is that I use constructor arguments for all my required > parameters of objects. The code inside of the BuilderFactoryLogic uses the > BuilderPropertyFactet.isAssignableFrom() method to figure out if a particular > parameter in a constructor is right. The > BuilderPropertyFactet.isAssignableFrom() eats an ApplicationRuntimeException > and returns false. This is bad when you miss-spell a service name, for > instance: > <service>service:MyServic</service> > When you meant, > <service>service:MyService</service> > The error that Hivemind throws is that it had trouble finding a valid > constructor, when the real problem was that it had problems finding your > service to even check if the constructor was valid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
