I'm learning bean validation and want to apply it in a webservice.
I would like to build a SOAP web service, implementing it using EJBs. Port implementation is facade to internal implementation structure.
As transport objects I generated classes from XML schema, while in internal structure I use JPA entities.
I would like to use bean validation annotations on JPA entities and EJB methods.
Is it possible somehow to use constraint violations as validation results in the facade to build fault messages?
Is there any good practice how to achieve that, since xsd types and jpa entities have slightly different structure and direct messages from validation might not be totally suitable for faults?
Related
I am trying Google Guice as Dependency Injection framework for my new project and shifting from spring.
I have to write multiple providers using #Provides, where instance created from one provider will be used as an input to other providers in the separate modules (sometimes the same module).
For binding the instance generated from the module, I am using Guice's
#BindingAnnotation
to create a custom annotation.
I just wanted to know how does the precedence works in Google Guice?
Like in spring we had a #Dependson annotation for bean creation, is there an alternative in Guice or Guice smart enough to generate a dependency graph by itself?
Does Binding the instances of providers using annotation created from #BindingAnnotation enough?
[is] Guice smart enough to generate a dependency graph by itself?
I'm not familiar with Spring, but my gut-feeling is Yes.
Does Binding the instances of providers using annotation created from
#BindingAnnotation enough?
As long as the provider has been annotated as providing something (using #Provides), Guice will use that annotation as a default, unless otherwise overridden inside a module.
However, using BindingAnnotations does include some code in a Module to bind it together,
https://github.com/google/guice/wiki/BindingAnnotations
bind(CreditCardProcessor.class)
.annotatedWith(PayPal.class)
.to(PayPalCreditCardProcessor.class);
So I suspect that Binding Annotations based annotations have stronger strength then #Provides and as long as you have the counterpart in the module, is more then enough to bind your providers together.
I want to share some domain objects between my client and server apps.
Starting with Hibernate 4, the Hibernate annotations were integrated in hibernate-core (used to be a separate jar), see http://in.relation.to/Bloggers/NoMoreHibernateannotationsModule
I would really prefer to stick with annotations (and not switch to xml based mapping).
At the same time I would really like to avoid bundling the hibernate core dependencies with the client (which will be transferred to the user via http through java web start, ideally on every startup).
Do I have to go back to Hibernate 3.x? Are these annotation dependencies needed to run the client or do I just need them to compile the client?
Thanks
You don't need to have the annotations of a class in the classpath to be able to load a class.
That said, a Hibernate entity contains collections and references to other entities. The collections are instances of Hibernate collections, and the references can be Hibernate proxies, if they're lazy-loaded. So if you serialize a Hibernate entity from the server to the client, the client will need the Hibernate jar(s) in its classpath to be able to load them.
If you want to avoid the Hibernate dependency at client-side, you should consider transferring DTOs to the client rather than Hibernate entities.
I am building a sort of validation framework for a GWT project.
The point is to reuse the same validation code for both client and server side.
I found that jsr-303 Bean Validation is supported by both GWT(here) and Spring(here).
As my model object are generated and I cannot annotate them properly, I would like to use xml-based configuration for jsr-303 Bean Validation. However, I don't see a way of doing it with gwt-validation.
Is there a way I configure the gwt-validation using xml instead of annotations?
It looks like there's no way of doing this yet.
I'm creating a Java EE application that's using JPA for data access. Initially I used EclipseLink, but the bundled Geronimo Javamail implementation that it depends on via Moxy was giving me some odd issues and I couldn't force it to use Sun Javamail, so I've switched to Hiberate as the JPA provider.
EclipseLink was ignoring the lazy/eager annotations, it was eagerly loading everything. Hibernate pays attention to those annotations, and so dependant objects aren't loaded. That means if I load say a person, with a lazy loading of the persons parents, if I access the parents in the view it's not lazy loaded, I get an exception that says the database session's closed.
I understand there are two ways to get around this:
- Open Session in View pattern/antipattern (which isn't great from a layered point of view, and can have the N+1 database calls problem, but is easy)
- Have service methods that load all the data the view needs (which makes the service layer messy with lots of duplicate methods to get varying amounts of data)
For reference my layers are View -> Controller -> Service -> Entity Object -> JPA. I don't have a dto as it's a small app and I don't like the DTO anti-pattern.
Thinking about the Open Session in View pattern, the problem is the OpenSessionInViewInterceptor and OpenSessionInViewFilter are both Hibernate specific, and both require you to declare a hiberate session on your Spring configuration files. I prefer to stay with pure JPA, configured with a persistence.xml file.
What are my options here? Can I just change my Spring configuration to load Hibernate explicitly, but then use pure JPA inside my application? Is there a pure JPA way achieve the same result, lazy loading from the view?
it sounds odd the EclipseLink ignores standard JPA annotations.
the javamail implementation should not be in any way related to JPA
there is OpenEntityManagerInViewX (filter/interceptor) which handle the same scenario for JPA
you can easily go without this pattern if you declare and use your collections wisely.
I have a Java EE 6 web application that offers it's data via a JAX-RS REST web service.
The entities are annotated with the JPA annotations as well as with the javax.xml.bind JAX annotations.
My aim is to assemble a client-jar out of my web-app project that contains the JAX-RS annotated "DTO" classes to be used for JAX unmarshalling in clients of my web-app.
Putting the raw entities in the client jar is not an option because of the JPA annotations, which would lead to bogus dependencies for the client.
Is there a way for doing this without writing the JAX-RS classes twice, for the web-app and the clients?
I thought of annotation processing and killing all JPA annotations in the entities, that's quite techy, but not very handy.
My second idea is to extract an interface of the needed getters/setters of the entities. The question here is how to handle the JAX annotations that are placed at the class members and at the getters.
Both ways seem to work somehow. But is there a general purpose solution for that task?
Hint: yes, i'm aware of the way to expose the JPA-Entities directly via rest and its coupling drawbacks to evolution etc =)
You could supply the JPA metadata via XML (http://java.sun.com/xml/ns/persistence/orm_2_0.xsd) instead of annotations. This would give you the mapping without the class path dependency.
http://java.dzone.com/articles/persisting-entity-classes