I've run into an interesting problem while developing an ORM framework for Android. I'm using a library called dexmaker for bytecode manipulation, which enables me to create proxies for persistent objects in order to implement lazy loading.
The proxied instance has an associated InvocationHandler such that when a method is called on the proxy, the invoke method is called on the InvocationHandler, which then calls the proxied object's respective method assuming it's been lazily loaded. Nothing too surprising -- it's just like Java's Proxy class but allows me to proxy actual classes instead of interfaces (see dexmaker's ProxyBuilder).
The part that's become problematic is that I also use reflection to retrieve field values from persistent objects and -- now that I've introduced lazy loading -- proxies. Here is what I'm currently doing:
for (Field f : getPersistentFields(model.getClass()) {
...
Object val = f.get(model); // model is either a persistent object or a proxy for one
mapField(f, val, map);
}
This of course works for regular model instances, but for proxied instances, f.get(model) is not retrieving the proxied object's field value. Instead, it's returning the default value assigned in the class's constructor. The access on the proxy's field is not being intercepted obviously.
My question is this: is there any way I can intercept an access on a proxy's member variable made through reflection? If not, how can I retrieve the value of a proxy's field in a "reflection-like" way?
One possible workaround I'm thinking of would be to retrieve and then invoke the field's getter method using reflection, but I'm wondering if there's a more direct solution. This workaround, if it actually works, would require the object to have a getter method for all persistent fields -- a requirement that should typically be followed from an OO-design point of view but also forces more work onto the user of the framework.
I'm open to any ideas.
A good solution is to access the fields using setter/getters rather than using Field class. (I believe this is more than a workaround)
On the other hand, if you want to go with the direct field accessing approach. As far as I see there is no easy way to intercept field accesses. Please check the answers to this question. Altough the question is related with intercepting field modification rather than reading
the field, it may provide some insights and direction.
Related
I am trying to use bytebuddy to intercept getfield and putfield accesses. I have read the rather comprehensive documentation on the site, but from what I can understand, it covers adding getters and setters to fields, rather than intercepting field accesses.
Here is basically what I am trying to do:
...
obj.prop = value;
x = obj.prop;
...
That in both these cases, I am trying to have some method called (or some bytecode inserted) before/after the field access. I was thinking of using Advice to do it, but I am unable to find a way to have it for something other than methods.
Edit:
I am using a Java Agent to do it.
I had an idea of adding a dup to duplicate the object reference followed by the call to a static method I defined to intercept the access (I only care about the object being referred to, not the field).
There is a new component that is still under development but that is already exposed with a basic API. It is called MemberSubstitution and allows you to replace a method call or field access with another execution.
This component does however rely on replacing the code that executes an instruction. Field access is non-virtual, therefore it is not possible to create any proxy class that would intercept a virtual access. Instead, you have to redefine any existing class that reads or writes the field, for example by using a Java agent.
As for your more specific question: At the moment, there is only a 1-to-1 substitution possible. I have not yet had the time to include a mechanism for adjusting the stack and local variable sizes. Also, you would also have to dup objects lower down on the stack if the field is non-static. The problem is not trivial so to say but I hope to offer such functionality some day.
At the moment you can however replace the field access with a static method call. Possibly, you can execute the original field operation from this method.
Looked at using CGLib, ASM, BCEL (aspect) and Javassist to add a field to a class during runtime....
Just to get my head straight it looks like these bytecode manipulators don't update the actual class rather allow the user to only dump the modification (like with CGLib and the writeFile method). Was hoping I would find a solution that (a) loaded the class (rather than doing an InputStream with BCEL) and (b) updated the class.
Maybe this is normal? Do people usually create a proxy and pass the proxy around?
What I want to do is to add a field (note: not a property via get/set methods) before passing the object along to a framework that looks for fields (not properties) with a particular annotation. So "clients" are creating my target classes that I want to inject with an extra field. Intercepting with AOP calls to a service layer where I want to manipulate these objects.
You can redefine classes with Intrumentation. However a common limiation is that you cannot change the fields used. This is because you cannot change the contents of a object (or add to it) once it has been created.
In your case you can,
create a proxy as you suggest, however proxies need to be interfaces.
create a subclass which has the additional field(s)
add the field before the class has loaded.
I've read documentation, but there is no definition of the main purpose of Dynamic Bean. I understand how to implement this but dont know why this approach so good.
So could someone tell the situation when it's good to use Dynamic Bean?
Thanks
Dynamic beans typically allow you to get and set fields which may not be explicit members. The most direct comparison is a map - maps allow you to get and set fields without defining them beforehand. However, a dyanamic bean conforms to standard java idioms (getters/setters).
Unlike a hashmap, however, dyanbeans can enforce constraints more readily (and they hide the underlying data structure implementation, so they can be lazy, or make data connections when being set, etc... ) . For example, you can easily add a getter or setter to your dynabean that is explicit, and the code would read very idiomatically and cleanly interact with other bean apis.
public int getCost()
{
if(this.get("cost")==null)
return -1;
return Integer.parseInt(super.get("cost"));
}
The most useful part about dynamic beans in ATG is providing additional DynamicPropertyMapper classes for classes that aren't already covered by it. First, note that you can use the DynamicBeans.setPropertyValue(object, property, value) and DynamicBeans.getPropertyValue(object, property) static methods to set or get properties on an object that don't necessarily correspond with Java bean properties. If the object you're using isn't registered with dynamic beans, it'll try to use Java bean properties by default. Support is provided out of the box to do that with repository items (properties correspond to repository item properties; also applies to the Profile object, naturally), DynamoHttpServletRequest objects (correspond to servlet parameters), maps/dictionaries (correspond to keys), and DOM Node objects (correspond to element attributes followed by the getters/setters of Node).
To add more classes to this, you need to create classes that extend DynamicPropertyMapper. For instance, suppose you want to make HttpSession objects work similarly using attributes with a fallback to the getters and setters of HttpSession. Then you'd implement the three methods from DynamicPropertyMapper, and the getBeanInfo(object) class can be easily implemented using DynamicBeans.getBeanInfo(object) if you don't have any custom BeanInfo or DynamicBeanInfo classes for the object you're implementing this for.
Once you have a DynamicPropertyMapper, you can register it with DynamicBeans.registerPropertyMapper(mapper). Normally this would be put into a static initialization block for the class you're writing the property mapper for. However, if you're making a property mapper for another class out of your control (like HttpSession), you'll want to make a globally-scoped generic service that simply calls the register method in its doStartService(). Then you can add that service to your initial services.
AFAIK JSR-303 is the standard bean validation system.
I don't know whether it could do validations like this (I guess no):
if an object has a deleted flag set, you cannot modify the object
you cannot change the start date property, after the date is passed
you cannot decrease some integer properties in the bean
So how can I handle validations, which depend on the previous state of an object?
I would like to solve problems like that in hibernate3.5 - spring3 - JPA2 environment.
Thanks
My solution was to mess with hibernate, reload the object to see the old state (after evicting the new object). This time I need some smarter solution...
I don't think this can be done using JSR 303 validation (or any other validation framework I've used). Validation is usually stateless - you pass it an instance of an object, and your validation framework tests things to make sure the current values of your object are valid. There's no real knowledge of previous states of the object.
You can do this - just not with validation. You could use a constrained property, or you could make this work using the proxy pattern or AOP.
It sounds like the fields which you want to validate (with regards to previous state) are all metadata about the records as opposed to real data. All of these fields (idDeleted, createdDate, etc.) are better left out of your domain layer and therefor do not require validation. I would put the logic for determining & setting these values in you data-access layer so that the systems using your repository interfaces do not need to know or care about getting them right.
If my assumption about these fields being meta-data is not correct and you have user-entered data which validation depends on previous state, then I do not think that an extra lookup for the previous values is absurd and should not be out of the question. It makes sense in your case. Hibernate itself does a lookup under then hood to determine whether to INSERT or UPDATE when using it's save function.
Hope you find a reasonable solution.
how can I handle validations, which depend on the previous state of an object?
I'm not 100% sure it's doable but the only way I can think of would be to create an object graph made of the "new state" and the "old-state" (transient) and to validate the object graph as a whole using custom constraints. That's at least what I would try.
I would probably create a transient field that says previous version which points to a copy of the data that represents its previous state. This object is created on construction but since it is marked as transient it is not serialized. Then do the validations against it.
Simplest implementation would be to add a method called makeACopy() which makes a copy of the object and put it into the field.
You can add complexity by implementing Clonable or creating a utility class that would do reflection, but that's up to you. I suggest makeACopy() and refactor later since it is easier to think about.
I don't know any ready-to-use solution either. As you suspect JSR-303 won't do the job, because it's validation is 'static'.
But...
An idea would be to use some AOP techniques to do that. So...
if an object has a deleted flag set, you cannot modify the object
This one I would implement as a proxy method registered around every setter. The proxy method would check the 'deleted' flag. If it was set to true, an exception would be thrown, otherwise the original method would be executed.
you cannot change the start date property, after the date is passed
This one is similar. This time you wouldn't access any other property in the intercepted setter, but the original (not changed yet) value of the field and setter argument.
you cannot decrease some integer properties in the bean
That one is the same as with the dates, the only difference is the date type (date vs integer).
One can argue if AOP is a good choice for this task, but still a solution. I am doubtful too.
One more concern is that I guess you would want to enforce these contraints on JPA entities. So using Spring AOP wouldn't be that easy, since the entities wouldn't be Spring managed.
A completely different approach is to put the validation checks into the setters of properties. The downside is that you would lose declarativeness.
Example:
public void setCounter(int newCounter) {
if (newCounter < this.counter) {
throw new IllegalOperationException("Cannot decrease the counter");
} else {
this.counter = newCounter;
}
}
You might want to look at OVal instead. We do this kind of validation all the time. Normally, it's done using the SimpleCheck where you get the object and the value and can do all kinds of cross-checking.
When using Spring AOP to create a proxy for a class using NameMatchMethodPointcutAdvisor and BeanNameAutoProxyCreator does this essentially proxy every call to the object, but only apply the advice to the matched methods, or somehow create a Proxied object that only has those methods and uses the normal object for the calls that are supposed to be intercepted?
The way, I think I understand it is that it does proxy every call to the object but then only calls the Advisor on the methods that match - but I can't find a good example/post to confirm this.
Depends on the technique used. (It is configurable by an attribute proxy-target-class in your aop config)
JDK dynamic proxies are proxies by interface - each methods of the interface goes through the proxy, as you said, and if it matches happens to be an "advised" method, the advisor is applied. Otherwise it is delegated to the original object
CGLIB proxies are effectively subclasses defined at runtime of your concrete classes. I can't be sure in this, but I assume only the "advised" methods are overridden, the rest retain the definition of the superclass.
However, no matter which mechanism is used:
it isn't your concern how exactly are the proxies implemented
this doesn't impact performance in a significant way - Debunking myths: proxies impact performance by the Spring team about proxy performance myths
or somehow create a Proxied object that only has those methods and uses the normal object for the calls that are supposed to be intercepted?
How would this actually work? When a class has a reference to the class that is being proxied, it only has one reference to it. It either has to invoke a proxy class or a non-proxied class. Spring can't know which methods you are calling and therefore can't give you one type if you need to call the advised method and another type if you're not.