Here is the sample: http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/WebContent/WEB-INF/applicationContext.xml
See the *txProxyTemplate* ... and then in every (ROOT-)Service this proxy Template is injected, for example: http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/WebContent/WEB-INF/services/diagramservice.service.xml You have to generate Interfaces for the Service Classes to make it work: http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/src/app/org/i4change/app/remote/IDiagramservice.java Sebastian 2011/8/1 Василий Дегтярев <[email protected]> > Hello Sebastian, > > Could you please give me link of samples of implementation from another > project. > > Thanks, > Vasiliy. > > > 2011/7/29 [email protected] <[email protected]> > >> That sounds good. >> >> Additionally the best way to handle the Session itself would be to let >> Spring manage the Session. >> Its a bit of refactoring to do it because in the end all Classes should be >> injected via Spring so that you can use a Spring template that holds the >> SessionContext and inject it into every Class. I can link some samples of >> such implementation from another project of mine. >> >> Sebastian >> >> >> 2011/7/29 Vasya <[email protected]> >> >>> Hello Sebastian, >>> It seems that we should improve openjpa transaction because current >>> transaction implementation does not catch openjpa entity transaction >>> exceptions. So we propose to add special DAOTransaction class that >>> should catch transaction exception and rollback transaction, please >>> see example below: >>> >>> public abstract class DAOTransaction <T> { >>> >>> >>> private T result; >>> private EntityManager em; >>> >>> public DAOTransaction() { >>> } >>> >>> public T execute() throws Exception { >>> Object idf = PersistenceSessionUtil.createSession(); >>> em = PersistenceSessionUtil.getSession(); >>> EntityTransaction transaction = em.getTransaction(); >>> if (!transaction.isActive()) { >>> transaction.begin(); >>> } >>> try { >>> run(); >>> transaction.commit(); >>> } >>> catch (Exception e) { >>> e.printStackTrace(); >>> } >>> finally { >>> if (transaction.isActive()){ >>> transaction.rollback(); >>> } >>> PersistenceSessionUtil.closeSession(idf); >>> } >>> return result; >>> } >>> >>> public abstract void run(); >>> >>> public void setResult(T result_) { >>> result = result_; >>> } >>> >>> public T getResult() { >>> return result; >>> } >>> >>> public EntityManager getEntityManager() { >>> return em; >>> } >>> >>> } >>> >>> >>> In this case method Usermanagment.addUser looks like this: >>> public Long addUser(final Users usr) { >>> try { >>> return new DAOTransaction<Users>() { >>> public void run() { >>> setResult(getEntityManager().merge(usr)); >>> } >>> }.execute().getUser_id(); >>> >>> } catch (Exception ex2) { >>> log.error("[addUser]", ex2); >>> } >>> return null; >>> } >>> >>> Please let me know your opinion about this. >>> >>> Thanks, >>> Vasiliy. >>> >>> >>> On Jul 27, 2:14 pm, "[email protected]" <[email protected]> >>> wrote: >>> > I agree with you with some exceptions: >>> > >>> > Users can login with the login+pwd OR email+pwd, both is accepted. >>> > >>> > If you query the database for the login, you have to check if >>> externalUserId >>> > == null. >>> > Cause the login and email is only unique for those people that sign up >>> > through openmeetings. If you sign up by using Facebook, Moodle, Joomla, >>> > whatever (generally using the SOAP/REST API), you can simulate any user >>> and >>> > those users "Could" use all the same login/email. So you might have >>> 1000 >>> > times the same login/email, cause for example somebody uses the SOAP >>> API, >>> > always sets the same login/email but NEVER an externalUserId (this >>> would >>> > result in creating a new user in openmeetings every time). As those >>> users >>> > that are simulated for access via SOAP are not allowed to login via the >>> > login-shield it does not matter that the login/email is several times >>> > duplicated. >>> > >>> > So you should change your patch to use the same mechanism that I use >>> for >>> > checking login+email+externalUserId==null. >>> > >>> > I just do realize that this check is wrong :)) >>> > >>> > The mechanism should be: >>> > If the imported user has externalUserId != null / > 0 => the user >>> should be >>> > imported WITHOUT checks. Even if duplicated. >>> > If the imported user has exteranlUserId == null, then you have to query >>> the >>> > database if a user with login or email and externalUserId=null does >>> already >>> > exist, and if so you can use your logic "if user was found we map all >>> > events/rooms etc. to user found" >>> > >>> > 2011/7/27 Maxim Solodovnik <[email protected]> >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > Hello Sebastian, >>> > >>> > > Today I planed to check in the code for handling login/emails and >>> files >>> > > (written and tested by Vasiliy), but found you was ahead of me :) >>> > >>> > > Your code is slightly differs than ours so I that to ask couple of >>> > > questions: >>> > > in your code you skip import user data (for all users) if user email >>> is >>> > > found in the DB. >>> > > In our approach we check user login (since email is not required >>> field and >>> > > ) >>> > > and if user was found we map all events/rooms etc. to user found. >>> > >>> > > I think our code will better suite the following situation: >>> > > 1) OM server was installed and full of data (users, organizations, >>> events >>> > > etc.) >>> > > 2) All data was backed up >>> > > 3) New version was installed (new DB) >>> > > 4) While installation admin entered his username/email (used in the >>> old >>> > > installation) To make situation more complicated lets imaging the >>> system has >>> > > more than one admin. Backup/Restore was done by user with "old" id >>> not equal >>> > > to 1. >>> > >>> > > As a result user data will not be mapped to the only created admin >>> user. >>> > >>> > > Does it make sense to you? >>> > > Could you take a look at the Vasiliy's patch attached (against rev. >>> 4007)? >>> > >>> > > On Mon, Jul 25, 2011 at 14:13, [email protected] < >>> > > [email protected]> wrote: >>> > >>> > >> I have done some tests during the weekend. >>> > >> I have some minor changes to the import, the memory consumption was >>> > >> okay, with Xmx512MB the was no Heap-Space exception. I will commit >>> my >>> > >> changes tonight but it should be no problem to merge them if you >>> have >>> > >> updates too, you can proceed in commiting them. >>> > >> The folder renaming, I had no chance to look inside that yet. >>> > >>> > >> .. as well as the activity window. >>> > >>> > >> You can also see the renewed proposal for Apache incubation here: >>> > >>> > >> >>> http://mail-archives.apache.org/mod_mbox/incubator-general/201107.mbo... >>> > >>> > >> Sebastian >>> > >>> > >> 2011/7/22 [email protected] <[email protected]>: >>> > >> > The only problem I see are the login/email cause: >>> > >> > Login should be unique so that users can login. >>> > >> > We just simply might add a check on that value and skip that user >>> if >>> > >> > it already exists. >>> > >> > Cause otherwise you always have at minimum one duplicate: >>> > >> > The user with the ID=1, cause even if you import it directly after >>> you >>> > >> > did the installation, ONE user always is there. And it would be >>> bad to >>> > >> > duplicate that one, cause you would not be able to login with this >>> > >> > (Admin) user again. >>> > >>> > >> > Sebastian >>> > >>> > >> > 2011/7/22 Maxim Solodovnik <[email protected]>: >>> > >> >> Hello All, >>> > >> >> I have checked in the code with id maps, discussed earlier. >>> > >> >> It has no check for duplicate users (import done multiple times) >>> > >> >> I'm not sure how can we protect the DB from such user action .... >>> > >> >> Even if all data would be checked it would not work in following >>> > >> situation: >>> > >> >> 1) import was performed >>> > >> >> 2) some data was edited (using admin) >>> > >> >> 3) import was run one more time >>> > >> >> Maybe you have any ideas about it? >>> > >> >> On Fri, Jul 22, 2011 at 17:42, [email protected] < >>> > >> [email protected]> >>> > >> >> wrote: >>> > >>> > >> >>> Okay Vasya, >>> > >>> > >> >>> regarding the ZIP for the 40.000 Users....this import is not the >>> usual >>> > >> >>> test-case >>> > >>> > >> >>> I do not export the Files in it, cause that would result in a >>> 80GB ZIP >>> > >> >>> file. I do only import/export the database-record in the ZIP. I >>> have >>> > >> >>> added some option for that. >>> > >> >>> You should generate some sample data with some sample rooms. >>> > >>> > >> >>> From what I understood your import would allow users to import >>> the >>> > >> >>> same ZIP n-times. >>> > >> >>> Or do you add some checks to not duplicate it? >>> > >>> > >> >>> What happens to users if you import a user twice, cause the >>> > >> >>> username/login would exist two times and the Auth-Mechanism >>> would not >>> > >> >>> work anymore. I think for a phase1 its okay if that fails, >>> somebody >>> > >> >>> should know that importing the same ZIP twice can result in >>> duplicates >>> > >> >>> ... >>> > >>> > >> >>> Sebastian >>> > >>> > >> >>> 2011/7/22 Vasya <[email protected]>: >>> > >> >>> > Hello Sebastian, >>> > >>> > >> >>> > I have added mapping for ID’s for import. Maxim should be >>> submitted >>> > >> my >>> > >> >>> > changes today. >>> > >> >>> > Now I am working on copy the folder of the upload-directory >>> from the >>> > >> >>> > Backup-ZIP to the disk. >>> > >>> > >> >>> > Vasiliy. >>> > >>> > >> >>> > On Jul 21, 4:21 pm, "[email protected]" < >>> [email protected]> >>> > >> >>> > wrote: >>> > >> >>> >> Hi Maxim, >>> > >>> > >> >>> >> yes this was the thing that I tried to avoid :) Collecting >>> all IDs >>> > >> and >>> > >> >>> >> building lookup tables to see which old id corresponds to the >>> > >> record >>> > >> >>> >> after the import. >>> > >>> > >> >>> >> The other thing, to import the objects in the correct order >>> is >>> > >> already >>> > >> >>> >> implemented. >>> > >>> > >> >>> >> Some Issue will be also the uploaded files: There are some >>> > >> >>> >> restrictions on the user's profile images. I think they have >>> the >>> > >> >>> >> userId as folderName in the path. So you can't copy the >>> folders >>> > >> >>> >> anymore into the disk just by coping the ROOT folder of the >>> > >> >>> >> upload-directory from the Backup-ZIP to the disk, cause there >>> are >>> > >> some >>> > >> >>> >> subfolders that contain invalid folderNames that need to be >>> > >> >>> >> rewritten/renamed. >>> > >>> > >> >>> >> We can try that out, its obviously better if it works but its >>> a >>> > >> rather >>> > >> >>> >> big change. >>> > >> >>> >> My concern is the same like yours: Could be quite memory >>> hungry >>> > >> >>> >> process. >>> > >>> > >> >>> >> I got for example a database with 40.000++ users that I need >>> to >>> > >> >>> >> import/export. Holding all 40.000 users would not work, maybe >>> > >> holding >>> > >> >>> >> the 40.000 IDs could work. >>> > >>> > >> >>> >> Sebastian >>> > >>> > >> >>> >> 2011/7/21 Maxim Solodovnik <[email protected]>: >>> > >>> > >> >>> >> > Hello Sebastian, Vasiliy >>> > >> >>> >> > Instead of creating generator classes I would like to >>> propose the >>> > >> >>> >> > following >>> > >> >>> >> > mechanism: >>> > >> >>> >> > 1) Import should be done in "well known" order i.e. >>> > >> organisanisations >>> > >> >>> >> > are >>> > >> >>> >> > imported first then users, then rooms etc. >>> > >> >>> >> > 2) While importing certain object id is not set. Instead of >>> this >>> > >> old >>> > >> >>> >> > id and >>> > >> >>> >> > new id are stored in hashtable key== oldId, value == newId >>> > >> >>> >> > 3) While importing objects containing links to "parent >>> objects" >>> > >> newId >>> > >> >>> >> > is >>> > >> >>> >> > used using Hashtable created. >>> > >> >>> >> > 4) Pictures/streams/videos are stored in the file system >>> using >>> > >> newId >>> > >> >>> >> > The import will be memory consuming operation but all >>> constraints >>> > >> >>> >> > will be >>> > >> >>> >> > valid. >>> > >>> > >> >>> >> > On Mon, Jul 18, 2011 at 17:46, Vasya < >>> [email protected]> >>> > >> >>> >> > wrote: >>> > >>> > >> >>> >> >> Hi Sebastian, >>> > >>> > >> >>> >> >> Thanks for your answer! >>> > >>> > >> >>> >> >> I will continue to investigate problem tomorrow. >>> > >>> > >> >>> >> >> Vasiliy. >>> > >>> > >> >>> >> >> On Jul 18, 5:32 pm, "[email protected]" < >>> > >> [email protected]> >>> > >> >>> >> >> wrote: >>> > >> >>> >> >> > Hi Vasya, >>> > >>> > >> >>> >> >> > If tested getBackupRooms yesterday, it was okay for me. >>> > >>> > >> >>> >> >> > The thing with the *deleted* is that it has to return >>> ALL >>> > >> records, >>> > >> >>> >> >> > no >>> > >> >>> >> >> > matter if the deleted flag is set or not. >>> > >> >>> >> >> > This is the case because of the foreign key references. >>> > >>> > >> >>> >> >> > Just imagine the following sample: >>> > >> >>> >> >> > Rooms-Table: >>> > >> >>> >> >> > ID name deleted >>> > >> >>> >> >> > 1 room1 false >>> > >> >>> >> >> > 2 room2 true >>> > >> >>> >> >> > 3 room3 false >>> > >>> > >> >>> >> >> > Rooms-Organizations Table: >>> > >> >>> >> >> > ID rooms_id organisation_id >>> > >> >>> >> >> > 1 1 1 >>> > >> >>> >> >> > 1 2 2 >>> > >> >>> >> >> > 1 3 1 >>> > >>> > >> >>> >> >> > If you only export those records that are deleted == >>> 'false' >>> > >> >>> >> >> > => the importer would add room3 as the record with the >>> ID 2 >>> > >> and as >>> > >> >>> >> >> > consequence the room would be assigned to the >>> organization 2 >>> > >> => >>> > >> >>> >> >> > which >>> > >> >>> >> >> > is wrong of course. >>> > >>> > >> >>> >> >> > And the same you have between all tables. That is why I >>> did >>> > >> import >>> > >> >>> >> >> > records always WITH all records marked as "deleted" AND >>> in the >>> > >> >>> >> >> > import >>> > >> >>> >> >> > process I did add each object with the ID ALREADY SET. >>> That >>> > >> means >>> > >> >>> >> >> > I >>> > >> >>> >> >> > did not use the generated Id from Hibernate, I did use >>> the ID >>> > >> that >>> > >> >>> >> >> > was >>> > >> >>> >> >> > provided >>> > >>> > ... >>> > >>> > read more » >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OpenMeetings developers" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/openmeetings-dev?hl=en. >>> >>> >> >> >> -- >> Sebastian Wagner >> http://www.webbase-design.de >> http://openmeetings.googlecode.com >> http://www.wagner-sebastian.com >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenMeetings developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/openmeetings-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "OpenMeetings developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/openmeetings-dev?hl=en. > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.wagner-sebastian.com [email protected] -- You received this message because you are subscribed to the Google Groups "OpenMeetings developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/openmeetings-dev?hl=en.
