I'm using Lombok in a Spring Boot application, The MongoDB object are the same as my domain model so when I do the mapping I have to specify all the field names even they are the same
public static Receipt toModel(MGReceipt mgReceipt) {
return Receipt.builder()
.id(mgReceipt.getId())
.date(mgReceipt.getDate())
.dueDate(mgReceipt.getDueDate())
...
.build();
}
Is there a way to simplfy this , and avoid to specify all the properties names from MGReceipt that match Receipt ones, with Lombok ? or maybe I should use another solution for the mapping like mapstruct
That's exactly what MapStruct was created for. MapStruct also plays quite nicely with lombok, as described here. Also lombok's #Builder is supported, if you want that.
Make sure you use recent versions of both lombok and MapStruct, and don't forget to add the lombok-mapstruct-binding as a third annotation processor to make sure MapStruct can see everything that lombok generates.
I'm not aware of any easier/nicer framework to do such a mapping. There's also no nice way of doing it manually, as that would require some nasty reflection stuff to identify similarly named fields/getters/setters.
Related
I'm trying to create a custom annotation processor that generates code at compilation time (as hibernate-jpamodelgen does). I've looked in the web, and I find custom annotation processors that works with maven, but do nothing when added to the Annotation Processing > Factory Path option. How could I create a processor compatible in this way? I have not found a tutorial that works.
My idea is to, for example, annotate an entity to generate automatically a base DTO, a base mapper, etc that can be extended to use in the final code.
Thank you all
OK, Already found out the problem. The tutorial I hda found out dint't specified that, in order to the compiler to be able to apply the annotation processor, there must be a META-INF/services/javax.annotation.processing.Processor file that contains the qualified class name of the processor (or processors).
I created the file pointing to my processor class, generated the jar and added it to Annotation Processing > Factory Path and all worked correctly.
Just be careful to keep the order of the processors correctly (for example, hibernate model generator claims the classes, so no more generation will be made after it), and change the jar file name each time you want to replace the library (it seems eclipse keeps a cache). These two things have given me a good headache.
Thanks all
I'm extracting JPA entities into a separate Fat/Uber jar for external system to use.
ProGuard is used through com.github.wvengen:proguard-maven-plugin to shrink all other unused code.
I want to keep all methods in JPA entities except ones annotated by #javax.persistence.Transient annotation. I've found "!transient" for field modifiers in ProGuard rules, but seems that !#javax.persistence.Transient for methods does not work :(
Can I reach the same effect somehow for methods by other way ?
Unfortunately I've not got an answer on this question and was not be able to solve this by ProGuard+MavenPlugin directly, but I've resolved this problem with one additional step before run a ProGuard. I've just used ByteBuddy + Maven plugin on Maven phase before you run ProGuard Maven plugin and it will then optimize/remove the rest unused stuff, see details about byte-buddy instrumentation step here: byte-buddy remove/strip methods
I was looking at this wonderful mybatis example
http://mybatis.co.uk/index.php/2010/09/mybatis-simple-and-complete-example.html
that uses mostly annotations but was hoping for an #MyBatisDao annotation so I don't need to ever go back to some mapping file and add a line for each dao that I add to the system. I obviously will just use mapping for now but was just curious if there was a way???
You can use the package element to let it scan for your mappers (since 3.1)
MyBatis 3.1 Reference Guide
My name is Denis and I really need your help or advice or anything :)
I am developing my project in Zend Framework 1.11 and am using Doctrine 2.1.
I have successfully integrated Doctrine in my ZF project and everything works. I also integrated Gedmo extensions and some my custom extensions.
The problem is with validation. I want to have validation of doctrine entities by using annotations. Because I sometimes need to validate my entities sometimes don't, I want that sort of validation, for example:
$user = new Entity\User; $user->setName('user'); $user->validate();
I don't want to change doctrine generated entities at all, so I won't change setters or use doctrine events for this.#HasLifecycleCallbacks.
I run into example at http://www.spiffyjr.me/2011/07/15/more-doctrine-2-and-zend-framework-integration-goodies/.
I downloaded code but didn't managed to put it in work. I followed instructions from that page, made my entities extend AbstractEntity, but when try to use for example isValid() i recieve following error:
[Semantical Error] The annotation "#Column" in property Bild\Entity\TestTest::$id was never imported. Did you maybe forget to add a "use" statement for this annotation?
I use doctrine annotations without #ORM\, just #, (for example #Column, not #ORM\Column). I even tried to add ORM but no luck it continues to throw errors.
I can recieve metadata for my entity, get field mappings and associating mappings, but when I try to getPropertyAnnotation
// validator annotations
$vAnnotations = self::_getPropertyAnnotation($property, self::ZENDVALIDATION);
var_dump($vAnnotations);die;
I recieve mentioned semantic error.
I tracked the errors down to Doctrine\Common\Annotations\AnnotationReader::getPropertyAnnotations($property); not returning annotations but throwing errors.
What do you think it can be?
It seems like I am not doing something properly but can't figure out what.
So, I need to make abstract entity, make my entities extend it, and make functions to validate my entities by using annotations.
So please, help me with this, if you can. I really need for my project but couldn't find a solution.
Thanks in advance.
Best regards.
The problem is caused by the configuration of the annotation reader. I went through the same problems while integrating the Symfony2 validator service for my Doctrine2 models in ZF1, more on the blog post here http://ssmusoke.wordpress.com/2012/03/04/doctrine-2-day-2-model-validation-using-symfony-validator-service-in-zend-framework/
We are trying to use RequestFactory with an existing Java entity model. Our Java entities all implement a DomainObject interface and expose a getObjectId() method (this name was chosen as getId() can be ambiguous and conflict with the domain object's actual ID from the domain being modeled.
The ServiceLayerDecorator interface allows for customization of ID and Version property lookup strategies.
public class MyServiceLayerDecorator extends ServiceLayerDecorator {
#Override
public Object getId(Object object) {
DomainObject domainObject = (DomainObject) object;
return domainObject.getObjectId();
}
}
So far, so good. However, trying to deploy this solution yields runtime errors. In particular, RequestFactoryInterfaceValidator complains:
[ERROR] There is no getId() method in type com.mycompany.server.MyEntity
Then later on:
[ERROR] Type type com.mycompany.client.MyEntityProxy was previously marked as bad
[ERROR] The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
[ERROR] Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:212) ~[gwt-servlet.jar:na]
My question is - why does the ServiceLayerDecorator allow for customized ID and Version lookup strategies if RequestFactoryInterfaceValidator is hardcoding the convention of getId() and getVersion()?
I guess I could override ServiceLayerDecorator.resolveClass() to ignore "poisoned" proxy classes but at this point it seems like I'm fighting the framework too much...
Couple of options, some of which have already been mentioned:
Locator. I like to make a single Locator for the entire proj, or at least for groups of related objects that have similar key types. The getId() call will be able to invoke your DomainObject.getObjectId() method and return that value. Note that the getDomainType() method is currently unused, and can return null or throw an exception.
ValueProxy. Instead of having your objects map to something RF can understand as an entity, map them to plain value objects - no id or version required. RF misses out on a lot of clever things it can do, especially with regard to avoiding sending redundant data to the server.
ServiceLayerDecorator. This worked pre 2.4, but with the annotation processing that goes on now, it works less well, since it tries to do some of the work for you. It seems ServiceLayerDecorator has lost a lot of its teeth in the last few months - in theory, you could use it to rebuild getters to talk directly to your persistence mechanism, but now that the annotation processing verifies your code, that is no longer an option.
Big issue in all of this is that RequestFactory is designed to solve a single problem, and solve it well: Allow developers to use POJOs mapped to some persistence mechanism, and refer to those objects from the client, following certain conventions to avoid writing extra code or configuration.
As a result, it solves its own problem pretty well, and ends up being a bad fit for many other problems/use-cases. You might be finding that it isn't worth it: if so, a few thoughts you might consider:
RPC. It isn't perfect for much, but it does an okay job for a lot.
AutoBeans (which RF is based on) is still a pretty fast, lightweight way to send data over the wire and get it into the app. You could build your own wrapper around it, like RF has done, and slim down the problem it is trying to solve to just your use-case.