What do you need this class for? Does the conflict actually has sth todo with the Exception or do you need this Class ** for the Spring <=> OpenJPA integration? Cause I don't see any reference to this class if you follow the Spring/JPA Guide: http://static.springsource.org/spring/docs/3.0.x/reference/orm.html#orm-jpa
You could add the quick & dirty solution of Vasiliy anyway, if it really improves the situation. Sebastian 2011/8/9 Maxim Solodovnik <[email protected]> > Hello Sebastian, > > I was unable to take a look at your latest logs, but suppose it is also > "InvalidStateException: This operation cannot be performed while a > Transaction is active." > > To handle it I add EntityManager injection via Spring config as was > previously discussed. > > Unfortunately I'm currently stuck on following library conflict: > 1) red5 is dependant on javaee-api-5.1.1.jar which > contains javax\persistence\spi\PersistenceProvider definition > 2) and openjpa-all-2.1.0.jar contains definition of this class > as well as implementation > (org.apache.openjpa.persistence.PersistenceProviderImpl) > > The problem is: these two classes seems to be incompatible: > > javax.persistence.PersistenceException: The instance of the object with the > class name 'org.apache.openjpa.persistence.PersistenceProviderImpl' in the > ClassLoader 'WebappClassLoader' is not an instance of PersistenceProvider > interface. > > I tried to get fresh version of javaee-api*.jar > > but > 1) the version downloaded from maven repository javaee-api-6.0.jar doesn't > have all necessary packages > 2) the version downloaded from > http://www.jarvana.com/jarvana/browse/org/ow2/jonas/osgi/javaee-api/ has > all packages BUT has incompatible version of PersistenceProvider interface > > Maybe you have idea how can I resolve this? > Thanks a lot in advance > > p.s. May be I can implement DAOTransaction abstract class (from initial > Vasiliy's proposal) as quick and dirty solution? > > > On Mon, Aug 8, 2011 at 15:58, [email protected] <[email protected] > > wrote: > >> meanwhile the service become unavailable, >> you might grab the latest Logfile: >> http://demo.openmeetings.de/jvm.stdout >> >> I might switch back to the previous version later today. >> >> We might at least agree on a road to take to solve those issues. >> >> >> Sebastian >> >> >> 2011/8/8 Maxim Solodovnik <[email protected]> >> >>> Hello Alexei, >>> >>> should i take a look at all these issues? Vasiliy is on vacation right >>> now. >>> >>> >>> On Mon, Aug 8, 2011 at 00:43, [email protected] < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> there are a number of Issues with openJPA and the migration. >>>> The demo server is now updated but I needed several hours to get the >>>> basic functions running again. >>>> >>>> Also the shift with the user_ids in the import/export is still todo for >>>> the profiles_$userId thing. >>>> Somehow we could agree that we make a unique MD5 hash for each user for >>>> his profile path. >>>> >>>> The user sign up process is basically fixed, however when you repress >>>> the button to sign up again, or you just enter an existing user again, it >>>> will show the message that you have successfully signup, instead of showing >>>> a message that the user/login is already taken (which is what already >>>> implemented). >>>> >>>> I think there is really quite a bit to test and fix, the openmeetings >>>> service became unresponsible/did not react to any user interaction after >>>> just 30 minutes without any message about the reason in the logfile. >>>> >>>> Also there are Issue with the Caching. Example: >>>> I do create a new conference room with type restricted, max number 16, >>>> type public >>>> goto conference rooms, see the conference room, >>>> go back to administration, edit that room set max number to 100, >>>> goto conference rooms, see the conference room => STILL 16 >>>> >>>> => That is really bad, cause to track down this problem you really will >>>> need to rethink the hole procedure of insert/update/delete and how it >>>> behaves by running in multiple Threads. This behaviour can lead to various >>>> unpredictable situations, strongly depending on what usage scenario and how >>>> many records you already have in the database >>>> I've spend weeks to track down such problems with the previous >>>> implementation, where the only really solution is to use the spring >>>> injected >>>> session and let spring manage the session-context. However it really needs >>>> some in depth testing. We can hardly release a package right now. >>>> >>>> Sebastian >>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> http://www.webbase-design.de >>>> http://openmeetings.googlecode.com >>>> http://www.wagner-sebastian.com >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> Sebastian Wagner >> http://www.webbase-design.de >> http://openmeetings.googlecode.com >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax > -- 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.
