Re: Integration with Java dependency injection frameworks?
Erm ... a MOOC? On Tue, Oct 1, 2013 at 9:14 PM, Marshall Bockrath-Vandegrift llas...@gmail.com wrote: Hi all: I was wondering – does anyone have any experience with or patterns for integrating Clojure with existing Java dependency injection frameworks? I’m working with the LensKit framework [1] for a MOOC and it uses a JSR-330/javax.inject dependency-injection framework named `grapht` [2] for, well, everything. In some examples dependency-injection is even used to provide input data file paths (!). As far as I can tell, the injection happens entirely via invoking some sort of concrete, user-provided, annotated constructor which accepts injected instances on (potentially annotated) constructor parameters. My thoughts thus far have centered on two basic potential approaches: 1. Implement small Java stubs with appropriately-annotated constructors for every injection point. The downside is that these stubs are (probably) not very reusable. Injected instances are only injected at the constructor parameters, so needing a different set of injected instances requires a different class/constructor. 2. Dynamically generate stub classes exposing constructors which accept some arbitrary per-class set of inject-able parameters. There might be an easier way to do it, but that’s the approach I’ve tried out thus-far using ASM and the Clojure dynamic class loaders to produce “Provider” factory classes: https://github.com/llasram/esfj The largest problem with this approach is that the actual factory implementation still needs to be injected somehow. I thought about stashing a function in a Var linked to the class, but have instead just made the implementation function itself another inject-able IFn parameter. This avoids namespace-abuse, but also means injecting Clojure implementations involves doing *more* dependency injection than with plain Java, which doesn’t seem right. Thoughts? [1] http://lenskit.grouplens.org/ [2] https://github.com/grouplens/grapht -Marshall -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Integration with Java dependency injection frameworks?
Cedric Greevey cgree...@gmail.com writes: Erm ... a MOOC? Massive Open Online Course – e.g., Coursera, edX, Udacity, etc. This is for the Coursera-offered version of the University of Minnesota course on recommendation systems, but that didn’t seem particularly relevant to the problem at hand. -Marshall -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Integration with Java dependency injection frameworks?
Hi all: I was wondering – does anyone have any experience with or patterns for integrating Clojure with existing Java dependency injection frameworks? I’m working with the LensKit framework [1] for a MOOC and it uses a JSR-330/javax.inject dependency-injection framework named `grapht` [2] for, well, everything. In some examples dependency-injection is even used to provide input data file paths (!). As far as I can tell, the injection happens entirely via invoking some sort of concrete, user-provided, annotated constructor which accepts injected instances on (potentially annotated) constructor parameters. My thoughts thus far have centered on two basic potential approaches: 1. Implement small Java stubs with appropriately-annotated constructors for every injection point. The downside is that these stubs are (probably) not very reusable. Injected instances are only injected at the constructor parameters, so needing a different set of injected instances requires a different class/constructor. 2. Dynamically generate stub classes exposing constructors which accept some arbitrary per-class set of inject-able parameters. There might be an easier way to do it, but that’s the approach I’ve tried out thus-far using ASM and the Clojure dynamic class loaders to produce “Provider” factory classes: https://github.com/llasram/esfj The largest problem with this approach is that the actual factory implementation still needs to be injected somehow. I thought about stashing a function in a Var linked to the class, but have instead just made the implementation function itself another inject-able IFn parameter. This avoids namespace-abuse, but also means injecting Clojure implementations involves doing *more* dependency injection than with plain Java, which doesn’t seem right. Thoughts? [1] http://lenskit.grouplens.org/ [2] https://github.com/grouplens/grapht -Marshall -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
