Interface names are an unfortunate special case. The interface name can either inlcude or omit the package, but aren't as flexible as normal class references, such as your example, where the interface is in a sub-package.
HiveMind defers converting the interface class name into a Class until as late as possible ... typically when the proxy is created. This is important for when a service-point interface references a class that may not be available. In hivemind.lib, there's some Spring related service interfaces. If we resolved interface names the same was as classes, then the Spring libraries would have to be full dependencies of hivemind-lib-*.jar. What I've explained here is documented, and is consistent with your experiments. Fixing it is possible, but would require a) including Spring as a dependency of hivemind-lib, or b) refactoring the Spring support into a seperate module. On 5/3/05, Hensley, Richard <[EMAIL PROTECTED]> wrote: > I'm using module package names, and I can't seem to get them to work for the > interface attribute of a service-point. Should they work? > > For instance I use > > package="com.foo" > > and > > interface="bar.MyClass" > > This seems to work fine when constructing an instance in a builder, but not > for the interface. The interface does work when I don't use partial package > names, like the following: > > package="com.foo.bar" > > interface="MyClass" > > Richard > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
