It looks like GWT has its own baked-in DI mechanism (GWT.create(Class<?>)). What benefits does GIN offer on top of this? Should you ever use them in conjunction with one another, or are they mutually exclusive? I like Guice so I'm tempted to use GIN, but don't want to introduce it if GWT already does the same stuff right out of the box.
Gin and GWT.create have a few differences - Gin is more about providing dependencies via the #Inject annotation, either on fields, setters, or the constructor, whereas GWT.create is specifically about obtaining an implementation. Gin will use any constructor you provide, but you must specifically provide the replacement type, whereas GWT.create will only work with a default constructor, and your 'rebind rules' don't need to be quite as precise, and can even cause new classes to be created at compile time. It also is able to look at what environment the user is running and select a specific set of rules based on that, which Gin is not able to do.
Gin actually makes use of GWT.create to get these other features - if you don't have a rule defined, Gin will call GWT.create automatically. This means if you have a rule like
#Inject MyRemoteServiceAsync rpcService;
Gin will call GWT.create to build that rpc call. This also works for UiBinder, Editor Drivers, I18n Messages and Constants, etc.
If you already understand and like Guice, Gin shouldn't be a big step for you, and you'll still have the ability to directly invoke GWT.create, or implicitly ask Gin to do it. In fact, in order to even use Gin, you need to call GWT.create(MyGinjector.class) to get the ball rolling.
GWT.create() has nothing to do with dependency injection. It's a factory method.
The only difference between GWT.create(SomeThing.class) and new SomeThing() is that the exact SomeThing class can be replaced or generated using so-called deferred binding. But there's nothing in GWT.create() about providing dependencies to the GWT.create()d object for instance.
Related
I have a component declared using the #Component annotation, in which there is a set of methods that implement communication with another api, in my product there are operations that are prohibited for a user with an anonymous id. I want to create an annotation, for example #ProhibitedForAnonym, which, every time the method is called, will check the ID of the anonymous customer, with the ID in the method parameter and throw an error if the IDs match. But I don't understand how to do annotation processing in OSGI, maybe some kind of interceptor?
There is no general interception framework in OSGi. However, you could do interception in the following ways:
Don't. Personally, I feel that since we've lambdas a code-based solution has won hands on over a 'magic' annotation check. It is about the same number of characters but a lambda based call allows me to single step, provide context to the security check, does not suffer from the THIS problem, is testable, and requires no complex framework with lots of bug opportunities.
Use the byte code weaving support in OSGi. You need to register a weaver early and then weave any class that has these annotations. You can take a look at https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.trace for an example of how to use the byte code weaver. Make sure your weaver is there first. If you use bndtools you can add it to the -runpath to run before anybody else. Or use start levels.
Use proxying. You can 'hide' and original service with the Service Hooks and then register a proxy. In the proxy you can then do the annotation check. This also requires that this code runs first and cannot be updated. I think the spec has an example of this
You might want to read: https://www.aqute.biz/appnotes/interceptors.html
I have a class that users will inherit from and implement two methods: navigateForwards() and navigateBackwards() (it's a wizard-like web application).
The user may want to add interceptors to these methods.
Another class (let's say it's part of a framework) will find the appropriate subclass, select() it and call the navigate(String) method which will call either navigateForwards() or navigateBackwards(). At that point interceptors won't work anymore since it's an unproxied method call. I could add interceptors to the navigate() method, but that's not the method subclasses are interested in overriding.
Is there an easy way to tell CDI to intercept a method that otherwise wouldn't be intercepted?
I came up with a couple of general approaches to solve this but none of them seems very promising:
Somehow get the proxy object that called me. That would require some sort of self-injection that replicates the select() call made in the "framework" class.
Get the list of interceptors for the method from CDI and call them manually. Somehow.
Use DeltaSpike's EnableInterceptorsProxyFactory http://deltaspike.apache.org/documentation/proxy.html to wrap this. That could be slow and/or uncover other limitations.
There may be another option with CDI extensions, but I'm not sure what an extension is capable of.
I've already tried turning everything upside-down and using decorators instead of a base class in the hopes that a call to the delegate object would get intercepted but it didn't, at least not in JBoss EAP 6.x (most likely 6.4, but it could be an earlier version when I tested).
The simplest solution I found (which for some obscure reason hadn't occurred to me before) is making navigate() static and passing the object explicitly (e.g. as self).
Looking from the outside the class gets a bit weird since it looks like it could have a regular non-static method but has a static one. OTOH it does the job and is easy to understand. I needed the current proxy object so I passed it in. It's trivial and it keeps interceptor behavior.
There are just a few calls that have to be changed in my project, but other projects will have different needs so it isn't a general solution unfortunately. That's why I am not accepting my own answer.
I am relatively new to Guice, so this may be basic question. It looks like Guice has the option to require explicit bindings. Is there any clear advantage to requiring explicit bindings? Does anyone regularly use this option in practice?
We use this option in practice. We use Guice only to wire our application together, not for any sort of per-request object construction. As a result, most of our bindings are in Singleton scope - we want, for example, our business logic and statistics interfaces to both work off the same persistence layer object.
In the absence of an explicit binding, Guice will attempt to satisfy the injection point using a JIT binding. This binding will be done in the "no scope" scope, which provides a fresh object instance to each injection point. That's almost never what we want, and leads to bizarre runtime errors. Forcing explicit bindings forces people to think about, and enumerate, the scope of each of their bindings.
I recently sat through a 1-hour debugging session because we didn't use this config. The problem was that multiple instances were created when I expected a singleton by default. Forcing an explicit binding is a good reminder to think about whether it should be a singleton or not.
I too spent few hours in debugging. The reason was that I forgot to add a binding of a concrete class to singleton scope. In order to have explicit bindings always, I used one answer from How do you prevent Guice from injecting a class not bound in the Module? (not the current chosen one): binder().requireExplicitBindings(); (in the configure method of AbstractModule).
I need to intercept the calls to all the method calls to an Interface. I've gone through the Java Dynamic Proxies however that will not help me. I'm not even sure whether this can be achieved, but thought of confirming.
So basically lets say i have an interface as follows:
public interface Foo {
public String getValue();
}
I would like to intercept all the calls to getValue() from whichever implementations of Foo. Problem is i do not have control over the different implementations of Foo, because of which i cant use Dynamic Proxies.
Is there a way i can do this?
Thanks.
AOP might help, but as you've discovered, it all gets much easier if you're in control of the object creation (even if only through a DI framework like Spring or Guice).
Another alternative is compile-time byte-code weaving - that is, finding all implementations and altering them to have your interception code in them at compile time.
A third alternative would be to look at using either an agent or a custom classloader to do weaving as the classes are loaded into the system. This is load-time weaving. But if you're in, say, a web container where you're not fully in charge of the classloaders, this might be tricky.
The only way to do this would be with a custom classloader that replaces the implementation classes with a proxy.
It might be possible to do this out-of-the-box with Spring AOP's load-time weaving.
I'm using Guice to route requests in my web app, and I'd like to modularize the routing of some of the URL patterns I'll be handling. Ideally, I'd like to be able to do something like this in my ServletModule:
delegate("/foo/bar/*").to(SomeOtherServletModule.class);
// in SomeOtherServletModule.configureServlets:
serve("/foo/bar/quux").with(Quux.class);
Or even better:
delegatePrefix("/foo/bar/").to(SomeOtherServletModule.class);
// in SomeOtherServletModule.configureServlets:
serve("/quux").with(Quux.class); // prefix removed
Is this possible in Guice? It seems that Guice tries really hard to make the bindings installed by ServletModules a singleton, which is in turn stored who-knows-where by GuiceServletContextListener to be used by GuiceFilter, but I'd like to un-singleton this so I can delegate like this, instead of having everything tightly bound in a single function.
I am the creator of Guice Servlet. This is basically not allowed as you are describing, as we felt it would be confusing for modules that are not intended to be used this way.
For example, many modules contribute filters that register at "/*" to provide some interception functionality (such as transactions). These could accidentally stop working if you auto-prefixed them. Given that servlet modules can be transitively installed, this is not as simple as being vigilant about one piece of code. Also, with regex bindings (example: /\.html$/), how does one handle prefixes? Do we support them (difficult problem)? Or do we simply register regex bindings normally and make a surprising exception for them?
Considering that what you're asking for is trivially achieved with a constructor in SomeOtherServletModule("/myprefix") that knows how to map itself correctly, we decided not to provide this functionality.