The JPAContainer has now reached a stage where there is actually something functional and usable to test. If you are interested in giving it a go, please read the
README file for instructions on how to download and compile the add-on.
I’m interested in all kinds of feedback: bug reports, suggestions for API-improvements, complaints about fuzzy or missing documentation, you-name-it. Post your comments in this thread (preferred way) or send them to me directly by e-mail (if you cannot use the forum for some reason).
Please remember that JPAContainer has not yet reached the official beta-stage and that some features and unit-tests are still missing (all the features demonstrated in the demo application are, however, fully functional). The API might also change, so please think twice before you start using JPAContainer in real production systems.
Great news !
Will look forward trying this once my load will fall down a bit
P.S. Funny thing, but in next version of our product we decided to follow NOSQL and move to distributed storage and bigtable scheme. However, JPAContainer will not be forgotten as SQL will live all around anyway us
Tried to use JPAContainer today ( v.0.9.0) with e jee6 application on a derby database, built-in glassfish. But it failes with SQL grammar error trying to fetch the size of entities. BTW, is Derby supported with JPAContainer ?
The environment is: GF 3.0, Hibernate 3.5 as pers.provider, LocalEntityProvider , formed as stateless bean.
The stacktrace is as follows:
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute query
com.vaadin.addon.jpacontainer.provider.LocalEntityProvider.doGetEntityCount(LocalEntityProvider.java:388)
at com.vaadin.addon.jpacontainer.provider.LocalEntityProvider.getEntityCount(LocalEntityProvider.java:397)
Caused by: org.apache.derby.client.am.SqlException: Syntax error: Encountered "fetch" at line 1, column 63.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source)
at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source)
at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown Source)
at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source)
I have not tested JPAContainer with Derby, but it believe it should work. That error seems a bit strange, as I don’t recall using the ‘fetch’ keyword in any of the queries that JPAContainer makes. I’ll look into it.
I just ran the Hibernate entity manager test on Derby and it passed. Dimitri, could you please give me some more information about what caused the error? Did you use any filters? What version of Derby did you use?
Im using Derby, which is bundled with GF3. The application is pure EJB3.1, with Hibernate 3.5 as persistence provider. According to stacktrace, the error occurs when trying to get entities count. I think I’ll better build a sample web app to reproduce the problem without extra code from our real application, then post it here, I think it would be easier to catch the problem.
P.S. In our entities we have the string-based, app generated PK. could this be a problem ?
Yes, it would be nice if you got post a sample web application. What I think is strange is the ‘fetch’ keyword, as it is not used by JPAContainer at all. My guess is that Hibernate uses it to limit the number of items to return, as the ‘limit’ keyword is not supported by Derby. If I remember correctly, the ‘fetch’ keyword was added to Derby 10.5. The Derby-version that comes bundled with GF3 is, however, 10.4. A possible explanation to your problem might be that Hibernate 3.5 is generating SQL intended for Derby 10.5.
May I suggest that you download the latest version of Derby and retry?
P.S. The persistence unit is configured to use Glassfish’s default jdbc/__default datasource, so it should deploy to standard GF3 installation “as is”, without any tweaks.
Petter, I just updgraded Derby with the version 10.5.3.0 and the example I did put to svn works well now. So I think this just needs to be noted in JPAContainer requirements.
By the way, JPAContainer works great, new data from the database appears in the table instantly and scrolling/navigation is fast. Did not try subcolumns and editing yet, but definitely a great work !
I opened a ticket and submitted a patch for the MetadataFactory class. It was starting at the entity class and working it’s way up, but it should work the other way. Also, the way I designed my entity classes was causing getDeclaredMethods() in extractPropertiesFromMethods() to pick up methods that weren’t technically declared (ie. getValue(String) → getValue(Serializable)). After inspecting the methods, I determined the thing that set them apart from the real deal was that they had both the volatile and synthetic flags set. According to the Java API, synthetic methods are intended for internal use only. Ticket # is 4590. I might also look into making another small related mod where the code expects the getter/setter methods to be declared in the same class. Initially, I defined getId() in a MappedSuperclass (ie. AbstractEntity) and in that same class, declared setId as abstract/@Transient so that you could use different strategies in other MappedSuperclass’es (ie. AutoIdEntity, StringIdEntity). Working on another issue surrounding calling Form.setItemDataSource() and ComboBox for which I opened another thread. I really want to use this container, so I am willing to invest time to make it work like other container implementations.
Hi Petter, just started with the JPAContainer with Vaadin 6.3.1 , and it works fine!
Just a little issue is that the table is not sortable in browser window, no sort direction arrow appears.
My Entity is very simple, any hints?
Have you tried to manually sort the table using the setSortContainerPropertyId and setSortAscending methods? I’m trying to find out whether this is a problem with JPAContainer or the Table component.
