On Fri, May 29, 2009 at 8:27 AM, Tabanelli Sergio <[email protected]> wrote: > Hi all > My name is Sergio Tabanelli and I am currently working on an identity > management project. > During the project inception we choose SDO as object entity abstraction api, > openjpa as persistence layer and fluid (apache labs project from Pinaki > Poddar http://people.apache.org/~ppoddar/fluid/site/index.html) as > connection layer between SDO and JPA. During development we spent 2 months > extending fluid functionality and correcting bugs (for example generation of > jpa pojo class on the fly and in memory using serp, enhance persist and > rollback functionality, add a changesummary driven applychanges method, > etc.). Now we have a framework that works quite well and is extensively used > across all our identity manager application. We are now releasing > opensource our product (probably with an apache2 licence) together with the > patched version of fluid (source are already available at > https://sourceforge.net/projects/gaiusidm/ and > http://gaiusidm.svn.sourceforge.net/viewvc/gaiusidm/). I am sorry but, due > to delivery pressure, changes to fluid was not tracked and we don’t have a > descriptive change history, code was not commented and, I am afraid, but I > don’t remember all code changes we made (work was done 1 year ago). I put > all changes I remember in a small RELEASE_NOTES text file in the fluid > project root dir. > > Here are some useful notes: > > to persist a new dataobject using the new SDOEntityManager.applyChanges > method: > > // do some stuff with changesummary log active > dataGraph.getChangeSummary().beginLogging(); > ..... > ..... > // end logging > dataGraph.getChangeSummary().endLogging(); > > // get an instance of the SDOEntityManager and then apply changes > SDOEntityManager em = (SDOEntityManager) emf.createEntityManager(); > em.getTransction().begin(); > em.applyChanges(dataGraph.getRootObject()); > em.getTransaction().commit(); > > if you don't want to use custom applyChanges method but you still want to do > changesummary driven persistence, you can use the standard persist method > passing the SDO data graph as persisted object > > // get an instance of the SDOEntityManager and then apply changes > EntityManager em = emf.createEntityManager(); > em.getTransction().begin(); > em.persist(dataGraph); > em.getTransaction().commit(); > > It must be mention also that changesummary driven persistence does not > persist the root dataobject but only contained dataobjects. > > to use dynamically in memory JPA pojo class generation you must use the new > SDODynamicClassResolver, In persitence.xml ad the following line: > > <property name="openjpa.ClassResolver" > value="org.apache.openjpa.sdo.SDODynamicClassResolver"/> > > see src/test/resources/MET-INF/persitence.xml for an example > > If you want to simply persist a dataObject despite the changesummary use the > persist, merge or remove standard method passing a dataObject as persisted > object (do a merge first if needed). Example: > > EntityManager em = emf.createEntityManager(); > em.getTransction().begin(); > dataObject = em.merge(dataObject); // needed only if detached > em.remove(dataObject); > em.getTransaction().commit(); > > There are some issues: > SDO type registration happens only on the first call to createEntityManager > method so you need to call this method before doing anything with the > persistent SDO types, alternatives should be investigated. > > Serp, the bytecode library used for JPA class generation, does not work with > enum annotation properties, needed for cascade type annotation, so on the > fluid source tree there is a patched version of the serp Annotation.java > class, if you don't want to patch serp you need to force classpath load > order to give precedence to the patched class version present in the fluid > jar (or if you are lucky....) > > Some other notes on SDO root objects: > normally my SDO XSDs does not have root objects, and I don't persist root > object. When I fetch from repository, dataobjects are returned without a > root and if I need to serialize or pass objects to "pure" SDO application I > use a new helper method to create and populate a new root object, this > method basically, create a new root SDO type on the same namespace of the > dataobject passed as argument, create a new root object and poupulate it > with all related objects. Example: > > SDOEntityManager em = (SDOEntityManager) emf.createEntityManager(); > DataObject dobj = em.find(dobjType, id); > dobj = ImplHelper.populateNewRootObject(dobj); //Create a new root object > and populate it with dobj and all related objects. > > In the test source tree there is a simple ldap & ActiveDirectory > abstractstoremanager, that is tested through persistence of dataobject to > ldap and activedirectory, those tests use a stupid hack to avoid failures if > no ldap or AD is configured, they print errors but don't fail. If you want > to test ldap and AD you need to configure your openldap and/or AD in > persistence.xml (see src/test/resources/MET-INF/persitence.xml for an > example) in the fluid root dir there are a simple slapd.conf and gaius.ldif > that can be used for openldap configuration and basedn creation. > > As I previously mention, coding was done with delivery pressure so I am sure > that some refactoring should be done…. > > Obviously suggestions, bug reporting and desiderata are more then welcome. > Pinaki already give me some good hits for enhancements… > Hoping that this work will be usefull to the openJPA and Tuscany community, > again, my thanks to Pinaki Poddar for the fluid project . > > > Ciao grazie > Sergio Tabanelli > > Hey Sergio
haven't go my mind round this yet but thanks for the heads up and the summary. Regards Simon
