Locale Issue on Debian/JBoss/Tomcat/SunJVM
Hi guys, I was just wondering whether anybody has encountered a similar situation to the following We have an application we developed that we run on JBoss. When we ran it on a Debian machine it seemed to ignore the machines locale (en_NZ) and use US date formats instead. The odd thing being that a Redhat machine with exactly the same locale settings, and the same JBoss/JDK installation worked correctly though. A W2K and a Solaris machine also worked correctly (same JBoss installation and Sun JDK version). Debian itself was using the local date formats correctly eg with 'date +%x' from bash, and JBoss on Debian would show the correct date format if the user region and language were hard coded into $JAVA_OPTS in the run.sh startup script. ie: JAVA_OPTS="$JAVA_OPTS -Duser.region=NZ -Duser.language=en" Is this a case of Sun not testing their JVM quite well enough on Debian? (if at all) Or have we set up our locale incorrectly? (details below) Software Versions: Debian Woody x86 jboss-3.0.3_tomcat-4.1.12 (downloaded from jboss.org) Sun's j2sdk-1_4_1_01-linux-i586 (the non rpm install) Locale set by 'LANG=en_NZ' in /etc/environment (only line present). Output of 'locale': LANG=en_NZ LC_CTYPE="en_NZ" LC_NUMERIC="en_NZ" LC_TIME="en_NZ" LC_COLLATE="en_NZ" LC_MONETARY="en_NZ" LC_MESSAGES="en_NZ" LC_PAPER="en_NZ" LC_NAME="en_NZ" LC_ADDRESS="en_NZ" LC_TELEPHONE="en_NZ" LC_MEASUREMENT="en_NZ" LC_IDENTIFICATION="en_NZ" LC_ALL= Has anybody else noticed that or tried to confirm it? Cheers Anton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#176629: gij-3.2: package incorrctly provides java1-runtime
Stephen Zander writes: > Package: gij-3.2 > Version: 1:3.2.2-0pre5 > Severity: important > > According to the Java policy, packages that provide java1-runtime must > support the the complete java runtime environment. As gij fails to > provide the java.awt.* classes, the provides on this package is > incorrect. Please remove it until such time as gij has support for > java.awt.*. so which runtimes do have complete awt support at all? The provides was added to build all packages which do not relay on all awt functionality. I would have to search the bug report ... what does the java policy say for these cases? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#176629: gij-3.2: package incorrctly provides java1-runtime
> > According to the Java policy, packages that provide java1-runtime must > > support the the complete java runtime environment. Well, AFAICT (looking at policy linked to www.debian.org), the Java policy isn't particularly explicit. Section 2.1 states: Java virtual machines must provide java-virtual-machine and depend on java-common. They can also provide the runtime environment that the package contains (java1-runtime and/or java2-runtime). If it does not provide the files itself it must depend on the needed runtime environment. My understanding is that the free JVMs are in various states of support for java1 and java2. For instance (and I could be wrong), gij support most but not all of java1, but also supports a fair amount of java2. The supported runtime environment for any given JVM is not at all black and white. If we're going to follow the policy so pedantically that the only JVMs supporting java1-runtime are those that fill the entirity of Sun's java1 spec, I'd say we've defeated the purpose of these virtual packages. For instance, most of the Java apps I maintain require some level of runtime classes, so I can't just depend on java-virtual-machine. But they pretty much run on most/all free JVMs, and I'd like to acknowledge that and allow the user choice in which JVM they use. Do I then have to Depend: gij | kaffe | sablevm | orp | etc etc etc? I'd really like this issue to be resolved on [EMAIL PROTECTED] before JVMs start removing java1-runtime from their provides lists as requested by these bug reports. If AWT specifically is going to be a big problem, perhaps even a third virtual package: java1-runtime, java1-awt-runtime, java2-runtime? CCing this to #176628 since a similar bug seems to have been filed on sablevm. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
retitle 176628 java.awt.* classess don't work as expected for java1-runtime thanks W liście z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > Package: sablevm > Version: 1.0.5-1 > Severity: important > > According to the Java policy, packages that provide java1-runtime must > support the the complete java runtime environment. As sablevm fails > to provide working java.awt.* classes, the provides on this package is > incorrect. Please remove it until such time as sablevm has working > support for java.awt.*. I searched for "runtime" in Java Policy (as found in java-common package) and couldn't find such explict statment. But even if it were there - I *refuse* to remove this Provides: because Sablevm _does_ provide java1 runtime env. with the expeption of things which don't work yet. *These things* I belive can be easily called bugs for simplicity. Severity "important" seems to be the right one here: "important - a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone" We all know that the fight for free Java (tfffj) is only beginning. And I don't think we would support free java and free software by marking every of today's free JVMs and their classlibs as unusable because of some lacks or bugs. Especially when there's effort under way to remove them. The Java Policy is to help us, to support us and to guide us. The Java Policy is for us, not the other way. Kind regards Grzegorz B. Prokopski signature.asc Description: PGP signature
Re: JBoss debs?
On Sat, 2003-01-11 at 07:55, Greg Wilkins wrote: > I'm the main developer of the Jetty HTTPServer and Servlet > container and a core developer on JBoss. > > Just a reminder (as I've emailed Joe before) that I'm more than > happy to: I haven't forgotten. Thanks for the group reminder though. I'm just not sure what help I need just yet. Right now, I don't think I need any other than maybe testing of my debs. > + lobby the JBoss project to make any changes that may > assist you with your packaging (not sure of how successful > that will be). At some point this will probably be helpful. Today, my changes are minimal so there's nothing much to go upstream. I do suspect that over time my changes will become considerable so some discussions will need to be had and agreements made. It would be nice to eventually get at least portions of the debian/ stuff into JBOSS CVS though, so packages may be built directly out of CVS. For example, the fact that JBOSS embeds *all* of it's dependancies (log4j, tomcat, etc etc) rather than using external libraries will likely cause problems for me as I try to retool JBOSS to use debian versions of libraries. > + Help with any changes you need to make to support the more > recent versions of JBoss that are based on the Jetty HTTPServer. I have a 3.2 CVS snapshot that I'm looking to package in the near future. > + Help *anybody* who wants to make a standalone jetty deb. I wouldn't mind doing this, I just don't currently use Jetty so I wouldn't know what to package or how to test it. We have internally discussed using Jetty for our sites (or at least exploring it) but haven't had the time to do proper testing. > I use debian, but I don't know anything about creating debians. > So I can't be proactive on this. But I can offer lots of > help to anybody who takes the lead on this and tells me what is > needed. Today, comments, feedback and testing are a good start. Going forward, someone on 'my side', lobbying the JBOSS team to get things into upstream would be great. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JBOSS debs updated
All, After my last email regarding my new JBOSS debs, I found some showstopper bugs within the package (ie. they didn't work). I spent yesterday rebuilding and testing my debs. The versions currently on my company site[1] have been tested to properly start/stop the server without exceptions. The buggy packages were the jboss-server-* packages. If you installed the older versions, please remove/purge them and update your systems. -joe [1] http://debian.innovationsw.com/ -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Locale Issue on Debian/JBoss/Tomcat/SunJVM
Hi guys, I was just wondering whether anybody has encountered a similar situation to the following We have an application we developed that we run on JBoss. When we ran it on a Debian machine it seemed to ignore the machines locale (en_NZ) and use US date formats instead. The odd thing being that a Redhat machine with exactly the same locale settings, and the same JBoss/JDK installation worked correctly though. A W2K and a Solaris machine also worked correctly (same JBoss installation and Sun JDK version). Debian itself was using the local date formats correctly eg with 'date +%x' from bash, and JBoss on Debian would show the correct date format if the user region and language were hard coded into $JAVA_OPTS in the run.sh startup script. ie: JAVA_OPTS="$JAVA_OPTS -Duser.region=NZ -Duser.language=en" Is this a case of Sun not testing their JVM quite well enough on Debian? (if at all) Or have we set up our locale incorrectly? (details below) Software Versions: Debian Woody x86 jboss-3.0.3_tomcat-4.1.12 (downloaded from jboss.org) Sun's j2sdk-1_4_1_01-linux-i586 (the non rpm install) Locale set by 'LANG=en_NZ' in /etc/environment (only line present). Output of 'locale': LANG=en_NZ LC_CTYPE="en_NZ" LC_NUMERIC="en_NZ" LC_TIME="en_NZ" LC_COLLATE="en_NZ" LC_MONETARY="en_NZ" LC_MESSAGES="en_NZ" LC_PAPER="en_NZ" LC_NAME="en_NZ" LC_ADDRESS="en_NZ" LC_TELEPHONE="en_NZ" LC_MEASUREMENT="en_NZ" LC_IDENTIFICATION="en_NZ" LC_ALL= Has anybody else noticed that or tried to confirm it? Cheers Anton
Re: Bug#176629: gij-3.2: package incorrctly provides java1-runtime
Stephen Zander writes: > Package: gij-3.2 > Version: 1:3.2.2-0pre5 > Severity: important > > According to the Java policy, packages that provide java1-runtime must > support the the complete java runtime environment. As gij fails to > provide the java.awt.* classes, the provides on this package is > incorrect. Please remove it until such time as gij has support for > java.awt.*. so which runtimes do have complete awt support at all? The provides was added to build all packages which do not relay on all awt functionality. I would have to search the bug report ... what does the java policy say for these cases?
Re: Bug#176629: gij-3.2: package incorrctly provides java1-runtime
> > According to the Java policy, packages that provide java1-runtime must > > support the the complete java runtime environment. Well, AFAICT (looking at policy linked to www.debian.org), the Java policy isn't particularly explicit. Section 2.1 states: Java virtual machines must provide java-virtual-machine and depend on java-common. They can also provide the runtime environment that the package contains (java1-runtime and/or java2-runtime). If it does not provide the files itself it must depend on the needed runtime environment. My understanding is that the free JVMs are in various states of support for java1 and java2. For instance (and I could be wrong), gij support most but not all of java1, but also supports a fair amount of java2. The supported runtime environment for any given JVM is not at all black and white. If we're going to follow the policy so pedantically that the only JVMs supporting java1-runtime are those that fill the entirity of Sun's java1 spec, I'd say we've defeated the purpose of these virtual packages. For instance, most of the Java apps I maintain require some level of runtime classes, so I can't just depend on java-virtual-machine. But they pretty much run on most/all free JVMs, and I'd like to acknowledge that and allow the user choice in which JVM they use. Do I then have to Depend: gij | kaffe | sablevm | orp | etc etc etc? I'd really like this issue to be resolved on [EMAIL PROTECTED] before JVMs start removing java1-runtime from their provides lists as requested by these bug reports. If AWT specifically is going to be a big problem, perhaps even a third virtual package: java1-runtime, java1-awt-runtime, java2-runtime? CCing this to #176628 since a similar bug seems to have been filed on sablevm. Ben.
Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
retitle 176628 java.awt.* classess don't work as expected for java1-runtime thanks W liście z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > Package: sablevm > Version: 1.0.5-1 > Severity: important > > According to the Java policy, packages that provide java1-runtime must > support the the complete java runtime environment. As sablevm fails > to provide working java.awt.* classes, the provides on this package is > incorrect. Please remove it until such time as sablevm has working > support for java.awt.*. I searched for "runtime" in Java Policy (as found in java-common package) and couldn't find such explict statment. But even if it were there - I *refuse* to remove this Provides: because Sablevm _does_ provide java1 runtime env. with the expeption of things which don't work yet. *These things* I belive can be easily called bugs for simplicity. Severity "important" seems to be the right one here: "important - a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone" We all know that the fight for free Java (tfffj) is only beginning. And I don't think we would support free java and free software by marking every of today's free JVMs and their classlibs as unusable because of some lacks or bugs. Especially when there's effort under way to remove them. The Java Policy is to help us, to support us and to guide us. The Java Policy is for us, not the other way. Kind regards Grzegorz B. Prokopski signature.asc Description: PGP signature
Re: JBoss debs?
On Sat, 2003-01-11 at 07:55, Greg Wilkins wrote: > I'm the main developer of the Jetty HTTPServer and Servlet > container and a core developer on JBoss. > > Just a reminder (as I've emailed Joe before) that I'm more than > happy to: I haven't forgotten. Thanks for the group reminder though. I'm just not sure what help I need just yet. Right now, I don't think I need any other than maybe testing of my debs. > + lobby the JBoss project to make any changes that may > assist you with your packaging (not sure of how successful > that will be). At some point this will probably be helpful. Today, my changes are minimal so there's nothing much to go upstream. I do suspect that over time my changes will become considerable so some discussions will need to be had and agreements made. It would be nice to eventually get at least portions of the debian/ stuff into JBOSS CVS though, so packages may be built directly out of CVS. For example, the fact that JBOSS embeds *all* of it's dependancies (log4j, tomcat, etc etc) rather than using external libraries will likely cause problems for me as I try to retool JBOSS to use debian versions of libraries. > + Help with any changes you need to make to support the more > recent versions of JBoss that are based on the Jetty HTTPServer. I have a 3.2 CVS snapshot that I'm looking to package in the near future. > + Help *anybody* who wants to make a standalone jetty deb. I wouldn't mind doing this, I just don't currently use Jetty so I wouldn't know what to package or how to test it. We have internally discussed using Jetty for our sites (or at least exploring it) but haven't had the time to do proper testing. > I use debian, but I don't know anything about creating debians. > So I can't be proactive on this. But I can offer lots of > help to anybody who takes the lead on this and tells me what is > needed. Today, comments, feedback and testing are a good start. Going forward, someone on 'my side', lobbying the JBOSS team to get things into upstream would be great. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
JBOSS debs updated
All, After my last email regarding my new JBOSS debs, I found some showstopper bugs within the package (ie. they didn't work). I spent yesterday rebuilding and testing my debs. The versions currently on my company site[1] have been tested to properly start/stop the server without exceptions. The buggy packages were the jboss-server-* packages. If you installed the older versions, please remove/purge them and update your systems. -joe [1] http://debian.innovationsw.com/ -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
