PJSJava

I made a little tool that makes it real easy to access and modify openoffice databases from Java, without having to open oo-base. Here's a code snippet from the unit test: OpenOfficeBaseJPA instance = new OpenOfficeBaseJPA(new File("testdb/TestDatabase.odb")); EntityManager em = instance.createEntityManager(); Integer rowcount = (Integer) em.createNativeQuery( "select count(*) from \"PUBLIC\".\"TestTable\"") .getSingleResult(); em.getTransaction().begin(); em.createNativeQuery( "insert into \"PUBLIC\".\"TestTable\" (\"TestField\") values ('Testvalue')") .executeUpdate(); em.getTransaction().commit(); Integer rowcount2 = (Integer) em.createNativeQuery( "select count(*) from \"PUBLIC\".\"TestTable\"")   .getSingleResult(); assertTrue(rowcount+1==rowcount2); em.close(); instance.saveChanges(); Thread.sl...

In some cases it might be useful to intercept and adjust the SQL generated by EclipseLink JPA. E.g. if you want to force an index in mysql you need to append force index (myindex) to the table name. If you create a query on the entitymanager: Query q = em.createQuery("select e from MyEntity"); you can cast it to the EclipseLink JpaQuery: JpaQuery jq = (JpaQuery)q; and the JpaQuery gives you access to the EclipseLink DataBaseQuery where you can prepare it before executing it: DatabaseQuery dbQuery = q.getDatabaseQuery(); dbQuery.prepareCall(((org.eclipse.persistence.jpa.JpaEntityManager)em).getActiveSession(),new DatabaseRecord()); You can now get the sql string and add the forced index: dbQuery.setSQLString(dbQuery.getSQLString()+" force index (myindex)"); and finally you can get the resultset using q.getResultList(). If you have parameters in the sql it's a bit more to it. Currently I've only found one option - probably not optimal since the query is transl...

Some of your code might use EJB session beans through JNDI lookup. To make this code find your session beans in your unit tests, you can replace the initial context quite easily. This is an example of how it can be done. public class ReplaceInitialContext extends InitialContext implements InitialContextFactory { static ReplaceInitialContext instance = null; public ReplaceInitialContext() throws NamingException { super(false); } public static ReplaceInitialContext getInstance() throws NamingException { if(instance == null) { System.setProperty("java.naming.factory.initial",ReplaceInitialContext.class.getName()); instance = new ReplaceInitialContext(); } return instance; } @Override protected void init(Hashtable environment) throws NamingException { } @Override public Object lookup(String name) throws NamingException { return "Hello"; } ...

You might want to use an embeddable container for this - but why really - cause it's really simple. EJB3 session beans are POJO's and should be tested like POJO's. However there are some issues in order to get EJB3 unit tests working. One of them are dependency injection. How does dependency injection work? Take a look at this method using reflection: /** * @param targetBean - the bean to inject into * @param annotationClass - the annotation class representing the injection * @param objectToInject - the object to inject into targetBean */ private void inject(Object targetBean, Class annotationClass, Object objectToInject) { // Scan all (private and public fields) of the bean class for(Field fld : targetBean.getClass().getDeclaredFields()) { // See if the specified annotation is present for the field if(fld.isAnnotationPresent(annotationClass)) { // See if the field type is appropriate according to the object that is to be injected if(fld....

LMAppletserver is a great tool for communicating from java-applet to server, but it is also a great tool for remote calls over http to ejb3 session beans in general. Here's an example of using stateful session beans with lmappletserver: https://lmappletserver.svn.sourceforge.net/svnroot/lmappletserver/lmappletserver_core/src_tests/com/lightminds/appletserver/core/tests/SFSBTest.java This is a unit test class, which also contains result verification, but is also a good example of how to use stateful session beans. You can check out the entire project in netbeans from: https://lmappletserver.svn.sourceforge.net/svnroot/lmappletserver/lmappletserver_core In NetBeans 6.5, just right click on the project, and select "Test" to run the tests (including the Stateful session bean test). The test uses Apache OpenEJB and Jetty as http servlet container (running the rpc servlet).

.... doesn't go very well together, since Seam wants to access your entityManager, and would want it to be a Hibernate instance... This is a simple workaround, by replacing s:convertEntity with a custom tag that gives the same result. By remembering the entities displayed to the s:selectItems, using the value of entity.toString() (which is className + hashCode() (which should be unique).). You might want to tune it maybe not to use hashcode (in case of non uniqueness), and maybe access your entitymanager (toplink) - instead of storing entities in memory.. But in any case this is a good starting point: package com.petersalomonsen.jsf.persistence.EntityConverter import java.util.HashMap; import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import javax.faces.convert.Converter; public class EntityConverter implements Converter { static HashMap<String,Object> entitiesToRemember = new HashMap<String,Object>(); public Object getAsObject(Fa...

I've been using EJB3 with jboss for a long time - and I've got use to this way of writing my ejb3 persistence queries: entityManager.createQuery("Select e from "+MyEntity.class.getName()+" e") which is also convenient considering refactoring compared to "Select e from MyEntity e". But the EJB3 persistence spec says this: "Entities are designated in query strings by their entity names. The entity name is defined by the name element of the Entity annotation (or the entity-name XML descriptor element), and defaults to the unqualified name of the entity class. Entity names are scoped within the persistence unit and must be unique within the persistence unit." And glassfish complains about the fully qualified classnames - it just want the unqualified classname (without package information). According to the spec - glassfish seems more correct to me - but the hibernate/jboss way of using fqn seems better to me - so I wonder, which one is really...