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?
Related
I like Spring Data REST but I need to explore the possibility to use it without exposing directly our JPA Entities. Furthermore, our access layer is currently build using GenericDAO instead of repository (or Spring Data JPA).
So the idea is to build a custom spring data module that implementing the Repository interfaces allow me to benefit of all the other functionalities of Spring Data REST. The entities managed by our custom spring data module will be at the end DTOs of the original JPA entities.
I'm currently looking to spring-data-ldap as implementation to mimic as it looks as the most simple data module available but I'm facing with the following issue
we get an exception at the application startup saying
Parameter 0 of constructor in org.springframework.data.dspace.repository.support.DSpaceRepositoryFactoryBean required a bean of type 'java.lang.Class' that could not be found.
Action:
Consider defining a bean of type 'java.lang.Class' in your configuration.
DSpaceRepositoryFactoryBean is our implementation that just return a very simple DSpaceFactoryBean that always return a banal implementation of the CrudRepository (all methods return null)
#Override
protected Class<?> getRepositoryBaseClass(RepositoryMetadata metadata) {
return SimpleDSpaceRepository.class;
}
have sense this approach? or will be better to give up with Spring Data REST and just use Spring MVC + HATEOS?
I am about to start new java project and I consider GWT as my framework for it.
I've checked a lot of articles on the internet (main documentation also) and I am quite confused.
So I ask You:
Can I use jpa Entities to work with DAO, and to be sended over network to client?
I really don't understand the concept of DTO (writing almost the same but more poor class of Model)
If I will about to send Entities over network to client, how to use Serializable Transient annotation to NOT serialize and send methods, parameters of class? Is it even possible?
How all of this will work with Generic Typed Superclass extended by right class implementation?
f.e:
public class GenericModel extends GenericModel<T> {
//some generic code
}
public class RightModel extends GenericModel<RightModel> {
// some right class code
}
the same goes with DAO...
Please help.
I count on Yours experience.
Not that I was an expert at that time but when I started to combine Hibernate (not JPA as such) and GWT, it was a pain.
The reason that you can't just send over Hibernate managed objects (and I guess same counts for JPA, regardless of the underlying technology), is that they contain bytecode-manipulation stuff like javassist. GWT doesn't like this at all, and you can't send those objects over the GWT RPC wire.
Ofcourse also it doesn't make sense: you can't expect your Javascript (client-side) to invoke SQL to lazy-load collections when you invoke a getter on your DAO (because that's what happens server-side with these DAO objects, that's what the javassist magic is doing behind your back).
I'm not sure that even if all collections were eagerly loaded, your objects would be free of javassist stuff, and could be serialized over GWT-RPC. That leaves you with one alternative, which is to have POJO objects tailor-made to contain only those parts (properties/collections) that you need on the client at that moment - the DTO.
Since then a lot has happened in GWT, and I know of something completely different from RPC, which is RequestFactory (see http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html). I haven't used that myself, but it claims to make it easy to build data-oriented (CRUD) apps with an ORM-like interface on the client. So this may be the way to go if you don't want to build custom classes for wiring RPC.
I'm trying to handle the Spring DAO Exceptions (http://docs.spring.io/spring/docs/4.0.3.RELEASE/spring-framework-reference/htmlsingle/#dao-exceptions) in the service layer of my application, just to discover that the exceptions in the spring-data-commons module don't extend org.springframework.dao.DataAccessException.DataAccessException.
Example: PropertyReferenceException.
As far as I can tell, all exceptions in this module, and maybe in the other sub-modules of Spring Data projects should extend DataAccessException.
Is there anything obvious that I'm not seeing here?
There is no need for Spring Data to use Spring Core's DataAccessException hierarchy as one may use the PersistenceExceptionTranslator. The latter translates thrown exceptions of e.g. Spring Data Repositories to a DataAccessException subtype.
PersistenceExceptionTranslator kicks in automatically when marking your repository with the "#Repository" annotation. The service (using the annotated repository) may catch the DataAccessException, if needed.
I have a POCO entity on which I have defined a custom constructor. I have also implemented the default constructor so that Entity Framework can successfully hydrate the object when I request a copy from the database.
This seems to work well but when I set the default constructor to private (to force my code to use the custom version) and request an entity from the database, I don't seem to be able to navigate over related entities as they are all null.
This seems to be a lazy loading problem so I could change my repository to eager load the related objects I need but am wondering if there is a better way to hide the default constructor from the client code whilst allowing Entity Framework to lazy load?
If you define private constructor you violate requirements for creating POCO proxy responsible for lazy loading:
A custom data class must have a public or protected constructor that
does not have parameters.
So the best option for you is using protected constructor or not using lazy loading.
Well, I have read the document about Entity Proxy http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html . As far as I understood Entity Proxy does not support transparently calling of lazy loaded entity relations. Such as, I have Employee entity, and this entity has supervisor field whose type is Employee, and this field fetch type is lazy.. When I have queried an employee, can I call its getSupervisor method at GWT layer?.. What I expect EmployeeProxy calls transparently getSupervisor method of Employee entity on the server.. Is this the case?.
No, just as you mention it doesn't support lazy loading. It would also be difficult, because while you want to do a getSupervisor(), which would return the data, in practice this would mean GWT performs an asynchronous call, and needs a receiver. Technically, it might be be possible to implement something like lazy loading, but due to the asynchrony it would never be possible to simple do a getSupervisor().
There is the gilead project that might do what you intend.