If you are getting
java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to javax.xml.bind.JAXBContext at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:145) at javax.xml.bind.ContextFinder.find(ContextFinder.java:277) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244) at com.rubenlaguna.en4j.mainmodule.ImportEvernoteFile.actionPerformed(ImportEvernoteFile.java:65) and you are using woodstox be sure to check the DevFaqModuleCCE. This could happen when you have Netbeans Platform Application with a module containing woodstox but also including JAXB 2.1 in the module dependencies for the application.
If you get a
error: Cannot access URL http://github.com/xxxxxxx/, return code 22
when trying to push changes to a git repository via HTTP.
This is probably because you are using an HTTP proxy to access the repo and that proxy doesn’t support WebDAV HTTP methods (especially PROPFIND). So when git issues a PROPFIND the http proxy answers back with a 500 Internal Server Error or something like that.
It seems that PROPFIND is absolutely required so if you can use git:// directly or use a HTTP proxy which supports PROPFIND.
If you create the persistence.xml manually in Windows the file will be created with CRLF line endings (windows style line endings), that will prevent Netbeans for recognizing- Netbeans will not recognize it as the special file it is and won’t be able to to open it with the special/custom visual editor.
[/caption]
I opened an bug report netbeans issue #172538. At the beginning, I thought the problem was due to different line ending CRLF vs LF issues, but as pointed out in the bug report the line ending has nothing to do with it.
I’m trying to use OpenJPA to insert some entries in the database and I’m getting a strange number of UPDATEs beside the INSERTs.
I isolated the problem to the following snippet of code
private void start() { EntityManagerFactory emf = Persistence.createEntityManagerFactory("persistencexmltest1PU"); EntityManager em = emf.createEntityManager(); for (int i = 0; i < 10; i**) { em.getTransaction().begin(); MyEntity n =new MyEntity(); n.setValue(i); em.persist(n); em.getTransaction().commit(); } } The generated SQL looks like this:
The newly released Google Web element: custom search is awesome.
To add it to my wordpress theme (which doesn’t have a top sidebar for widgets) I had to edit (Appearance ⇒ Editor) the header.php file and add the snippet I got from Google there, at just at the end of the header.php. So the search web element is show right after the banner and before the posts.
In my case the code is
In the build.xml of the project (likely this will be a Java Class Library project), override -post-compile or -pre-jar and invoke <openjpac/>. You will need to add the build/classes and the openjpa jars to <taskdef/> and <openjpac/>. The <openjpac/> will enhance all classes mentioned in persistence.xml (which has to be in the classpath)
<?xml version="1.0" encoding="UTF-8"?> <project name="JpaEntitiesLibrary" default="default" basedir="."> <description>Builds, tests, and runs the project JpaEntitiesLibrary.</description> <import file="nbproject/build-impl.xml"/> <target name="-post-compile"> <echo message="begin openJPAC"/> <path id="openjpa.
It seems that no current JPA implementation is able to paginate the result using Apache Derby 10.5 OFFSET/FETCH mechanism. So javax.persistence.Query setFirstResult and setMaxResults don’t really translate into proper pagination with “OFFSET/FETCH”
TopLink/EclipseLink org.eclipse.persistence.platform.database.DerbyPlatform Hibernate org.hibernate.dialect.DerbyDialect OpenJPA. org.apache.openjpa.jdbc.sql.DerbyDictionary
Java 6 includes STaX , when I tried to parse a Evernote backup file with it, I got a OOME error.
java.lang.OutOfMemoryError: Java heap space at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(XMLStringBuffer.java:205) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.refresh(XMLDocumentScannerImpl.java:1520) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.invokeListeners(XMLEntityScanner.java:2070) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(XMLEntityScanner.java:486) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2679) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:548) at Googling a bit I found a bug report 6536111. It says that this should be fixed in 1.6.0_14. But I tried Sun 1.6.0_16 and no luck. I got the exact same thing.
In my previous post I talk about JTable and JPA pagination through a custom TableModel.
Now working directly with TableModel is not want you want to do, you want to use Beans Bindings because it means less manual coding and a lot of help from the IDE (like Netbeans).
With netbeans you can easily bind a JTable to the result list of JPA query. But if that Query returns thousands of rows it’s going to be slow or unfeasible.
I really want to talk about JTable, Beans Binding and JPA pagination but I think I need to write about JTable and JPA pagination first. So I will take the Beans binding stuff in another post.
By the way, choose wisely your JPA Provider/DB Provider combination, as some combinations will not give you any real paginations at all. For example, neither OpenJPA, Hibernate or TopLink/EclipseLink seems to support Apache Derby pagination (OFFSET/FETCH).