[Persistence, JBoss/CMP, Hibernate, Database] - calendar timezones and database discrepancies
by kagey
Hey All,
I am using EJB3 with hibernate on jboss 4.0.5. I'm testing my application with two different datasources - mysql 5 and oracle 10g.
Ok, so i have an entity that i persist that has a date member of type Calendar. Here is the different functionality that i experience depending on datasource.
On Oracle, if i specify the calendar's date to be noon localtime, and the timezone of the calendar to be local timezone, in the database the date column will be noon. If i change the timezone of the calendar to UTC, the date in the database is in my case (noon + 7 hours) (My current timezone is -7). This functionality makes sense and is what i expected. Since the column types that hibernate creates do not support timezone information, hibernate converts the date to the calendar's timezone before it stores the date.
Using Mysql, the first scenario is the same. But if i change the calendar's timezone to UTC, mysql ignores it and the date stored is the same as the first.
Does anyone know a way to get mysql to consider the timezone of the calendar like the oracle datasource does? Ultimately i would like to get my application to store dates in UTC instead of server localtime, which i can accomplish with oracle but not mysql, so thats my motivation here.
Thanks for listening.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991816#3991816
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991816
19 years, 4 months
[EJB 3.0] - Re: EJB Annotation question?
by jxcheng
Yes, it is in a client application.
Why @EJB annotation does not work there?
Is it due to that JBOSS does not fully implement EJB 3.0?
In Sun's JavaEE 5 tutorial and sample code,
I see the following in a client program:
| package converter.client;
|
| import converter.ejb.Converter;
| import java.math.BigDecimal;
| import javax.ejb.EJB;
|
|
| /**
| *
| * @author ian
| */
| public class ConverterClient {
| @EJB
| private static Converter converter;
|
| /** Creates a new instance of Client */
| public ConverterClient(String[] args) {
| }
|
| /**
| * @param args the command line arguments
| */
| public static void main(String[] args) {
| ConverterClient client = new ConverterClient(args);
| client.doConversion();
| }
|
| public void doConversion() {
| try {
| BigDecimal param = new BigDecimal("100.00");
| BigDecimal yenAmount = converter.dollarToYen(param);
|
| System.out.println("$" + param + " is " + yenAmount + " Yen.");
|
| BigDecimal euroAmount = converter.yenToEuro(yenAmount);
| System.out.println(yenAmount + " Yen is " + euroAmount + " Euro.");
|
| System.exit(0);
| } catch (Exception ex) {
| System.err.println("Caught an unexpected exception!");
| ex.printStackTrace();
| }
| }
| }
|
The client code above works well with Sun's Java System Application Server 9.0.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991815#3991815
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991815
19 years, 4 months
[JBoss Seam] - Re: Seam Log4J wrapper
by quilleashm
I've come across this before when wrapping commons-logging but never come up with a satisfactory fix.
commons-logging works because it passes a Fully Qualified Class Name (FQCN) in to every call to the log4j library (check out the Log4JLogger in commons-logging). The log4j library then uses this as the "entry" point into the logging system and takes the line/method/file of the entry just below it in the stack frame (it uses nasty string searching because StackTraceElement is 1.4+). This obviously goes wrong when something adds another wrapping layer round the commons-logging.
The only "fix" I have come up with, but never implemented, is to plugin a different commons-logging LogFactory implementation, trap the case where it detects log4j as the logging type and return a custom log4j wrapper rather than the one provided by commons-logging. The wrapper would then pass in it's own FQCN that would allow log4j to get the line numbers right.
Another fix would be to use log4j directly in Seam which would make passing in the correct FQCN trivial. Of course doing this may not be viable if commons-logging must be used to support the other log implementations.
If I can spare some time I may look into bodging the first solution together to at least see if it works.
Cheers.
Mike.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991814#3991814
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991814
19 years, 4 months