I am using NetBeans 6.8 for building Spring MVC application.
Technologies :
Spring MVC 2.5
Derby DB
Hibernate for ORM
GlassFish v3 server
I use New JPA Controller Classes from Entity Classes for adding ORM file. It is supposed to generate class for managing queries with my POJO files.
Problem is, that NetBeans generates following code, and won't compile :
public int getBrandCount() {
EntityManager em = getEntityManager();
try {
CriteriaQuery cq = em.getCriteriaBuilder().createQuery();
Root<Brand> rt = cq.from(Brand.class);
cq.select(em.getCriteriaBuilder().count(rt));
Query q = em.createQuery(cq);
return ((Long) q.getSingleResult()).intValue();
} finally {
em.close();
}
}
At the picture, there is NetBeans error :
It looks like method getCriteriaBuilder of Entity Manager Interface is unimplemented. Or some other reason why I can't use it in code.
I don't know what other info should I provide, so please ask if anything comes to your mind.
Thanks
I ran into this problem and found that I had the Hibernate JPA library (included with Netbeans) above Persistence (JPA 2.0) library in the project library manager list. I moved Persistence above Hibernate and it cleared up the compile issues.
NetBeans is generating JPA 2.0 code so you need the JPA 2.0 API on your class path to compile your code (and a JPA 2.0 provider to run it). Since you're using Hibernate, here are the required libraries to use Hibernate Entity Manager 3.5.1-Final:
org.hibernate:hibernate-entitymanager:jar:3.5.1-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.1-Final:compile
| +- antlr:antlr:jar:2.7.6:compile
| +- commons-collections:commons-collections:jar:3.2:compile
| +- dom4j:dom4j:jar:1.6.1:compile
| | \- xml-apis:xml-apis:jar:1.0.b2:compile
| \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.1-Final:compile
| \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
| \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile
I have the similar problem when deploying project with
Netbeans 7.0.1
Apache Tomcat 7
Hibernate 3
When mapping the class entity from database, i mixed it with annotation so the controller can be easily generated by Java Persistence Controller. The problem is same. The getCriteriaBuilder is the problem since it isn't supported by JPA 1.0. I have checked it in the project classpath and i found that Persistence Library is miss used since the project import two persistence library which is persistence library from ejb3 and EclipseLink(JPA2.0).
When i remove the ejb persistence library, the getCriteriaBuilder works fine for me.
Related
I'm currently writing my first Spring application (Spring boot + hibernate). I checked the best practices directory structure on their documentation here. It makes sense.
Question 1:
I have an interface (or Abstract class) that a few subclasses extend, and so I only need a #Repository for the parent class. I've decided to do it this way:
com
+- example
+- myapplication
+- Application.java
|
+- message
| +- AbstractMessage.java
| +- IMessageRepository.java
| +- MessageRepositoryImpl.java
+- messageTypeA
| +- messageTypeA.java
| +- messageTypeAService.java
+- messageTypeB
| +- messageTypeB.java
| +- messageTypeBService.java
Question 2:
Now I have a new entity to save called Group. So what I could do is add a Group directory on the same level as Message. However, this Group is actually a part of Message (like, logically), so it would actually make sense if it was part of the same message directory (the only reason we are saving them as different entities is because it makes more sense to derive analytics that way). Furthermore I'm even using the same MessageRepository to save it (I just added a second method in the interface like so:)
public interface MessageRepository {
void insert(AbstractMessage message);
void insert(AbstractMessage message, AbstractGroup group);
}
Would something like the following be good? Or should every entity have its own package? Am I overthinking this?
com
+- example
+- myapplication
+- Application.java
|
+- message
| +- AbstractMessage.java
| +- IMessageRepository.java
| +- MessageRepositoryImpl.java
| +- messageTypeA
| +- messageTypeA.java
| +- messageTypeAService.java
| +- messageTypeB
| +- messageTypeB.java
| +- messageTypeBService.java
|
+- group
+- AbstractGroup.java
+- GroupTypeX.java // same service as message, just different entity
+- GroupTypeY.java // same service as message, just different entity
That's more an opinion-based thing, but I'd like to give you a couple suggestions.
First of all, naming.
The I prefix on interfaces is an "ancient" technique from IBM to recognize them. Please, don't do that, it's reduntant, it doesn't make sense in a fresh environment. What's an I-MessageRepository?!
You'll find this kind of naming convention mostly on Eclipse RCP projects, or any product by IBM.
Then the implementation name. Don't use the Impl suffix, it does not say anything to the person who is reading or editing your code.
Give it a name which says what its purpose or domain scope is.
ActiveMQMessageRepository
FileMessageRepository
TcpMessageRepository
Second, Repositories.
Repositories should manage a single type of object, not more than one. Use Services to coordinate multiple Repositories. This will make it easier for everyone to debug, and it will decouple a lot of code.
Third, packages.
Try to always have a flat package structure. A flat structure is easier to maintain, easier to look at, easier to understand. Don't create dozens of sub-packages such as
- messages
- services
MessageService
- implementations
...
- repositories
MessageRepository
- abstract
AbstractMessageRepository
- implementations
TextMessageRepository
- exceptions
- runtime
- checked
UnsupportedMessageException
Horrible and useless. And you cannot leverage package visibility.
So keep messages and groups on separate packages, and give them their own Repository.
Expose interfaces from packages, not concrete implementations. (when possible)
I agree with #LppEdd answer above. Just one question what do you mean when you say
(the only reason we are saving them as different entities is because it makes more sense to derive analytics that way).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm a beginner with spring boot. I'm involved in the beginning of a project where we would build rest services using spring boot. Could you please advise the recommended directory structure to follow when building a project that will just expose rest services?
From the docs:, this is the recommended way
The following listing shows a typical layout:
com
+- example
+- myapplication
+- Application.java
+- customer
+- Customer.java
+- CustomerController.java
+- CustomerService.java
+- CustomerRepository.java
+- order
+- order.java
+- OrderController.java
+- OrderService.java
+- OrderRepository. java
The Application. java file would declare the main method, along with the basic SpringBootApplication as follows:
package com.example.myapplication;
import org. springframework.boot.springApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
#SpringBootApplication public class Application {
public static void main(string[] args)
{
springApplication.run(Application. class, args);
}
}
config - class which will read from property files
cache - caching mechanism class files
constants - constant defined class
controller - controller class
exception - exception class
model - pojos classes will be present
security - security classes
service - Impl classes
util - utility classes
validation - validators classes
bootloader - main class
You do not need to do anything special to start. Start with a normal java project, either maven or gradle or IDE project layout with starter dependency.
You need just one main class, as per guide here and rest...
There is no constrained package structure. Actual structure will be driven by your requirement/whim and the directory structure is laid by build-tool / IDE
You can follow same structure that you might be following for a Spring MVC application.
You can follow either way
A project is divided into layers:
for example: DDD style
Service layer : service package contains service classes
DAO/REPO layer : dao package containing dao classes
Entity layers
or
any layer structure suitable to your problem for which you are writing problem.
A project divided into modules or functionalities or features and A module is divided into layers like above
I prefer the second, because it follows Business context. Think in terms of concepts.
What you do is dependent upon how you see the project. It is your code organization skills.
Though this question has an accepted answer, still I would like to share my project structure for RESTful services.
src/main/java
+- com
+- example
+- Application.java
+- ApplicationConstants.java
+- configuration
| +- ApplicationConfiguration.java
+- controller
| +- ApplicationController.java
+- dao
| +- impl
| | +- ApplicationDaoImpl.java
| +- ApplicationDao.java
+- dto
| +- ApplicationDto.java
+- service
| +- impl
| | +- ApplicationServiceImpl.java
| +- ApplicationService.java
+- util
| +- ApplicationUtils.java
+- validation
| +- impl
| | +- ApplicationValidationImpl.java
| +- ApplicationValidation.java
DAO = Data Access Object.
DTO = Data Transfer Object.
Use Link-1 to generate a project. this a basic project for learning. you can understand the folder structure.
Use Link-2 for creating a basic Spring boot project.
1: http://start.spring.io/
2: https://projects.spring.io/spring-boot/
Create a gradle/maven project Automatically src/main/java and src/main/test will be created. create controller/service/Repository package and start writing the code.
-src/main/java(source folder)
---com.package.service(package)
---ServiceClass(Class)
---com.package.controller(package)
---ControllerClass(Class)
Please use Spring Tool Suite (Eclipse-based development environment that is customized for developing Spring applications). Create a Spring Starter Project, it will create the directory structure for you with the spring boot maven dependencies.
I've got a maven parent project that has two child modules (spring ws archetypes) each one is intend to be deployed in its own application server. One of the modules exposes a ws endpoint that is used by a ws client in the other module.
My problem is that i will have the java objects generated by jaxb and xsd in both modules, unless i find the way to share this set of classes without replicating it.
Is there any way to import an specific package from one module to the other? Is there other more appropriate way to deal with this problem?
Cheers!
create a ws-api maven module that only contains the api classes interfaces.
create a ws-impl that depends on the ws-api, because it implements it.
create the client module with the ws-api module as it's dependency, because it uses it.
Then you have the following structure, you can reuse the api clases and you have a clear api:
parent-pom
+- ws-api
+- ws-impl
+- client
The module dependencies will be
+------------+ uses +------------+
| client | --------> | ws-api |
+------------+ +------------+
^
| implements
|
+------------+
| ws-impl |
+------------+
In this setup the jaxb objects have to be generated in the ws-api module.
For a detailed explanation of why to separate the api and implementation take a look at my blog
http://www.link-intersystems.com/blog/2012/02/26/separation-of-api-and-implementation/
Spring-Webflow JSF intgration war example(http://www.springsource.org/webflow-samples/spring-booking-faces.war) file from spring site is not working in GlassfishV3 server. It works in Tomcat6.0.
In Glassfish, It throws following exception
Caused by: java.lang.UnsupportedOperationException
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:141)
at com.sun.faces.util.RequestStateManager.get(RequestStateManager.java:194)
at com.sun.faces.util.Util.getFacesMapping(Util.java:564)
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:483)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
at org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:77)
at org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:97)
at org.springframework.webflow.engine.ViewState.resume(ViewState.java:198)
at org.springframework.webflow.engine.Flow.resume(Flow.java:551)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:263)
... 40 more
I received a similar error that you are facing sometime back . Try replacing your JSF jars with the following jars.I guess it is using Primefaces too . Use following combination of jars
[INFO] +- com.sun.faces:jsf-api:jar:2.0.3-b05:compile
[INFO] +- com.sun.faces:jsf-impl:jar:2.0.3-b05:runtime
[INFO] +- org.primefaces:primefaces:jar:2.2.RC2:compile
Please let me know if you still face any problem
Every example I have found uses #Id, but when I try to write my code, many of the annotations that I'm used to are gone, there are annotatoins like #Index, and the #Entity parameters have changed. I've looked through the Hibernate documentation, and can't find anything talking about changing all of their annotations, so am I looking at a bogus version?
Even #Column() with a name is gone, this is extremely confusing, I'm using Hibernate 3, but I find it hard to believe they went through and broke EVERY annotation that they used to support.
I downloaded the most recent version of Hibernate3.jar, that's all I've included, looking through the JAR I see the annotations packages
import org.hibernate.annotations.Entity;
import org.hibernate.annotations.Table;
I think a wrongly defined class path on your side is more likely than a bogus version. And without more details about the version of Hibernate you're using, the JARs you have on the class path, I don't know what to add.
Update: I'd suggest to use JPA annotations over Hibernate annotations. Here are the dependencies I'm using with the latest version of Hibernate Entity Manager:
org.hibernate:hibernate-entitymanager:jar:3.5.3-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.3-Final:compile
| +- antlr:antlr:jar:2.7.6:compile
| +- commons-collections:commons-collections:jar:3.2:compile
| +- dom4j:dom4j:jar:1.6.1:compile
| | \- xml-apis:xml-apis:jar:1.0.b2:compile
| \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.3-Final:compile
| \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
| \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile
No, the annotations haven't changed.
It's hard to us for know if you are looking at a bogus version without knowing what is on your classpath.
Are you sure that hibernate-annotations is on your classpath? As well as the JAR containing the javax.persistence classes (such as hibernate-jpa-2.0-api-1.0.0.Final.jar)?