I'm using void afterUnmarshal(Unmarshaller unmarshaller, Object parent) in my beans and have got the complier set to fail if parameters are not used.
The compiler seems to be okay with unused parameters if I override a superclass/interface that has a javadoc for the param.
But I can't find any class to override the afterUnmarshall method. Is there no unmarshaller interface or something like it to solve this problem?
There is not interface provided with the JAXB APIs. We designed it this way so that you could add just one of afterUnmarsal or beforeUnmarshal if you wanted. You could solve this issue by introducing your own interface:
package com.example;
public interface UnmarshallerListener {
void afterUnmarshal(Unmarshaller unmarshaller, Object parent);
}
Related
Trying to clean up some nasty code, for which we dont have the source code. Imagine something like this:
public class Driver{
private String paramA;
private String paramB;
new Driver(HugeAndOverbloatedObject object)
{
paramA = object.getSubObject4711().getParamX();
paramB = object.getSubObject4712().getParamY();
}
}
This third library has this all over the place: tight coupling via constructors, eventhough the classes are hardly related. The rude combination of private members and forced constructor inheritance make the extension of the code virtually impossible without creating "sloppy" constructor parameter objects.
So I am trying to manipulate the classes via AspectJ and compile time weaving, so I can slim down on the constructors, to something like this:
Driver driver = new Driver("paramA", "paramB");
I think this should be possible, and I have made some progress. If I have something like this:
public aspect NewConstructor {
Driver.new(String parameterA, String parameterB){
//New Constructor Code
}
}
and run this through the weaver I actually find a new constructor in the driver, but not quite as I expected.
Issue: Unexpected third Parameter in the woven class
I was hoping I can invoke it with two parameters:
new Driver("paramA", "paramB")
Instead I need to invoke it with three parameters:
new Driver("paramA", "paramB", new NewConstructor())
Why do I need to instantiate a new instance of the aspect and pass it as an argument? Can this be prevented?
Something odd is going on here. You should not need to add the aspect as a third argument to the constructor. In fact, when I try this myself using the following class and aspect, I do not get any compile errors:
Java class:
package pack;
public class Driver {
public static void main(String[] args) {
new Driver("paramA", "paramB");
}
}
Aspect:
package pack;
public aspect NewConstructor {
public pack.Driver.new(String parameterA, String parameterB){
}
}
Are your Java class and aspect in different projects? Are you using an aspect path and/or in path? Are you using load time weaving?
If after doing a full build of your project you still see the probem, it's worth raising a bug for AspectJ.
I'm a bit lost with the use of Inject on variable.
I got this code working :
private XXServiceAsync xxServiceAsync;
#Inject
protected IndexViewImpl(EventBus eventBus, XXServiceAsync tableManagementServiceAsync) {
super(eventBus, mapper);
this.xxServiceAsync = xxServiceAsync;
initializeWidgets();
}
With this code, I can call my RPC service wherever I need in the class (On click ...)
I would like to clear a bit the code by injecting direcly in the variable ; doing so :
#Inject
private XXServiceAsync xxServiceAsync;
protected IndexViewImpl(EventBus eventBus) {
super(eventBus, mapper);
initializeWidgets();
}
This always keep the Service to NULL.
Am I doing something wrong ? Is the GIN magic with rpc services meant to be done otherwise?
Thanks!
It is still null at that point, because Gin (and Guice, and other frameworks like this) cannot assign the fields until the constructor has finished running.
Consider how this would look if you were manually wiring the code (remember that Gin/Guice will cheat a little to assign private fields, call non-visible methods):
MyObject obj = new MyObject();//initializeWidgets() runs, too early!
obj.xxServiceAsync = GWT.create(xxService.class);
If you need something in the constructor, pass it into the constructor. If you wont need it right away (such as until asWidget() is called), then a field or setter annotated with #Inject can be helpful.
If you have field level injection you can use an empty #Inject method to do your post-inject initialization. The no-arg injected method will be run after field injections on the class are complete.
#Inject void initialize(){
...
initializeWidgets()
}
Edit: I previously stated that it was run after method injection as well, but testing shows that this is not always the case.
I've try to expose to the client(gwt) an aspectJ method through gwt-rpc, but the gwt client can't find the method defined in an aspect. The class that i expose implements IsSerializable and only it's method are visible to the client interface...the method added by their aspect contrariwise no. How i can fix this? thanks in advice.
p.s. i post a little example for more clarity:
this is the class...
public class Example implements IsSerializable{
private String name;
public setName(String name){
this.name=name
}
}
and this is the aspect...
privileged aspect Example_x{
public int Example.getVersion() {
return this.version;
}
}
The Example.getVersion() method is unavailable on the client side.
TNX
This won't work, as GWT needs access to the source of any Java class that is exposed to the client side. This is necessary to compile them from Java to Javascript. If you modify your classes using AspectJ, the added methods will not be visible to the GWT compiler and therefore not to the client.
I'd say AspectJ is simply the wrong tool for this task. If you want to add some methods to existing classes you could write a (possibly generic) container class that contains an instance of Example as well as the version information from Example_x.
I have a new project where I am using GWT-Views like Composite, etc.
I have injected the items in the main menu (like ProductList below) using GinInjector. This works fine!
Somewhere I want to have a reference from a small component to an item from my main menu in order to update it. I try to inject it this way:
public class ProductForm extends Composite {
...
#Inject
ProductList list;
....
}
But when I use the list I always get null. Whereby, ProductList is defined this way:
public class MyModule extends AbstractGinModule {
...
#Override
protected void configure() {
bind(ProductList.class).asEagerSingleton();
bind(ProductForm.class).asEagerSingleton();
}
...
}
Any idea what I am doing wrong?!
Solution:
I failed to mention that ProductForm is an element of the ProductList using the UIBinder's #UIField tag, So That injecting it will create a new object rather than the one created using UIBinder.
I had to restructure my code to include presenters and an event bus so that no direct references between views are needed (other than the #UIField attributes).
I was working through Gin documentation : I'll quote it here :
Gin "Magic"
Gin tries to make injection painless and remove as much boilerplate from your code as possible. To do that the generated code includes some magic behind the scenes which is explained here.
Deferred Binding
One way Gin optimizes code is by automating GWT deferred binding. So if you inject an interface or class1 bound through deferred binding (but not through a Guice/Gin binding), Gin will internally call GWT.create on it and inject the result. One example are GWT messages and constants (used for i18n purposes):
public interface MyConstants extends Constants {
String myWords();
}
public class MyWidget {
#Inject
public MyWidget(MyConstants myconstants) {
// The injected constants object will be fully initialized -
// GWT.create has been called on it and no further work is necessary.
}
}
Note: Gin will not bind the instances created through GWT.create in singleton scope. That should not cause unnecessary overhead though, since deferred binding generators usually implement singleton patterns in their generated code.
You can see for yourself in this URL : http://code.google.com/p/google-gin/wiki/GinTutorial
It fails to mention why a singleton cannot be autogenerated by deferred binding and injected.
You can fix this by handcreating, using GWT.create(YourFactoryInterface.class).getProductList() in the constructor.
This means for testing puposes, you will need to pull the GWT.create into a seperate method and override it in a subclass and use that for testing like :
YourFactoryInterface getFactory() {
return GWT.create(YourFactoryInterface.class)
}
and
getFactory().getProductList()
Gin's asEagerSingleton() binding was broken for quite a while, and was injecting null. Not sure when the fix went in, but I had problems with eager singletons on v1.0. See the issue or the explanation, if you're interested. I'd either switch to regular .in(Singleton.class) bindings, or make sure you're using Gin 1.5.
Is the Ginjector creating the ProductForm? I think maybe that is needed to make it populate the injected variable.
I have java class with protected static method:
package parent;
public class Parent {
protected static void parentMethod() {
System.out.println("I'm in parent static method");
}
}
Before Scala 2.12.4 (2.12.3) I could call this method from another package like this:
package child
import parent.Parent
class Child extends Parent {
def childMethod = {
println("I'm in child method and calling parentMethod")
Parent.parentMethod()
}
}
But Scala 2.12.4 does not compile this code. I'm getting the error:
Error:(9, 12) method parentMethod in object Parent cannot be accessed
in object parent.Parent Access to protected method parentMethod not
permitted because prefix type parent.Parent.type does not conform to
object Child in package child where the access takes place
Parent.parentMethod()
This access pattern was very important for me because JOOQ code generation uses this.
What happened?
Nice catch, this is most likely a regression introduced by this PR, as part of a solution to this issue.
I've already opened a ticket for this that you can track. In the meanwhile, if this kind of access pattern is vital for your application, unfortunately I don't think you have much choice but to stick to Scala 2.12.3 for the time being.
Edit
The issue was already known and a fix has been already merged. As of the time of writing the patch is bound to be part of the 2.12.5 release.