R. Shellbay

That approach is known, and will work, but it is not sufficient.
What I want to do is, explained in a different matter.
Our framework is packed in jar (obviously!) and what i want is to set some System property whenever one of the classes from that jar is loaded, kind of like a :
Hey THAT framework is used!!!
I don't know which class will be loaded first, and obviously I can't put such a statement in each class, so I was hoping that there is a way, using manifest or something to tell java, that when a jar is loade, run this class/method/snippet/whatever...
A good example could be...
I'm developing a web application that may be run on several different application servers and i know that for instance jboss uses log4j as their logging mechanism. And if the application is running on Jboss, then I also want to log using log4j.
There are several different ways to find out that the application is running on jboss, and a small config parameter could solve this problem easily, but i want a sexy solution ;o)
So when jboss starts to log, using log4j, then I should be able to pick up that , "hey log4j is beeing used in the same vm as me!!, well maybe I will use log4j too"

Most j2ee applications in our firm is implemented using out own j2ee framework. Part of this framework is a logging framework where all messages are pushed through.
When developing other applications that should be independent of this framework , we still want to log through this framework if it is available ( in the classpath ).
So in my application I want to have a small log wrapper to do something like (perhaps in a static initializer ):
if ( main framework available) {
// get main framework log dao
}
else {
// get other dao, maybe log4j
}
I'm aware of the possibility to search for classes in classpath and that approach will work just fine...
What I'm looking for is a way to set some kind of flag, when the jar is loaded. Like some kind of static initialzer for the jar..
PSEUDO :
// when jar loaded
// set system property "framework present"=true
And hence in my small wrapper I can do something as easy as :
if (System.getProperty("foo.bar.foo") !=null) {
//heeeey, main framework is in classpath, and can be used
}
Is there a way to do this??
thx

If the file is located within your servlet context, u can use the following approach to achieve the full path
String resource = "smallpath/text.txt"
java.net.URL u = context.getResource(resource);
String fullpath = u.toString();

The Jakarta project commons have a FileUpload thingy.
This include among other a multipartfomrparser...
Jakarta Commons
-r

This approach is for instance used by the JSTL implementation of the import tag..
The tag does a .. include(request, ServletResponseWrapper ) instaed of the regular include(request, response).
The reason I guess is to better control the writing to the response object, and to have better control with the flushin of whatever is in the response object...

You can change jsp's in the tomcat webapps folder, and see the changes immediately, as tomcat recompiles a jsp if it any changes. This is a good approach for small changes, but the disadvantage is the double book-keeping, when needing to update your original jsp-page as well.
Changes in java class files will demand a restart of tomcat, as the classloader need to be reset. So as a general rule..
1. If deploying a war with no changes in class-files, only jsp, then no restart is needed.
2. If changes in class-files--> restart
Also, as a comment. Learn ANT. It will automate your builds and save enourmous amounts of time in the end. Best thing ever happened....

We have a situation where one Websphere server is ( should be) talking to another. Those two servers are located at different locations, and hence there are firewalls in between.
The ports 9002 and 9003 are open, but the communication between the servers, seems to be happening on different ports as well. The example below is from a successful connection from client to websphere in an open LAN, wheras the connection between the 2 websphere servers fail, propably because not all ports are opened.

tcp 0 0 xxx.yyy.151.82.62982 ggg.iii.167.33.2155 ESTABLISHED tcp 0 0 xxx.yyy.151.82.62981 ggg.iii.167.33.2157 ESTABLISHED tcp 0 0 xxx.yyy.151.82.9003 ggg.iii.167.33.2151 ESTABLISHED tcp 0 0 xxx.yyy.151.82.9002 ggg.iii.167.33.2153 ESTABLISHED tcp 0 0 xxx.yyy.151.82.49280 ggg.iii.167.33.2159 ESTABLISHED
The ports besides 9002/9003 are somewhat random, for each connection.
We don't want to open all ports, but rather limit the range of ports to open...
Any idea's?

First of all, The iterate tag iterates on a collection. You may either specify an object that itself is a collection, or you may set the property attribute in order to tell <logic:iterate> which method on the object that returns a collection.
Iterate will then loop through that collection, using the iterator() method that all Collections have.
A HashMap is not a collection, and hence I would have thought the jsp-compiler would fail when finding the wrong data type.
Also.... The element contained in the collection must be beans...
When using <bean:write ... property="foo"/> The object that is actually operated on, should have a method getFoo() .

Hope this was some help...

This is not quite my area, but I may help with a few comments.
There are mechanism's in different applicationservers for registering datasources as a jndi resource. This datasource can be used by you by doing a JNDI lookup of that exact datasouce.
There should be several tutorials out there to help you on your way

Are you sure you have the jstl.jar in web-inf/lib or some in som eother classpath?

My guess is that you need to restart your webserver each time. At least that's my experience. The reason, i think, is that when the resourcebundle is loaded, JVM "transforms" it into a java class, and hence it is not reloaded unless the classloader is reloaded => restart...

I've used both Struts and JSTL, and found both quite useful.
You should be aware that JSTL demands jsp 1.2 while Struts works well on 1.1 (Please correct me if I'm wrong).
Also my experience is that what you can do in Struts you can do easier with JSTL, and I also think that JSTL expression language is a better approach than the "attributes" approach of Struts..

This is a common problem when building javadoc offline, or from "offline" locations. The link option is , as far as i know, used for locating the packagelist for the thirdparty api you are using. You may copy this package list to a local directory and tell javadoc to obtain the packagelist from that location instead.
If you're using ant this can be done like this:
<target name="javadoc"/> ... ... <link href="http://java.sun.com/j2se/1.4/docs/api/" offline="true" packagelistLoc="${app.meta}\j2se"/> </target>