Guice-persist and @Finder documentation

[Deanna Bonds]

I have done lots of searching and I haven't found any documentation or usage samples for the @Finder documentation.

Looking at the source for com.google.inject.persist.finder It seems to follow the warp-persist model. But it isn't identical. Apparently in the module install you have to addFinder interfaces (not sure why - is that a way to get the finder out of the inject chain? - saw that bit in the junit tests for persist package) The boxing seems to be a bit different. Can anyone point me to any docs or an examples?

[Chris]

> I have done lots of searching and I haven't found any documentation or
> usage samples for the @Finder documentation.

I started with the unit tests: http://goo.gl/tzNcJ which were very
helpful. The wiki also has good higher level documentation: http://goo.gl/wJL92

> Looking at the source for com.google.inject.persist.finder It seems to
> follow the warp-persist model. But it isn't identical. Apparently in the
> module install you have to addFinder interfaces (not sure why - is that a
> way to get the finder out of the inject chain? - saw that bit in the junit
> tests for persist package) The boxing seems to be a bit different. Can
> anyone point me to any docs or an examples?

Dynamic accessors probably need to be made explicitly known to the
module because I don't think Guice inspects interfaces.
The other change I found from warp-persist was that you need to
specify the implementation of your Collection return type:
@Finder(query="foo", returnAs = HashSet.class)
Set<FooEntity> getFoos();

Hope that helps,
-Chris

[Deanna Bonds]

Thanks Chris.  I had already found those links in my search for documentation.  The junit test case was really the only example I found except for someone else using that same pattern on stackoverflow.com .  I am hoping the AddFinder call in the Module register is just for the unit test as that would make using the @Finder more trouble that it is worth if I have to do it for each domain object that I have finders.   And still haven't really seen an example of the Boxing.   I am currently leaning to using warp-persist even though it doesn't appear to be maintained for a couple years.  It has an easier interface and is documented, but I really hate adding another library just to do finders.

[Alen Vrečko]

Warp-persist also requires to register the @Finder interface. See
http://www.wideplay.com/dynamicfinders

It is via the .addAccessor(PersonAccess.class) instead of addFinder.

The reason why you need to register all your _interfaces_ is simple.
Guice has no idea how to instantiate FinderInterface. Consider

@Inject MyFinderInterface

This has to be backed by a concrete class!

The only option is to generate backing class on the fly when addFinder
is called. There is no "wildcard" provider in Guice. See
http://code.google.com/p/google-guice/issues/detail?id=49 and the
discussions on the mailing list if you want more.

Your options are simple
o) Use @Finder in concrete class instead of Interface (this works
OOTB)
o) Put all @Finder interfaces in selected packages and create a custom
scanPackage method that will do a selective class path scanning.

See how scan packages is done in Sitebricks or similar. I think full
blown classpath scanning is just plain evil. But I do selective class-
path scanning to great success i.e. register all @Entity from a
package, register all quartz jobs from a package etc.

Warp-persist works great. Still using it over guice-persist as it
provides the Hibernate Native support.

Cheers
Alen

[Deanna Bonds]

Thanks Alan.  My intention was to use the finders in concrete classes such as the service class.  I didn't realize that the guice-persist addFinder was just for interfaces, but that makes sense the way you described it.  I still think I will go with warp persist though.  It is better documented - well anything is better considering I can't find anything on guice-persist @Finder.