[jboss-user] [Beginner's Corner] - Re: JBOSS 5.1 Server -> org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider
Amar Kintu [http://community.jboss.org/people/amar4kintu] created the discussion "Re: JBOSS 5.1 Server -> org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider" To view the discussion, visit: http://community.jboss.org/message/563705#563705 -- Hello Fabian Krüger, Thanks for the answer. I have also checked it by removing all jar files that are provided by JBOSS server from my /WEB-INF/lib directory. But problem seems to be same. After searching lot in Google and putting question in different forums, I come to know that JBOSS 5.1 is very tightly coupled with JPA 1.0. So it is not possible to use JPA 2.0 with JBOSS 5.1 server. So now I am trying things with JPA 1.0. Let me know if you have any other ideas. Thanks. Amar -- Reply to this message by going to Community [http://community.jboss.org/message/563705#563705] Start a new discussion in Beginner's Corner at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2075] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools] - Re: 64 bit xulrunner - has anyone got one, or detailed steps to build one?
henk de boer [http://community.jboss.org/people/henk53] created the discussion "Re: 64 bit xulrunner - has anyone got one, or detailed steps to build one?" To view the discussion, visit: http://community.jboss.org/message/563689#563689 -- > Max Andersen wrote: > > Yes, we should make it optional: https://jira.jboss.org/browse/JBIDE-7058 > https://jira.jboss.org/browse/JBIDE-7058 > > It is better you can install and have 95% of the functionallity working than > not being able to install at all. Indeed, thanks again for the effort. I'm sure there are people who use the preview and visual stuff a lot, but I'm really more of a text guy myself and currently use the editor for it's good .xhtml support and content assist etc. There may be more people like me ;) -- Reply to this message by going to Community [http://community.jboss.org/message/563689#563689] Start a new discussion in JBoss Tools at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2128] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [jBPM] - Re: Concept of different locales/time zones in jBPM5
Michael Wohlfart [http://community.jboss.org/people/mwohlf] created the discussion "Re: Concept of different locales/time zones in jBPM5" To view the discussion, visit: http://community.jboss.org/message/563675#563675 -- Hi Peter, I agree with you that timezones should be considered from the beginning of jBPM5's development. But I don't see your point about jBPM4, what i don't understand is this: > [...] > The problem is that the current implementation of jBPM neither store nor use > UTC time and date internally: the engine always rely on the local time and > date which can lead issues in an environment where your clients are in > different locations (and time zones) > [...] > The current implementation simply returns 'new Date()' which contains the > local timestamp. If the UTC time was returned here that would mean that you > store the date consistently from all locations but at the same time, you > would also have to modify the code in a lot of places (date based queries in > service interfaces; JobExecutor service scheduling etc) so I am a bit > reluctant to say that all these parts should be rewritten. Why do you think the engine uses local time internally? This is from JavaDoc for java.util.Date: > Although the Date class is intended to reflect coordinated universal time > (UTC), it may not do so exactly, depending on the host environment of the > Java Virtual Machine. Nearly all modern operating systems assume that 1 day > = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once > every year or two there is an extra second, called a "leap second." The > leap second is always added as the last second of the day, and always on > December 31 or June 30. For example, the last minute of the year 1995 was > 61 seconds long, thanks to an added leap second. Most computer clocks are > not accurate enough to be able to reflect the leap-second distinction. So my understanding so far was that jBPM4 uses UTC already internally (which may be off by some seconds on some platforms), but as far as I understand you don't agree on that? -- Reply to this message by going to Community [http://community.jboss.org/message/563675#563675] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
