Re: ApplicationResources.properties - resolution
OK, after I figured out how to grep through the content of all the jar files I could find, it turned up. I had programmed a JAAS login module, placed it in CATALINA_HOME/common/lib, using ApplicationResources.properties (i.e. the same class name that I specified in the app's web.xml under javax.servlet.jsp.jstl.fmt.localizationContext), and using the same strings (e.g. app.title). So JSTL fmt had picked up the ApplicationResources.properties class from the jar in commons/lib, well actually the _de.properties, and used that in my app. And it would presumably have used it in all apps that specified ApplicationResources as the resource bundle name. Perhaps this could be considered counter-intuitive behaviour? I'm not sure. But I think the behaviour should be defined at the next round of spec. writing. Whatever, I'm happy now. :) On 01/21/2004 08:47 PM Evgeny Gesin wrote: Adam, this situation is not obvious. I suggest to run a search command over all* files to look for a specific DE text which you see on the screen. That can give you some ideas what happen at run-time. Evgeny Gesin Javadesk CEO / Founder --- Adam Hardy [EMAIL PROTECTED] wrote: Yes. Searched for all *.properties files in tomcat and in them for the offending strings, but to no avail. I'll try again though just to make sure. On 01/21/2004 03:21 PM Sgarlata Matt wrote: Hi Adam - As another shot in the dark, maybe in your build process you don't delete old .properties files? In the past I left out this step in my build process and had strange results similar to what you are describing. Have you searched your filesystem for the old _de.properties file to see if it's lingering somewhere? Other than that, I too am stumped ... Matt - Original Message - From: Adam Hardy [EMAIL PROTECTED] To: Tag Libraries Users List [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 6:03 AM Subject: Re: ApplicationResources.properties apparently cached Thanks for the response. I know exactly how it must look to people reading this, but what you are suggesting is what I have been doing for the past week. I'm 99% positive that this is not a result of browser or proxy or JSP caching. On 01/21/2004 11:54 AM Evgeny Gesin wrote: I think somethings can be wrong with application or understanding how it works with bundle.properties, if DE still cached. Try to remove compiled pages (under the work directory in Tomcat), stop and start Tomcat and point browser to the same pages again and see what happen. Evgeny Gesin Javadesk CEO / Founder --- Adam Hardy [EMAIL PROTECTED] wrote: Can anybody make any comment about this? Other than that you think I might be losing it? Thanks On 01/20/2004 06:38 PM Adam Hardy wrote: I have set up my i18n properties files for use with the fmt:message taglib (jstl 1.0) via the javax.servlet.jsp.jstl.fmt.localizationContext and I tested it out with DE and EN to make sure my different locales on the browser would generate the correct language text. All worked, and so I deleted the German file, since it was only a test and I'm not ready to do all the proper translation into German yet. I deleted the _en.properties and _de.properties files, and have only a default ApplicationResources.properties so I really can't see where the old German strings are coming from. However the German strings keep appearing in my web pages in German browsers. This has been troubling me for a month now and I'm really determined to fix it. I'm sure it's not being cached by the browser or by a proxy. Chopping and changing the locale in the browser proves that. What also puzzles me is the work-around I did: I recreated the German _de.properties file, and so now I have something sensible (the old strings are pretty stupid random bits of text). But when I deleted this new German file to test if the bug had gone, the old German strings reappeared. What is my next logical step? I'm completely stuck here. Thanks Adam -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApplicationResources.properties - resolution
Which is a good argument for making your bundle basenames unique: com.cyberspaceroad.jaas.ApplicationResources com.cyberspaceroad.app1.ApplicationResources com.cyberspaceroad.app2.ApplicationResources ... For a web app, the property files would reside in WEB-INF/classes/com/cyberspaceroad/app1/ApplicationResources.properties Quoting Evgeny Gesin [EMAIL PROTECTED]: Great! That's because first .properties file found in classpath is used. Evgeny Gesin Javadesk CEO / Founder --- Adam Hardy [EMAIL PROTECTED] wrote: OK, after I figured out how to grep through the content of all the jar files I could find, it turned up. I had programmed a JAAS login module, placed it in CATALINA_HOME/common/lib, using ApplicationResources.properties (i.e. the same class name that I specified in the app's web.xml under javax.servlet.jsp.jstl.fmt.localizationContext), and using the same strings (e.g. app.title). So JSTL fmt had picked up the ApplicationResources.properties class from the jar in commons/lib, well actually the _de.properties, and used that in my app. And it would presumably have used it in all apps that specified ApplicationResources as the resource bundle name. Perhaps this could be considered counter-intuitive behaviour? I'm not sure. But I think the behaviour should be defined at the next round of spec. writing. Whatever, I'm happy now. :) On 01/21/2004 08:47 PM Evgeny Gesin wrote: Adam, this situation is not obvious. I suggest to run a search command over all* files to look for a specific DE text which you see on the screen. That can give you some ideas what happen at run-time. Evgeny Gesin Javadesk CEO / Founder --- Adam Hardy [EMAIL PROTECTED] wrote: Yes. Searched for all *.properties files in tomcat and in them for the offending strings, but to no avail. I'll try again though just to make sure. On 01/21/2004 03:21 PM Sgarlata Matt wrote: Hi Adam - As another shot in the dark, maybe in your build process you don't delete old .properties files? In the past I left out this step in my build process and had strange results similar to what you are describing. Have you searched your filesystem for the old _de.properties file to see if it's lingering somewhere? Other than that, I too am stumped ... Matt - Original Message - From: Adam Hardy [EMAIL PROTECTED] To: Tag Libraries Users List [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 6:03 AM Subject: Re: ApplicationResources.properties apparently cached Thanks for the response. I know exactly how it must look to people reading this, but what you are suggesting is what I have been doing for the past week. I'm 99% positive that this is not a result of browser or proxy or JSP caching. On 01/21/2004 11:54 AM Evgeny Gesin wrote: I think somethings can be wrong with application or understanding how it works with bundle.properties, if DE still cached. Try to remove compiled pages (under the work directory in Tomcat), stop and start Tomcat and point browser to the same pages again and see what happen. Evgeny Gesin Javadesk CEO / Founder --- Adam Hardy [EMAIL PROTECTED] wrote: Can anybody make any comment about this? Other than that you think I might be losing it? Thanks On 01/20/2004 06:38 PM Adam Hardy wrote: I have set up my i18n properties files for use with the fmt:message taglib (jstl 1.0) via the javax.servlet.jsp.jstl.fmt.localizationContext and I tested it out with DE and EN to make sure my different locales on the browser would generate the correct language text. All worked, and so I deleted the German file, since it was only a test and I'm not ready to do all the proper translation into German yet. I deleted the _en.properties and _de.properties files, and have only a default ApplicationResources.properties so I really can't see where the old German strings are coming from. However the German strings keep appearing in my web pages in German browsers. This has been troubling me for a month now and I'm really determined to fix it. I'm sure it's not being cached by the browser or by a proxy. Chopping and changing the locale in the browser proves that. What also puzzles me is the work-around I did: I recreated the German _de.properties file, and so now I have something sensible (the old strings are pretty stupid random bits of text). But when I deleted this
How can I get the size of a java.util.List class from JSTL?
Hi, how can I replace the code below with a JSTL command ? (scc_history points to a java.util.List class). bean:size id=nr_of_scc_history name=scc_history / Zsolt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
http 500 when i add depends-required
Hello. I just started using the struts validator...I am trying to
validate a single field in a form. When I validate for minlength, it
works properly. However, when I add 'required' to the list of depends,
I get an HTTP 500 when I am forwarded to the page where the validation
will occur. It runs through the action as expected, but it dies when it
tries to forward to the JSP...I've included a snippet of my xml below:
The following works perfectly:
form name=personDemographicsForm
field property=firstName depends=minlength
arg0 key=button.update/
arg1 key=${var:minlength} name=minlength resource=false/
var
var-nameminlength/var-name
var-value5/var-value
/var
/field
/form
The following causes the HTTP 500:
form name=personDemographicsForm
field property=firstName depends=minlength, required
arg0 key=button.update/
arg1 key=${var:minlength} name=minlength resource=false/
var
var-nameminlength/var-name
var-value5/var-value
/var
/field
/form
Any help is greatly appreciated. Thanks
chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get the size of a java.util.List class from JSTL?
Zsolt wrote: Hi, how can I replace the code below with a JSTL command ? (scc_history points to a java.util.List class). bean:size id=nr_of_scc_history name=scc_history / You'll have to wait for JSTL 1.1/JSP 2.0. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: http 500 when i add depends-required
Please disregard. I failed to set validate to false on the way in,
and it failed when validating. It was throwing the error - Validation
failed but no input form available - but I didn't see that originally.
thanks
chris
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 10:13 AM
To: [EMAIL PROTECTED]
Subject: http 500 when i add depends-required
Hello. I just started using the struts validator...I am trying to
validate a single field in a form. When I validate for minlength, it
works properly. However, when I add 'required' to the list of depends,
I get an HTTP 500 when I am forwarded to the page where the validation
will occur. It runs through the action as expected, but it dies when it
tries to forward to the JSP...I've included a snippet of my xml below:
The following works perfectly:
form name=personDemographicsForm
field property=firstName depends=minlength
arg0 key=button.update/
arg1 key=${var:minlength} name=minlength resource=false/
var
var-nameminlength/var-name
var-value5/var-value
/var
/field
/form
The following causes the HTTP 500:
form name=personDemographicsForm
field property=firstName depends=minlength, required
arg0 key=button.update/
arg1 key=${var:minlength} name=minlength resource=false/
var
var-nameminlength/var-name
var-value5/var-value
/var
/field
/form
Any help is greatly appreciated. Thanks
chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get the size of a java.util.List class from JSTL?
Zsolt wrote:
Hi,
how can I replace the code below with a JSTL command ?
(scc_history points to a java.util.List class).
bean:size id=nr_of_scc_history name=scc_history /
With JSP 1.2 and JSTL 1.0, there's no way to get the size, only
to check if it's empty:
c:if test=${empty scc_history}
With JSP 2.0 and JSTL 1.1, you can use the length() function:
c:set var=nr_of_scc_history value=${fn:length(scc_history)}/
Hans
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get the size of a java.util.List class from JSTL?
Thank you!
Zsolt
Hans Bergsten wrote:
Zsolt wrote:
Hi,
how can I replace the code below with a JSTL command ?
(scc_history points to a java.util.List class).
bean:size id=nr_of_scc_history name=scc_history /
With JSP 1.2 and JSTL 1.0, there's no way to get the size, only
to check if it's empty:
c:if test=${empty scc_history}
With JSP 2.0 and JSTL 1.1, you can use the length() function:
c:set var=nr_of_scc_history value=${fn:length(scc_history)}/
Hans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem getting JavaBean value
OK, thanks. I was trying to locate that spec yesterday on Sun's Web site,
but, couldn't seem to find it.
Jon
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 7:45 PM
Subject: Re: Problem getting JavaBean value
Nope, the Introspector does not lie ;-). Quote from the Javadoc:
This normally means converting the first character from upper case to
lower case, but in the (unusual) special case when there is more than
one character and both the first and second characters are upper case,
we leave it alone.
This is also covered in section 8.8 Capitalization of inferred names
of the JavaBeans Spec.
Jonathan Eric Miller wrote:
That worked, but, shouldn't it have made the first character lowercase?
Jon
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 5:54 PM
Subject: Re: Problem getting JavaBean value
Try:
${courseSiteRequest.CNetId}
You can use java.beans.Introspector.decapitalize as a sanity check for
your property names.
Jonathan Eric Miller wrote:
I'm using jakarta-taglibs-standard-1.1.0-B1 with JSP 2.0 and Tomcat
5.0.16.
I have a bean that has the following accessor method.
public String getCNetId() {
return cNetId;
}
I'm attempting to get the value in a JSP using the following,
c:out value=${courseSiteRequest.cNetId}/
but, I'm getting the following error,
javax.servlet.ServletException: Unable to find a value for cNetId in
object of class edu.uchicago.at.coursesiterequest.CourseSiteRequest
using
operator .
If I change the case to the following, it works.
public String getCnetId() {
return cNetId;
}
c:out value=${courseSiteRequest.cnetId}/
Is this a bug?
Jon
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
c:import Not Throwing Error For Bad In-Context-JSP url Attribute
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist, an
error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem getting JavaBean value
http://java.sun.com/products/javabeans/docs/spec.html
Jonathan Eric Miller wrote:
OK, thanks. I was trying to locate that spec yesterday on Sun's Web site,
but, couldn't seem to find it.
Jon
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 7:45 PM
Subject: Re: Problem getting JavaBean value
Nope, the Introspector does not lie ;-). Quote from the Javadoc:
This normally means converting the first character from upper case to
lower case, but in the (unusual) special case when there is more than
one character and both the first and second characters are upper case,
we leave it alone.
This is also covered in section 8.8 Capitalization of inferred names
of the JavaBeans Spec.
Jonathan Eric Miller wrote:
That worked, but, shouldn't it have made the first character lowercase?
Jon
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 5:54 PM
Subject: Re: Problem getting JavaBean value
Try:
${courseSiteRequest.CNetId}
You can use java.beans.Introspector.decapitalize as a sanity check for
your property names.
Jonathan Eric Miller wrote:
I'm using jakarta-taglibs-standard-1.1.0-B1 with JSP 2.0 and Tomcat
5.0.16.
I have a bean that has the following accessor method.
public String getCNetId() {
return cNetId;
}
I'm attempting to get the value in a JSP using the following,
c:out value=${courseSiteRequest.cNetId}/
but, I'm getting the following error,
javax.servlet.ServletException: Unable to find a value for cNetId in
object of class edu.uchicago.at.coursesiterequest.CourseSiteRequest
using
operator .
If I change the case to the following, it works.
public String getCnetId() {
return cNetId;
}
c:out value=${courseSiteRequest.cnetId}/
Is this a bug?
Jon
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
I think this is addressed in the 7.4 c:import section of the JSTL 1.0
Spec. There's an explanation of how errors are handled for internal vs.
external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist,
an error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
I'm not an expert in this area, but after looking at the spec:
http://jcp.org/aboutJava/communityprocess/final/jsr052/index.html
it seems like a JspException should be thrown, even for internal URLs. It's
quite possible that I'm overlooking something though.
- Jim
At 05:50 PM 1/22/2004 -0500, you wrote:
I think this is addressed in the 7.4 c:import section of the JSTL 1.0
Spec. There's an explanation of how errors are handled for internal vs.
external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist,
an error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
For an internal URL, try the equivalent JSP:
%
String path = request.getParameter(pageURL);
RequestDispatcher rd = request.getRequestDispatcher(path);
rd.include(request, response);
%
It seems to behave the same way. With TC 4.1.29, I don't see any log
info about the include, but on WLS 8.1.2 I get the following:
...Included resource or file /foo.jsp not found from requested
resource /import.jsp.
No exceptions are thrown, however, just an error logged.
James Watkin wrote:
I'm not an expert in this area, but after looking at the spec:
http://jcp.org/aboutJava/communityprocess/final/jsr052/index.html
it seems like a JspException should be thrown, even for internal URLs.
It's quite possible that I'm overlooking something though.
- Jim
At 05:50 PM 1/22/2004 -0500, you wrote:
I think this is addressed in the 7.4 c:import section of the JSTL
1.0 Spec. There's an explanation of how errors are handled for
internal vs. external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import
throws errors for non-existent files. When the c:import url
attribute is an in-context-jsp (like pageHeader.jsp) that doesn't
exist, no error is thrown. However, when the url attribute is a
file: that doesn't exist, an error is thrown. Can anyone confirm,
or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
