Another stoopid JSP question

[OhioDude]

I have a jsp application that I want the user to be able to customize by editing values in a text file. For example, changing names of image files and changing text that appear on various pages. I want these options to be read in and available to the jsp code every time the page is loaded. I've tried several approaches. The file contains java String variable declarations.

When I use "%@ include file=", changed options only get read in if I make a change to the jsp page that requires a recompilation of the page (I understand that's by design.)

When I use "jsp:include page=" I receive a servlet error saying that the variable is undefined when I try to reference one of the options stored in the file.

Can somebody tell me the best way to accomplish this simple task?

 

[kamper]

Have you ever used a RequestDispatcher? That's what <jsp:include /> does. It sends control to a new page (the same way you would normally send control from a servlet to a jsp) and allows the included file to print out whatever it wants, but then it returns. Unlike <% @include %> which, as you've seen, includes the file and then goes on processing the jsp as if it was always there.

As far as using String variables that are in an include file, this in general is not good practice. I've seen some pretty horrific cases where multiple pages include the same, very large, file and then you have all sorts of tricky dancing around trying to figure out if you can make changes anywhere without breaking the compilation of another page (and you're lucky if it does break compilation and not just functionality). Not only that but if your user does something wrong like misses a semi-colon, the page is broken because their java syntax was wrong.

The ultimate solution would have the customized items cached somewhere and when the user changes things they can signal it to be updated without affecting customers (no down time...). That might involve your database and would have some globally accessible set of properties. But I get the feeling you're going for simplicity...
Going with the caching idea, if you can provide an easy way for your user to signal that the jsp should be recompiled then you could use <% @include %>. That would provide speed for the majority of times that nothing changes and a small, but required, hit everytime something does change. How to do that would depend on your server, it may be as simple as deleting the compiled .class and .java files for the jsp, although that is probably not a very elegant solution.

Alternatively, using <jsp:include />, you could place the required options into the request attributes. So:
request.setAttribute("key1", "value1");
and back in the main page, retrieve with:
request.getAttribute("key1");
The problem with this is that you lose alot of typesafety and, if you want to be safe about it, you spend a lot of time/code doing error checking.

Any of that sound useable?

 

[OhioDude]

Yeah, I'm aware of the dangers of letting users change options by editing a jsp library file. I have enough trouble myself remembering every curly bracket and semi-colon. I tried this approach out of a need for getting this project done quickly and me being very new to java and jsp.

Just a little background -- I have been programming for over 20 years using mostly VB, COBOL (gasp!) and some C, and very little of it having anything to do with the web. The application I'm working on is a complete B2B CRM package that interfaces with a legacy back-office accounting system. I didn't write the app, I'm just attempting to modify it for a customer. The front end is all written using jsp and very little of the code is documented so this has been a pretty frustrating introduction to jsp for me.

Anyway...

I tried the setAttribute and getAttribute but something isn't working right. I have a file called "schweppe.config" and here's a snippet from it: (Edited so the forums won't choke.)

(%

request.setAttribute("GUEST_CATEGORY_1","S000");
request.setAttribute("GUEST_CATEGORY_2","C000");
request.setAttribute("GUEST_CATEGORY_3","E000");
request.setAttribute("GUEST_CATEGORY_4","Q000");
request.setAttribute("GUEST_CATEGORY_5","W000");
request.setAttribute("GUEST_CATEGORY_6","J000");
request.setAttribute("GUEST_CATEGORY_7","H000");
request.setAttribute("GUEST_CATEGORY_8","T000");
request.setAttribute("GUEST_CATEGORY_9","F000");
request.setAttribute("GUEST_CATEGORY_10","D000");

%)

My calling jsp page looks like this: (again, edited.)

(jsp: include page="schweppe.config" flush="true" /)


Now, how do I access the attributes from within the calling page? If I do this (just as an example):


CurLetter[0] = request.getAttribute("GUEST_CATEGORY_TITLE_1").toString();


CurLetter[0] is blank.

 

[kamper]

No ideas off the top of my head so I'll ask the dumb question:

Do you realize that your example uses "GUEST_CATEGORY_1" as the key the first time and "GUEST_CATEGORY_TITLE_1" the second time? Or was that just a problem with the example?

 

[OhioDude]

Problem in the example. I can't believe I'm having so much trouble trying to do something so simple.

Here's the actual code snippet from the calling jsp page:

jsp: include page="schweppe.config" flush="true" />
[%

String[] CurFile = {"","","","","","","","","",""};
String[] CurLetter = {"","","","","","","","","",""};
String[] GuestText = {"","","","","","","","","",""};
String[] GuestImagesSmall = {"","","","","","","","","",""};
String[] GuestImagesLarge = {"","","","","","","","","",""};

int ix = 0;

try
{
for (ix = 0; ix <=9; ix++)
{
CurLetter[ix] = request.getAttribute("GUEST_CATEGORY_TITLE_" + (ix +1)).toString();
CurFile[ix] = request.getAttribute("GUEST_CATEGORY_" + (ix +1)).toString();
GuestText[ix] = request.getAttribute("GUEST_IMAGES_TEXT_" + (ix +1)).toString();
GuestImagesSmall[ix] = request.getAttribute("GUEST_IMAGES_SMALL_" + (ix +1)).toString();
GuestImagesLarge[ix] = request.getAttribute("GUEST_IMAGES_LARGE_" + (ix +1)).toString();
}
}
catch (Exception e)
{
System.out.println("Error in loading properties:"+e.toString());
}
%>


Here's the actual include page:

[%

request.setAttribute("GUEST_CATEGORY_1","S000");
request.setAttribute("GUEST_CATEGORY_2","C000");
request.setAttribute("GUEST_CATEGORY_3","E000");
request.setAttribute("GUEST_CATEGORY_4","Q000");
request.setAttribute("GUEST_CATEGORY_5","W000");
request.setAttribute("GUEST_CATEGORY_6","J000");
request.setAttribute("GUEST_CATEGORY_7","H000");
request.setAttribute("GUEST_CATEGORY_8","T000");
request.setAttribute("GUEST_CATEGORY_9","F000");
request.setAttribute("GUEST_CATEGORY_10","D000");

request.setAttribute("GUEST_CATEGORY_TITLE_1","Service Catering &amp; Supplies");
request.setAttribute("GUEST_CATEGORY_TITLE_2","Cookware");
request.setAttribute("GUEST_CATEGORY_TITLE_3","Equipment Supplies / Food Catalogs");
request.setAttribute("GUEST_CATEGORY_TITLE_4","Equipment");
request.setAttribute("GUEST_CATEGORY_TITLE_5","Ware/Glass Washing Equip / Chems");
request.setAttribute("GUEST_CATEGORY_TITLE_6","Janitorial Equip / Cleaners");
request.setAttribute("GUEST_CATEGORY_TITLE_7","Shelving / Storage / Safety");
request.setAttribute("GUEST_CATEGORY_TITLE_8","Tabletop");
request.setAttribute("GUEST_CATEGORY_TITLE_9","Food Items");
request.setAttribute("GUEST_CATEGORY_TITLE_10","Disposables / Food Service Kitchen");

request.setAttribute("GUEST_IMAGES_TEXT_1","Here is some S000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_2","Here is some C000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_3","Here is some E000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_4","Here is some Q000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_5","Here is some W000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_6","Here is some J000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_7","Here is some H000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_8","Here is some T000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_9","Here is some F000 marketing text!");
request.setAttribute("GUEST_IMAGES_TEXT_10","Here is some D000 marketing text!");

request.setAttribute("GUEST_IMAGES_SMALL_1","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_2","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_3","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_4","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_5","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_6","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_7","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_8","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_9","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_SMALL_10","/images/ecprismlogo.jpg");

request.setAttribute("GUEST_IMAGES_LARGE_1","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_2","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_3","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_4","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_5","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_6","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_7","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_8","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_9","/images/ecprismlogo.jpg");
request.setAttribute("GUEST_IMAGES_LARGE_10","/images/ecprismlogo.jpg");

%>

 

[kamper]

I'm gonna copy that into a couple of jsp's and run it on Tomcat over here in just a minute. In the meantime I will suggest some changes. First, change the format of the file that the user changes. Do it in a properties file. In case you're not familiar with it, it's just a "key=value" text file like so:
GUEST_CATEGORY_1=S000
GUEST_CATEGORY_2=C000
...
Then use java.util.Properties.loadFromFile() to load these into a Properties object (from your main page). That way your user doesn't have to worry about correct java syntax (although they do have to worry about properties file syntax, it's much simpler). The only downer there is that you have to make sure you try to open the properties file from the right place and it probably won't be a relative location...

 

[kamper]

Oho! :light: Try renaming your schweppe.config to schweppe.jsp. It's quite possible that the server doesn't know it's supposed to compile it. Alternatively, you could specify in web.xml that the server should parse it.

 

[ahurtt]

There is a key difference between using jsp:include and the @include. When you use the xml syntax tag jsp:include, the include happens dynamically at RUN TIME. When you use the jsp @include method, the include happens at COMPILE time. So what does this mean? It means that when using the @include method, the server will compile the contents of the included file into the jsp page that includes it. Hence, you have to change the including file in order to get the server to recompile the contents of the included file. Simply changing the included file will not get the server to recognize that the jsp file including it should recompile. Using the @include method, since the included content gets compiled into the page that calls it, you can often refer to variables between each file and they will compile and be visible at run time.
When you use, the jsp:include, think of it this way. . .The server compiles each file as a separate jsp and only calls the included file at runtime passing whatever parameters you supply. . .But since they are really compiled into separate classes underneath, this is why the including page cannot see variables you define in the included page and vice-versa. So when you need to be able to dynamically pass in arguments to your included file, it's better to use the jsp:include tag. Get it? It's a subtle difference that makes a LOT of difference. But still, I think you would be better off using a Properties object in conjunction with a properties file for simplicity like a previous person responded. The main overhead here would be that you would need to create the Properties object each time the page is called to ensure that the properties read in were always the most recent incase somebody edited. It's often more efficient to read in the properties from the file 1 time and keep the properties cached. But that isn't always possible like it sounds like in your case.

 

[kamper]

Originally posted by: ahurtt
Hence, you have to change the including file in order to get the server to recompile the contents of the included file. Simply changing the included file will not get the server to recognize that the jsp file including it should recompile.

Changing the including file should not work any better than changing the included file. For deployment the server should be configured not to recompile anything unless explicitly told to. Come to think of it OD, that might be a problem given how you're doing it right now. You'd better test it with a configuration as close to deployment as possible.
I'm liking the Properties idea more now. What you can do is have the Properties object stored in the application variable (a ServletContext instance, iirc). In order to reload it have the user visit a certain utility page (hidden, password protected, whatever you like). That utility page then reloads the properties file and updates the Properties. That way you only read them in when they need to be updated and you don't have any of this recompilation crap to worry about.

Edit: removed some extraneous comments....

 

[ahurtt]

That sounds like a good idea. And if you wanted to take it one step further, they could use this same utility page to update the properties and then persist the new properties file programatically rather than manually edit the properties file and run the risk of the user screwing up the properties file. Using a Properties object makes this task pretty simple since as I recall, the Properties object is capable of reading in default properties and then repersisting any changes made back to the underlying properties file. Then when the app starts up you just read them into the ServletContext from the properties file. You don't even really need to store the Properties object itself in the ServletContext. You can just store the properties it contains there and then you can access them more easily directly from the jsp. . .Less chance of user error, cleaner code.

 

[OhioDude]

Thanks, guys.

Changing the file to "schweppe.jsp" didn't help. All of the attributes are empty in the calling page...

Come to think of it OD, that might be a problem given how you're doing it right now. You'd better test it with a configuration as close to deployment as possible.

It's being tested on the user's production server...

Tell me more about accessing these as properties. I tried something similar using a bean written by the folks who wrote the app. I patterned my usage off of some code they were using elsewhere in the app.

I can retrieve all of the properties just fine this way and load them into the arrays, but suprisingly, after I edit the properties file, my page STILL returns the old values for the properties. Perhaps I'm not instantiating the bean properly?

My frustration level is reaching its peak...

Here's the code that loads the properties. (Edited so the forums won't choke.)

===============================================
%@ page import="com.beans.jdbc.jdbcbean,com.beans.jdbc.getformat" %>

String[] CurCat = {"","","","","","","","","",""};
String[] CurTitle = {"","","","","","","","","",""};
String[] GuestText = {"","","","","","","","","",""};
String[] GuestImagesSmall = {"","","","","","","","","",""};
String[] GuestImagesLarge = {"","","","","","","","","",""};

int ix = 0;

jdbcbean bean=new jdbcbean();

try
{
bean.loadTheBundle("global.schweppe");

for (ix = 0; ix <=9; ix++)
{
CurTitle[ix] = bean.getTheString("GUEST_CATEGORY_TITLE_" + (ix +1));
CurCat[ix] = bean.getTheString("GUEST_CATEGORY_" + (ix +1));
GuestText[ix] = bean.getTheString("GUEST_IMAGES_TEXT_" + (ix +1));
GuestImagesSmall[ix] = bean.getTheString("GUEST_IMAGES_SMALL_" + (ix +1));
GuestImagesLarge[ix] = bean.getTheString("GUEST_IMAGES_LARGE_" + (ix +1));
}
}
catch (Exception e)
{
System.out.println("Error in loading Bundle:"+e.toString());
}

===============================================

And here's the properties file:

===============================================

GUEST_CATEGORY_1=S000
GUEST_CATEGORY_2=C000
GUEST_CATEGORY_3=E000
GUEST_CATEGORY_4=Q000
GUEST_CATEGORY_5=W000
GUEST_CATEGORY_6=J000
GUEST_CATEGORY_7=H000
GUEST_CATEGORY_8=T000
GUEST_CATEGORY_9=F000
GUEST_CATEGORY_10=D000

GUEST_CATEGORY_TITLE_1=Service Catering &amp; Supplies
GUEST_CATEGORY_TITLE_2=Cookware
GUEST_CATEGORY_TITLE_3=Equipment Supplies / Food Catalogs
GUEST_CATEGORY_TITLE_4=Equipment
GUEST_CATEGORY_TITLE_5=Ware/Glass Washing Equip / Chems
GUEST_CATEGORY_TITLE_6=Janitorial Equip / Cleaners
GUEST_CATEGORY_TITLE_7=Shelving / Storage / Safety
GUEST_CATEGORY_TITLE_8=Tabletop
GUEST_CATEGORY_TITLE_9=Food Items
GUEST_CATEGORY_TITLE_10=Disposables / Food Service Kitchen

GUEST_IMAGES_TEXT_1=Here is some S000 marketing text
GUEST_IMAGES_TEXT_2=Here is some C000 marketing text
GUEST_IMAGES_TEXT_3=Here is some E000 marketing text
GUEST_IMAGES_TEXT_4=Here is some Q000 marketing text
GUEST_IMAGES_TEXT_5=Here is some W000 marketing text
GUEST_IMAGES_TEXT_6=Here is some J000 marketing text
GUEST_IMAGES_TEXT_7=Here is some H000 marketing text
GUEST_IMAGES_TEXT_8=Here is some T000 marketing text
GUEST_IMAGES_TEXT_9=Here is some F000 marketing text
GUEST_IMAGES_TEXT_10=Here is some D000 marketing text

GUEST_IMAGES_SMALL_1=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_2=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_3=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_4=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_5=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_6=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_7=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_8=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_9=/images/ecprismlogo.jpg
GUEST_IMAGES_SMALL_10=/images/ecprismlogo.jpg

GUEST_IMAGES_LARGE_1=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_2=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_3=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_4=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_5=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_6=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_7=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_8=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_9=/images/ecprismlogo.jpg
GUEST_IMAGES_LARGE_10=/images/ecprismlogo.jpg
===============================================

 

[ahurtt]

Oh, one other thought if you don't want to mess with properties files and all. . .you can use the web.xml deployment descriptor to store the properties. . .but typically the kinds of things you put in there are application configuration type properties. And it would likely require an application restart to read in new or changed properties if you use the deployment descriptor file. But properties file is simplest of all because of it's simple key=value format. With the web.xml file, the person editing it needs to have at least a little bit of xml knowledge.

 

[OhioDude]

That sounds like a good idea. And if you wanted to take it one step further, they could use this same utility page to update the properties and then persist the new properties file programatically rather than manually edit the properties file and run the risk of the user screwing up the properties file. Using a Properties object makes this task pretty simple since as I recall, the Properties object is capable of reading in default properties and then repersisting any changes made back to the underlying properties file. Then when the app starts up you just read them into the ServletContext from the properties file. You don't even really need to store the Properties object itself in the ServletContext. You can just store the properties it contains there and then you can access them more easily directly from the jsp. . .Less chance of user error, cleaner code.

Alex - I posted my reply before I got a chance to read yours. I like this approach better myself. Now, just need to make it work with my limited jsp exposure...

 

[ahurtt]

Hmm, well if the jdbcbean class is storing the underlying properties in static variables it could explain why you don't see the new values after editing the properties file. Do you have the source code available for the bean?

I'd look at that loadThebundle() method and make sure it isn't trying to do some kind of singleton pattern on underlying class variables or something similar to that. Strange yous still see the old values even after calling that method.

 

[kamper]

Originally posted by: ahurtt
That sounds like a good idea. And if you wanted to take it one step further, they could use this same utility page to update the properties and then persist the new properties file programatically rather than manually edit the properties file and run the risk of the user screwing up the properties file. Using a Properties object makes this task pretty simple since as I recall, the Properties object is capable of reading in default properties and then repersisting any changes made back to the underlying properties file. Then when the app starts up you just read them into the ServletContext from the properties file. You don't even really need to store the Properties object itself in the ServletContext. You can just store the properties it contains there and then you can access them more easily directly from the jsp. . .Less chance of user error, cleaner code.

:thumbsup: But I don't see why you would want to store the individual properties directly in the ServletContext. A Properties object will be used to read/write the files so you'd have to write code to move the key/values in between the SC and the Props. Not only that, but you lose type safety, since a SC attribute is a generic Object, whereas Props only store Strings. In addition to that, if the SC is being used to store other stuff it could become very confusing as to which attributes belong to what, you might even get naming conflicts leading to mysterious bugs.

 

[OhioDude]

Hmm, well if the jdbcbean class is storing the underlying properties in static variables it could explain why you don't see the new values after editing the properties file. Do you have the source code available for the bean?

Sure do, but it's too long to post here. Can you tell me what to look for?

 

[kamper]

And two stylistic points (sorry, but I just can't help it ):

In java you can declare for loop indexes inline:
for (int ix = 0; ix < 10; ix++)....

And using System.out is considered bad form in a web environment (although it probably won't kill you). The best solution is to set up a logger of some sort. Although it's a bit of a complexity jump over System.out it's not that hard. log4j gets my recommendation.

 

[kamper]

Originally posted by: OhioDude

Hmm, well if the jdbcbean class is storing the underlying properties in static variables it could explain why you don't see the new values after editing the properties file. Do you have the source code available for the bean?

Sure do, but it's too long to post here. Can you tell me what to look for?

Just look for anything that might short circuit the loadTheBundle() method. But it looks like that "bean" is not doing anything that Properties won't so you might try that instead. I say "bean" because that class doesn't appear to conform to what a JavaBean is supposed to do.

 

[ahurtt]

Look in the bean for any class level variables with the static keyword modifier in front of them. Any data stored in static variables becomes data associated with the class itself. . .in other words, 1 copy of the variable for all instances of the class. With non-static variables, or instance variables, each instance of a class gets a copy of the variable. Thus, when you declare static variables in a class, constructing a new instance of the class with the new operator typically does not have any effect on static data unless the constructor somehow explicitly modifies the static data. Also note, you cannot access static variables from non-static methods. . .so if you have:

public class Aclass {

public static String aString = "sometext";

public void aMethod() {

//will not compile because instance method can't access static variable.
aString = "othertext";

//will compile but you have just modified aString for all instances of this class.
//will not compile if you make aString private instead of public.
Aclass.aString = "othertext";

}

}

 

[kamper]

Originally posted by: ahurtt
Hmm, well if the jdbcbean class is storing the underlying properties in static variables it could explain why you don't see the new values after editing the properties file.

What is your logic on that one? I don't see why the load method couldn't change static values just as easily as none static ones. That would, in fact, be a silly implementation because you'd have to do all sorts of synchronization to keep static values safe.

 

[ahurtt]

Valid points kamper. The only reason I was thinking to put the properties from the file into the servlet context instead of putting the Properties object itself there was just to make for less scriptlet code in the JSP itself. He'd be able to access the properties directly from a class (the ServletContext) which is part of the servlet API and have less import directives in the code. . .minor things really. It's probably really be best, the more I think of it, to wrap the Properties object in a bean class so that you can use the <jsp:useBean> tag to access the Properties object from the JSP. Then you have virtually no java code in your jsp. . .I'm just overthinking it because I'm sitting here at work with nothing really to do

 

[kamper]

Originally posted by: ahurtt
Look in the bean for any class level variables with the static keyword modifier in front of them. Any data stored in static variables becomes data associated with the class itself. . .in other words, 1 copy of the variable for all instances of the class. With non-static variables, or instance variables, each instance of a class gets a copy of the variable. Thus, when you declare static variables in a class, constructing a new instance of the class with the new operator typically does not have any effect on static data unless the constructor somehow explicitly modifies the static data. Also note, you cannot access static variables from non-static methods. . .so if you have:

public class Aclass {

public static String aString = "sometext";

public void aMethod() {

//will not compile because instance method can't access static variable.
aString = "othertext";

//will compile but you have just modified aString for all instances of this class.
//will not compile if you make aString private instead of public.
Aclass.aString = "othertext";

}

}

You've got that backwards. Non-static methods can touch static methods/data but static methods cannot touch non-static methods/data.

 

[kamper]

Originally posted by: ahurtt
Valid points kamper. The only reason I was thinking to put the properties from the file into the servlet context instead of putting the Properties object itself there was just to make for less scriptlet code in the JSP itself. He'd be able to access the properties directly from a class (the ServletContext) which is part of the servlet API and have less import directives in the code. . .minor things really. It's probably really be best, the more I think of it, to wrap the Properties object in a bean class so that you can use the <jsp:useBean> tag to access the Properties object from the JSP. Then you have virtually no java code in your jsp. . .I'm just overthinking it because I'm sitting here at work with nothing really to do

I agree there, I wanted to suggest that a long time ago. But if he was interested in keeping java out of his jsps then he would be using servlets for all of this anyways. Encoding application logic (as opposed to display logic) with tags is no better than writing java straight in.

 

[ahurtt]

Originally posted by: kamper

Originally posted by: ahurtt
Hmm, well if the jdbcbean class is storing the underlying properties in static variables it could explain why you don't see the new values after editing the properties file.

What is your logic on that one? I don't see why the load method couldn't change static values just as easily as none static ones. That would, in fact, be a silly implementation because you'd have to do all sorts of synchronization to keep static values safe.

The load method could change the properties. That's not to say it does. He just asked why he didn't see the updated values after modifying the properties file and I posted the first and simplest possible explanation that came to mind without seeing the source code for the bean. We don't really know what the load method is doing because he said the bean source code was too big to post here. But given the information I have, that load method is prime suspect number one for me. It might have an underlying implementation that only loads the Properties object if it is currently null. And if the Properties object were static, using the new jdbcbean() operation would not reset the underlying Properties object to null. Just supposing. . .don't really know without the code.

 

[kamper]

Gotcha, I missed the jump from "not loading" to "static properties" but that explanation makes sense. Still, I should hope that's not the case, because of the potential synchronization issues.