I am using JPA 2.0. (EclipseLink 2.0.2)
If an entity contains relations, for example:
#OneToMany(cascade = CascadeType.ALL, mappedBy = "userId")
private Collection<Blog> blogCollection;
I am getting the following error when I am sending it through RPC:
com.google.gwt.user.client.rpc.SerializationException: Type 'org.eclipse.persistence.indirection.IndirectList' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.: instance = {[]}
In general all the Persistence APIs use a technique named code injection, which means that it injects code in your POJOs classes in order to do persistence job.
Because this is doing at runtime the GWT compiler was unable to see that, so it can't generates serializers for that types.
The solutions is not to send Persistance Classes thru the wire. Instead use DTO (Data Transfer Objects).
Hope this helps.
Regards
Daniel
This error message most likely means that your "Blog" object does not implement java.util.Serializable or com.google.gwt.user.client.rpc.IsSerializable.
RPC and Serializable Discussion
Related
We are using MapStruct with Spring Data to convert between JPA entities and DTO classes. All the mappers follow the same pattern with methods beanToDTO() and dtoToBean(). After a learning cure, we have all this working. Now we are trying to use Spring injection to replace the implementation on JPA entity, DTO, and Mapper classes. We have the JPA entities and DTO replacement working. So now we are trying to have Spring inject alternative Mapper implementation.
For our problem, we can subclass the mapper interface and not it will have 2 beanToDTO() methods and 2 dtoToBean methods(), 1 for the base JPA entity and DTO and 1 for the subclassed JPA entity and DTO. This works fine for straightforward examples.
For mappers that require some customization, we utilize the #Mapping annotation and #InheritInverseConfiguration for the base mapper. For the subclassed mapper, we try the same thing but the problem is the InheritInverseConfiguration in the subclass mapper gives the error "Several matching inverse methods exist: beanToDTO(), beanToDTO(). Specify a name explicitly."
Both methods have the same name so we have no way to identify the implementation we want to reference. I realize that the problem is due to our implementation approach but it simplifies our code to:
- getBean()
- getMapper().beanToDTO()
and we will be able to replace JPA entity, Mapper , and DTO via Spring injection.
Are there other MapStruct trick that will help us with this problem?
Thanks
Have you looked at the #MapperConfig.. checkout our unit test. I would advise to put your base / prototype methods in #MapperConfig annotated shared configuration interface that you can reference in #Mapper
See this unit test for more info. Or checkout the user guide.
As a yet "newbie" of JavaEE, say I try to implement a rather big RESTful API with Spring 4 and Hibernate and, the final JSON objects should be transformed to flattened Objects other than the original Java bean entities annotated with #Entity.
Due to the "out-of-the-box" feature of Spring and Hibernate, I am sure most programmers can easily get the work done. But as an experienced programmer, we would focus more on the code structure, design architecture so that the whole project is more maintainable and code is easy to read.
So my first question is the package structure:
where to place the Java bean entities annotated with #Entity? I have seen some people place them in the package called model, I am not exactly clear about their purpose anyway
Where to place the final flattened objects transformed from the Java bean entities? I placed it in the package called dto as this is data transfer object between the service layer and the controller layer
so I have the following package structure:
sample.model //place the #Entity Java beans
sample.dto //place the aforementioned DTO
sample.controller //place the controller class
Anyone can give some comments on it? Thanks in advance
There's two different ways to organize packages in Java project.
package-per-feature
package-per-layer
Comparison
But how to name your package it's really up to you.
In different projects, I faced with names like:
for entity: model, domain, entity
for DTO: dto, transport, response or request (depending on direction)
Spring provides the OpenEntityManagerInViewFilter to enable lazy loading of objects during the view phase, but what if I would like to use it in a message passing architecture like STOMP over websockets?
If I need to return an entity that has lazy properties in a #MessageMapping method the only way to do it that I know is to manually invoke property getters on the entity before returning it otherwise Jackson will raise an exception while serializing it to JSON.
Are there any more elegant solutions to that generic problem?
The JPA 2.0 specification mentions in section 6.9 that CriteriaQuery objects are serializable, and hence may outlive any open EntityManagers or EntityManagerFactory instances:
CriteriaQuery objects must be serializable. A persistence vendor is required to support the subse- quent deserialization of a CriteriaQuery object into a separate JVM instance of that vendor’s runt- ime, where both runtime instances have access to any required vendor implementation classes.
The EJB 3.1 specification says in section 21.2.2:
An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances, except if it is a Singleton session bean with bean-managed concurrency.
If I have a stateless session bean that wishes to pre-build a bunch of CriteriaQuery objects using a CriteriaBuilder obtained from an injected #PersistenceContext, where should I stash the results?
I can think of the following possibilities but am concerned that all but one run afoul of the "no synchronization primitives" clause above:
In a Map that is stored as the value of one of my bean's instance fields, understanding that I'll have to synchronize access to the map. My take: section 21.2.2 violation.
In a ConcurrentMap that is stored as the value of one of my bean's instance fields. My take: still a section 21.2.2 violation, as I'm sure the ConcurrentMap implementation synchronizes somewhere.
In a #Singleton EJB's instance field somewhere, where the #Singleton exists only to serve as this kind of cache; with bean-managed concurrency this should be legal, but now all my stateless session beans that want to make use of this CriteriaQuery cache have to inject the singleton into themselves...seems like a lot of overhead.
So it sounds like strictly speaking the last option is the only specification-compliant one. Am I correct?
I would consider putting them in a simple static context, accessible from anywhere. The problem lies in initializing them since you need an entity manager instance to do that. Perhaps a singleton ejb for initializing things as described at Call method in EJB on JBoss startup. The singleton could initialize your criteria query cache, which then could serve criteria queries to your DAOs through static context.
Another option would be to use JPQL which has built in support for precompiled queries. Of course you'd lose some advantages of using the criteria API, though I think the main issue (type safety etc.) might be OK since precompiled queries should throw an exception if they are invalid at deploy time rather than runtime.
I am wondering what is the best way to handle mapping of entity beans (JPA 2) to DTOs.
Since you cannot use entity beans "directly" with GWT, you need to handle DTOs instead.
I have several entities with various relationships (OneToOne, OneToMany, ManyToMany with a join table etc).
Initially i started converting all entities to DTOs by hand with the help of a class MyEntityTransform.java with methods like :
static final public CarBean persistant2Bean(CarPersist) {
return new CarBean(cartPersist.getId(), carPersist.getName(),
carPersist.getDescription());
}
Other methods are : persistent2BeanCollection(...), persistent2BeanMap(...), bean2Persistent(...), bean2PersistentCollection(...)
That becomes a fastidious task when handling collections, especially when the same entity has references to several other entities;
I have been thinking about using the DOZER framework to handle the mapping between entities and DTOs.
It is mentionned here : http://code.google.com/intl/fr/webtoolkit/articles/using_gwt_with_hibernate.html
However i am not sure how well it handles the various JPA mappings (manytomany for instance) and how much work it is to configure it in the dozer-bean-mappings.xml file.
Also i guess this framework is intensively using reflection to perform mapping operations. Such approach is much slower than mapping performed "by hands", e.g. when i use the methods in my MyEntityTransform.java class.
What do you suggest ? i'm interested in everybody's experience handling JPA entities with GWT.
Thanks.
Celinio
http://www.celinio.net/techblog
In first instance I would always prefer Dozer. When the DTO structure is the same as your entities, you can use Dozer with zero configuration by simply calling the map function. When your DTOs differ from your entities the configuration overhead is minimal. Simply look in the really good documentation.
When performance becomes an issue, I would prefer a code generator approach, but I would never write the mapping code by myself cause it can be very error prone.
If you want to just include entities in you EJB or JPA module in your GWT module follow these steps. I found it out my own and It worked for me.
Include your EJB module in GWT module's build path (you may have already done that)
Now goto your entities package in EJB module (i will take it as "com.ejbproject.entities")
Create a file named Entities.gwt.xml (<ProjectSourcePath>/com/ejbproject/entities/Entities.gwt.xml)
File content should be
<module>
<source>com.ejbproject.entities</source>
</module>
Now include following fragment in your GWT project's <modulename>.gwt.xml file.
<inherits name="com.ejbproject.entities.Entities"/>
Now you can include Entities in your GWT client side and gwtCompile without any problem