the benefit is fairly straight forward: you don't have to inject a
`ResourceEnvironment` instance, and we lose a little bit of code
duplication by centralizing the place where the resource-loading flow
starts and finishes.
That same object is the one that offers the ability to load native code
through JNA, so its a fairly scary object. If it becomes too scary we of
course have the option of hiving that complexity off into a new class, a
`NativeResourceLoader` and the regular `ResourceEnvironment`, but I just
thought the ability to push the actual loading of resources out of a
constructor and into guice would be handy.
And I would think that this would be a handy feature for deep
configuration: if the type isn't a uniquely identifying feature, the
ability to make runtime decisions about static configuration through
annotations seems really handy and not likely to break much (whose going to
be binding instances of annotations to things?) In my case, a static image
resource can be identified by a path similar to
"/com/ourcompany/whatever/someimage.png".
On Sunday, October 18, 2015 at 7:30:06 AM UTC-7, Tim Peierls wrote:
>
> What benefits would this have over what I imagine your colleagues are
> doing?
>
> public interface ResourceEnvironment {
> Image getImage(String name);
> // ... other resource-providing methods ...
> }
>
> public class SomeService {
>
> private final Image image;
>
> @Inject public SomeService(ResourceEnvironment env){
> image = env.getImage("/com/mycompany/myasset.png");
> }
>
> //big complex methods doing big complex method things.
> }
>
> //with a module containing
> public class ModuleToDoThat implements Module{
> public void configure(){
> //...
> }
>
> @Provides ResourceEnvironment getResourceEnvironment() {
> return new ResourceEnvironment() {
> @Override public getImage(String name) {
> return toImage(getClassLoader().getResource(name));
> }
> Image toImage(URL url) { ... }
> // ... implement other resource-providing methods ...
> };
> }
> }
>
>
> On Sun, Oct 18, 2015 at 1:18 AM, Geoff Groos <[email protected]
> <javascript:>> wrote:
>
>> Hey guys,
>>
>> So it's occurred to me that a number of classes in our codebase are
>> injecting a so called 'ResourceEnvironment' so they can use it to retrieve
>> a static image from whiten our deployed jar. This got me wondering if I
>> could achieve something as slick as injecting the image directly with guice:
>>
>> public class SomeService{
>>
>> private final Image image;
>>
>> @Inject
>> public SomeService(@Named("/com/mycompany/myasset.png") myAssetImage){
>> image = myAssetImage;
>> }
>>
>> //big complex methods doing big complex method things.
>> }
>>
>> //with a module containing
>> public class ModuleToDoThat implements Module{
>> public void configure(){
>> //...
>> }
>>
>> @Provides Image getImageWithName(Named name){
>> return getClassLoader().getResource(name.value());
>> }
>> }
>>
>> This would actually reduce a fair bit of code on our code base; using
>> annotations to pass meta-data about the specific instance that's needed *at
>> runtime* would be a really cool feather for guice's cap.
>>
>> AFAIK the feature I'm requesting is binding annotations to be whitelisted
>> (along with the calling Injector) as things that you can request without
>> providing an explicit configuration path for them. A little less obtusely:
>> with the injector you don't need to tell guice how to provide a provider
>> method with an injector, it just assumes the injector you're looking for is
>> the one doing the provide-ing. I would ask that binding annotations be
>> given the same 'scope', such that any binding annotations used would be
>> automatically wired to that provider method (and if they don't exist, the
>> provider methods eligibility for provision removed).
>>
>> Needless to say this is a fair bit of rope to hang yourself with, in the
>> event that you need to start passing more information than is available at
>> annotation-writing-time, some developers (myself included) might try to
>> ham-fist some things into static scope so that they can be used by the
>> annotation. That said, I think the benefit outweighs the cost; it would be
>> really slick and cut 50 lines of cruft off my codebase.
>>
>> I'm *fairly* certain I could hack something together with provision
>> listener and a stack (probably static), but rather than go down that road I
>> figured I should post this as a request-for-help and/or a feature request
>> here first.
>>
>> Is there a way to do this without using the SPI that would give me the
>> same effect? If I was to try to do it myself with a stack and a provision
>> listener, would it be as hard as I think it is? Is this something I should
>> request a little more formally (by creating a github issue)?
>>
>> cheers,
>>
>> -Geoff
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/google-guice.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-guice/882e5b98-a32a-4f5a-a47f-02b4fc8d117b%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/google-guice/882e5b98-a32a-4f5a-a47f-02b4fc8d117b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/a9537919-b7b3-43a0-af60-7463f8d54f0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
