Hey Sandro, Thanks for the tip on EStore.
Is the JCRM project in a usable state at this point? As we are still in the planning stages for this project JCRM may be a better solution as alot of the work would be very similar. Any where other than the one page mentioned that I may be able to get more information or an example of the use of JCRM? Thanks Wes > Hi Wes, > > just one word to the EStore. It can basically deligate many aspects of > the EMF EList to your EStore implementation. This way you can hook in > your connection to the OCM API. > > Ciao, > > Sandro > > Sandro Böhme schrieb: >> Hi Wes, >> >> I'm sorry my information about OCM are outdated so I will see if I can >> help you with EMF. >> >> > I would also like to enable the proxy=true for beans and collections. >> For >> > collection that would require the getter to be called to allow for >> the >> > creation of the collection appropratly and enhanced for lazy loading. >> > How >> > can you specify that the object will autoCreate the collection and >> only >> > the get needs to be called to access it? >> Do you mean the resolveProxy property of EMF? >> The proxy is usually for cross resource references in EMF I'm not sure >> how it's useful for lazy loading. >> Just to be sure to understand your use case: You would like to retrieve >> the according nodes using OCM as soon as your getXYZ() method got >> called. Is that correct? >> I got lazy loading to work implementing the EMF EStore. But I would not >> call that trivial. If you have a look at the end of this >> (http://wiki.eclipse.org/index.php/JCR_Management) wiki page you will >> find a description how to connect to the CVS where you find the meta >> model plugin of JCRM. In the src_resource folder is the >> JCRMStoreEObjectImpl class that implements the EStore for lazy loading >> in the dynamicGet() method. Maybe that helps. >> >> Bye, >> >> Sandro >> >> >> >> Wes schrieb: >>> Hi Sandro, >>> >>> Here are the issues I have run into at this point. >>> >>> The application has a large ecore model that I would like to utilize >>> OCM >>> as the persistence manager. >>> >>> When retrieving objects from the repository, the OCM needs to create >>> EMF >>> objects. For @Beans I added an implementationClass to the annotation >>> so >>> that the correct implementing class would be created and not attempt to >>> instantiate interface class. Is this the best solution? >>> >>> Collections are another issue. First I got a conflict with the >>> @Collection annotation with java.util.Collection. I made a quick >>> change >>> to that renamed the annotation (for testing) to avoid the collision >>> which >>> there should be a better way. When the system encountered a collection >>> I >>> provided a collectionClass that was an extension of the EcoreBasicList >>> with ManageableList interface so that the ManageableListUtil would >>> function correctly. >>> >>> I would also like to enable the proxy=true for beans and collections. >>> For >>> collection that would require the getter to be called to allow for the >>> creation of the collection appropratly and enhanced for lazy loading. >>> How >>> can you specify that the object will autoCreate the collection and only >>> the get needs to be called to access it? >>> >>> >>> Thanks for you help! >>> Wes >>> >>> >>>> Hi Wes, >>>> >>>> what are this aspects? Maybe I can help you. >>>> >>>> Best regards, >>>> >>>> Sandro >>>> >>>> Wes schrieb: >>>>> I am working with and EMF based application that I am looking to >>>>> leverage >>>>> the OCM functionality for repository management. I have changed >>>>> some of >>>>> the OCM code to support this function but there are some aspects that >>>>> I >>>>> am >>>>> not sure are the best approaches. >>>>> >>>>> Has anyone implemented Jackrabbit OCM with EMF? >>>>> What issues if any did you run into? >>>>> Any examples? >>>>> >>>>> >>>>> Thanks >>>>> Wes >>>>> >>> >>> >> >
