RE: Class loader behavior with resource bundles...
I have only one guess: you've got the wrong package (or no package) in your
ListResourceBundle implementation,...
-- Bill K.
> -Original Message-
> From: James Lehmer [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 6:48 PM
> To: [EMAIL PROTECTED]
> Subject: Class loader behavior with resource bundles...
>
>
> First off, if the following has an answer that's been posted
> before, my
> apologies. I searched the archives (and the Web in general)
> and didn't get
> any hits. Really. I swear! :-)
>
> I am going to try and be as detailed as possible, because it
> appears that it
> COULD be a Tomcat bug, since the behavior displayed is
> different depending
> on whether it's Tomcat under Windows 2000 or Linux. So bear
> with me, this is
> long. However, I'd appreciate any insight, if it is NOT a
> bug, as to why the
> behavior is different on those two platforms, and what we
> could have done to
> have mitigated it in the first place. Luckily, I found out
> how to fix the
> non-optimal behavior, but that just leaves me confused as to why, and
> nervous that we don't understand the environment as well as
> we should (what
> else is lurking to bite us?)
>
> o Tomcat version 3.1.1
> o Redhat 7.0 with up2date on everything within a week or so.
> o Windows 2000 SP1
> o JDK 1.3
>
> 1) I created a set of Java classes in a package, let's call
> it com.foo.bar.
> There are the main classes, some exception classes, and a
> ListResourceBundle
> class, FooListResourceBundle, for holding error messages used when an
> exception is thrown.
>
> 2) The main classes in com.foo.bar load the resource bundle
> in a static
> initializer as follows:
>
> /**
> *** Initialize error messages.
> **/
> static
> {
> try
> {
> msgs =
> java.util.ResourceBundle.getBundle("com.foo.bar.FooListResourc
> eBundle");
> }
> catch (Throwable t)
> {
> // Note that we can't throw our own exception here
> // (not allowed in static initializers).
> // See initializer() for where we DO throw the exception
> // if this didn't load correctly.
> }
> }
>
> As per the comments, the initializer method, called by all
> constructors,
> simply checks the msgs field for null, and throws an
> exception if it is so.
> This is how we know the problem exists later on.
>
> 3) Tested the library code using unit tests at the command
> line. Everything
> works great.
>
> 4) Published code to colleague who is doing actual servlet writing.
> Colleague is developing under Windows 2000, running Tomcat there. He
> installed my code (more on that in a bit), wrote his servlets
> to call it,
> tested it. Everything worked great.
>
> 5) Colleague published his code, along with mine, to QA. QA is running
> Tomcat under Linux (the final product distribution will be released on
> Linux). Right away, we get the first error, which is the
> exception from my
> main class that is thrown in the initializer method when it
> detects the
> resource bundle wasn't successfully loaded.
>
> 6) Started poking around. I delivered the code to my
> colleague in both jar
> and class file forms, he has decided to install it for his servlet as
> classes under WEB-INF/classes/com/foo/bar. The class loader
> is obviously
> finding the main class from there (since that class is
> throwing a custom
> exception because it can't find the resource bundle), so why
> can't it load
> the resource bundle class file, which is in the same package,
> from the same
> location?
>
> 7) After much hacking and poking around, I figure out that I
> can get past
> this if I create a properties file that has the appropriate
> contents in it,
> and place it under $TOMCAT_HOME/classes/com/foo/bar. Placing
> the class file
> there doesn't work. Only the properties file works (as far as
> loading is
> concerned, but read on). See java.util.ResourceBundle JDK
> docs if you don't
> know about being able to back a bundle with a properties file.
>
> 8) So, I think "that's weird", but am happy - kind of.
> Because (a) I still
> don't know WHY the class loader choked, and (b) the lack of
> problems lasts
> for about a day. Then I get a new bug from QA. This one
> occurs when my main
> class tries to throw an exception and tries to look up an
> error message from
> the resource bundle (which is now backed by the properties
> file, remember).
> In this case, the message is:
>
> Error: 500 Location: /you/go Internal Servlet Error:
> java.lang.ClassFormatError: com/foo/bar/FooListResourceBundle (Illegal
> constant pool index)
>
> Arg!
>
> 9) I do some more hacking around. Finally figure out that
> everything will
> work great if I use the jar file, Foo.jar, and place it in
> WEB-INF/lib. I
> also have to remove the existing class files from
> WEB-INF/classes/com/foo/bar, or otherwise the main class gets
> loaded from
> there first, and we are back to the symptoms in #5.
RE: Class loader behavior with resource bundles...
> I have only one guess: you've got the wrong package (or no > package) in your > ListResourceBundle implementation,... No - I just double-checked that, and it's the same package (correctly spelled :-). Remember: 1) It works when the class unit tests are exercised on the command line. 2) It works on Tomcat under W2K. Jim Dilbert: I *have* a personality! Dogbert: Let's not get into that "Is zero a number" debate again. smime.p7s
Re: Class loader behavior with resource bundles...
Hi Jim,
I've had my fair share of fun trying to use getResourceBundle to load a
properties file and made basically the same discoveries you have. The
properties file say bar.properties gets loaded as
ResourceBundle.getBundle("org.foo.bar") and must be in
WEB-INF/classes/org/foo/bar.properties. This is so Tomcat can find the
properties file in the web applications classpath- otherwise it doesn't know
where it is-
Jason
James Lehmer wrote:
> First off, if the following has an answer that's been posted before, my
> apologies. I searched the archives (and the Web in general) and didn't get
> any hits. Really. I swear! :-)
>
> I am going to try and be as detailed as possible, because it appears that it
> COULD be a Tomcat bug, since the behavior displayed is different depending
> on whether it's Tomcat under Windows 2000 or Linux. So bear with me, this is
> long. However, I'd appreciate any insight, if it is NOT a bug, as to why the
> behavior is different on those two platforms, and what we could have done to
> have mitigated it in the first place. Luckily, I found out how to fix the
> non-optimal behavior, but that just leaves me confused as to why, and
> nervous that we don't understand the environment as well as we should (what
> else is lurking to bite us?)
>
> o Tomcat version 3.1.1
> o Redhat 7.0 with up2date on everything within a week or so.
> o Windows 2000 SP1
> o JDK 1.3
>
> 1) I created a set of Java classes in a package, let's call it com.foo.bar.
> There are the main classes, some exception classes, and a ListResourceBundle
> class, FooListResourceBundle, for holding error messages used when an
> exception is thrown.
>
> 2) The main classes in com.foo.bar load the resource bundle in a static
> initializer as follows:
>
> /**
> *** Initialize error messages.
> **/
> static
> {
> try
> {
> msgs =
> java.util.ResourceBundle.getBundle("com.foo.bar.FooListResourceBundle");
> }
> catch (Throwable t)
> {
> // Note that we can't throw our own exception here
> // (not allowed in static initializers).
> // See initializer() for where we DO throw the exception
> // if this didn't load correctly.
> }
> }
>
> As per the comments, the initializer method, called by all constructors,
> simply checks the msgs field for null, and throws an exception if it is so.
> This is how we know the problem exists later on.
>
> 3) Tested the library code using unit tests at the command line. Everything
> works great.
>
> 4) Published code to colleague who is doing actual servlet writing.
> Colleague is developing under Windows 2000, running Tomcat there. He
> installed my code (more on that in a bit), wrote his servlets to call it,
> tested it. Everything worked great.
>
> 5) Colleague published his code, along with mine, to QA. QA is running
> Tomcat under Linux (the final product distribution will be released on
> Linux). Right away, we get the first error, which is the exception from my
> main class that is thrown in the initializer method when it detects the
> resource bundle wasn't successfully loaded.
>
> 6) Started poking around. I delivered the code to my colleague in both jar
> and class file forms, he has decided to install it for his servlet as
> classes under WEB-INF/classes/com/foo/bar. The class loader is obviously
> finding the main class from there (since that class is throwing a custom
> exception because it can't find the resource bundle), so why can't it load
> the resource bundle class file, which is in the same package, from the same
> location?
>
> 7) After much hacking and poking around, I figure out that I can get past
> this if I create a properties file that has the appropriate contents in it,
> and place it under $TOMCAT_HOME/classes/com/foo/bar. Placing the class file
> there doesn't work. Only the properties file works (as far as loading is
> concerned, but read on). See java.util.ResourceBundle JDK docs if you don't
> know about being able to back a bundle with a properties file.
>
> 8) So, I think "that's weird", but am happy - kind of. Because (a) I still
> don't know WHY the class loader choked, and (b) the lack of problems lasts
> for about a day. Then I get a new bug from QA. This one occurs when my main
> class tries to throw an exception and tries to look up an error message from
> the resource bundle (which is now backed by the properties file, remember).
> In this case, the message is:
>
> Error: 500 Location: /you/go Internal Servlet Error:
> java.lang.ClassFormatError: com/foo/bar/FooListResourceBundle (Illegal
> constant pool index)
>
> Arg!
>
> 9) I do some more hacking around. Finally figure out that everything will
> work great if I use the jar file, Foo.jar, and place it in WEB-INF/lib. I
> also have to remove the existing class files from
> WEB-INF/classes/com/foo/bar, or otherwise the main class gets loaded from
> there first, and we are back to the symptoms in #5.
>
> So, wise ones on the list, I beseech thee! What were w
Re: Class loader behavior with resource bundles...
On Tue, 20 Mar 2001, Jason Novotny wrote:
>
> Hi Jim,
>
>
> I've had my fair share of fun trying to use getResourceBundle to load a
> properties file and made basically the same discoveries you have. The
> properties file say bar.properties gets loaded as
> ResourceBundle.getBundle("org.foo.bar") and must be in
> WEB-INF/classes/org/foo/bar.properties. This is so Tomcat can find the
> properties file in the web applications classpath- otherwise it doesn't know
> where it is-
>
It is also standard behavior of Java with respect to class paths, and is
not specific to Tomcat. Resource bundles have to follow the same
directory structure rules as a class named org.foo.bar would.
> Jason
>
Craig McClanahan
RE: Class loader behavior with resource bundles...
> I've had my fair share of fun trying to use getResourceBundle
> to load a
> properties file and made basically the same discoveries you have. The
> properties file say bar.properties gets loaded as
> ResourceBundle.getBundle("org.foo.bar") and must be in
> WEB-INF/classes/org/foo/bar.properties. This is so Tomcat can find the
> properties file in the web applications classpath- otherwise it
> doesn't know
> where it is-
When I tried placing the properties file in
WEB-INF/classes/com/foo/bar/FooListResourceBundle.properties (to use the
naming convention of my example in the post) it was not found. Only when I
placed it in
$TOMCAT_HOME/classes/com/foo/bar/FooListResourceBundle.properties was it
found (but then I got the second error).
Jim
Dilbert: I *have* a personality!
Dogbert: Let's not get into that "Is zero a number" debate again.
smime.p7s
RE: Class loader behavior with resource bundles...
> It is also standard behavior of Java with respect to class paths, and is > not specific to Tomcat. Resource bundles have to follow the same > directory structure rules as a class named org.foo.bar would. It WAS in the same directory structure, as my post pointed out. The resource bundle IS in the same package as the main class, IS stored in the same directory as the main class, DOES work when loaded from either the command line tests or Tomcat under Windows 2000, DOES work when loaded from a jar file (which contains the SAME class directory structure, DOES NOT work under Tomcat on Linux. This is NOT an "it's in the wrong place" problem, per se. If it were, it would've been caught under the command line testing and/or under Tomcat on Windows 2000. This is a "why is Linux Tomcat different than Windows 2000 Tomcat" issue, IMHO. Jim Dilbert: I *have* a personality! Dogbert: Let's not get into that "Is zero a number" debate again. smime.p7s
RE: Class loader behavior with resource bundles...
I have a question. How to you pass a data stream with XML using URL
connection object to test a servlet on Tomcat?
I am having problems in sending across this data stream to Tomcat.
Thanks
-Original Message-
From: William Kaufman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 10:04 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Class loader behavior with resource bundles...
I have only one guess: you've got the wrong package (or no package) in your
ListResourceBundle implementation,...
-- Bill K.
> -Original Message-
> From: James Lehmer [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 6:48 PM
> To: [EMAIL PROTECTED]
> Subject: Class loader behavior with resource bundles...
>
>
> First off, if the following has an answer that's been posted
> before, my
> apologies. I searched the archives (and the Web in general)
> and didn't get
> any hits. Really. I swear! :-)
>
> I am going to try and be as detailed as possible, because it
> appears that it
> COULD be a Tomcat bug, since the behavior displayed is
> different depending
> on whether it's Tomcat under Windows 2000 or Linux. So bear
> with me, this is
> long. However, I'd appreciate any insight, if it is NOT a
> bug, as to why the
> behavior is different on those two platforms, and what we
> could have done to
> have mitigated it in the first place. Luckily, I found out
> how to fix the
> non-optimal behavior, but that just leaves me confused as to why, and
> nervous that we don't understand the environment as well as
> we should (what
> else is lurking to bite us?)
>
> o Tomcat version 3.1.1
> o Redhat 7.0 with up2date on everything within a week or so.
> o Windows 2000 SP1
> o JDK 1.3
>
> 1) I created a set of Java classes in a package, let's call
> it com.foo.bar.
> There are the main classes, some exception classes, and a
> ListResourceBundle
> class, FooListResourceBundle, for holding error messages used when an
> exception is thrown.
>
> 2) The main classes in com.foo.bar load the resource bundle
> in a static
> initializer as follows:
>
> /**
> *** Initialize error messages.
> **/
> static
> {
> try
> {
> msgs =
> java.util.ResourceBundle.getBundle("com.foo.bar.FooListResourc
> eBundle");
> }
> catch (Throwable t)
> {
> // Note that we can't throw our own exception here
> // (not allowed in static initializers).
> // See initializer() for where we DO throw the exception
> // if this didn't load correctly.
> }
> }
>
> As per the comments, the initializer method, called by all
> constructors,
> simply checks the msgs field for null, and throws an
> exception if it is so.
> This is how we know the problem exists later on.
>
> 3) Tested the library code using unit tests at the command
> line. Everything
> works great.
>
> 4) Published code to colleague who is doing actual servlet writing.
> Colleague is developing under Windows 2000, running Tomcat there. He
> installed my code (more on that in a bit), wrote his servlets
> to call it,
> tested it. Everything worked great.
>
> 5) Colleague published his code, along with mine, to QA. QA is running
> Tomcat under Linux (the final product distribution will be released on
> Linux). Right away, we get the first error, which is the
> exception from my
> main class that is thrown in the initializer method when it
> detects the
> resource bundle wasn't successfully loaded.
>
> 6) Started poking around. I delivered the code to my
> colleague in both jar
> and class file forms, he has decided to install it for his servlet as
> classes under WEB-INF/classes/com/foo/bar. The class loader
> is obviously
> finding the main class from there (since that class is
> throwing a custom
> exception because it can't find the resource bundle), so why
> can't it load
> the resource bundle class file, which is in the same package,
> from the same
> location?
>
> 7) After much hacking and poking around, I figure out that I
> can get past
> this if I create a properties file that has the appropriate
> contents in it,
> and place it under $TOMCAT_HOME/classes/com/foo/bar. Placing
> the class file
> there doesn't work. Only the properties file works (as far as
> loading is
> concerned, but read on). See java.util.ResourceBundle JDK
> docs if you don't
> know about being able to back a bundle with a properties file.
>
> 8) So, I think "that's weird", but am happy - kind of.
> Because (a) I still
RE: Class loader behavior with resource bundles...
Jim, Does it work in the command line tests under both Linux and Win2K? I just want to make sure the JDK itself is ruled out. Personally, we've run into instances where regular .properties files aren't found under Tomcat if they're in WEB-INF/classes; but if we put them in a package directory under that and then load them accordingly, they are found. Donnie >>> [EMAIL PROTECTED] 03/21/01 08:39AM >>> > It is also standard behavior of Java with respect to class paths, and is > not specific to Tomcat. Resource bundles have to follow the same > directory structure rules as a class named org.foo.bar would. It WAS in the same directory structure, as my post pointed out. The resource bundle IS in the same package as the main class, IS stored in the same directory as the main class, DOES work when loaded from either the command line tests or Tomcat under Windows 2000, DOES work when loaded from a jar file (which contains the SAME class directory structure, DOES NOT work under Tomcat on Linux. This is NOT an "it's in the wrong place" problem, per se. If it were, it would've been caught under the command line testing and/or under Tomcat on Windows 2000. This is a "why is Linux Tomcat different than Windows 2000 Tomcat" issue, IMHO. Jim Dilbert: I *have* a personality! Dogbert: Let's not get into that "Is zero a number" debate again.
RE: Class loader behavior with resource bundles...
> Does it work in the command line tests under both Linux and
> Win2K? I just want to make sure the JDK itself is ruled out.
>
> Personally, we've run into instances where regular .properties
> files aren't found under Tomcat if they're in WEB-INF/classes;
> but if we put them in a package directory under that and then
> load them accordingly, they are found.
Good question, and one I started researching this morning ("Hmmm - could
it be a JVM difference?").
Yes, the command line tests DO work under Linux as well as Win2K, so it
doesn't appear to be a JVM/JDK issue (running JDK 1.3 on both OSes).
Jim
Dilbert: I *have* a personality!
Dogbert: Let's not get into that "Is zero a number" debate again.
smime.p7s
