Merrill Higginson

I can think of a couple of options:

Check with your MQ administrator to see if it's possible to set up an MQ server with multiple queues that can be used by a number of developers.

If you're using JMS protocol rather than MQ protocol, you could just install an open source JMS server and configure listeners for it.

You can do this by making the property name for each checkbox the same or by using the html:multibox tag. Then you can simply use the "required" validation to verify that at least one checkbox was checked.

If you're going to forward to a servlet, you must specify redirect="true".

The DispatchAction is considered an "extra", so it's in struts-extras-1.3.10.jar.

The other surprise is that you will have to change the URLs for your Struts taglib definitions. Example:
<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %> <%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %> <%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %>

I'm not sure what a "rem:select" tag does. If it's your own custom tag, I can't help you.

However, the html:select tag will auomatically set the selected option to the value that you specify in the property attribute. So, all you have to do is set the ActionForm bean's property to the right value, and the correct option will be displayed. For more details, see question 3 of our FAQ.

You will find the answer to this question by reading question 6 of our Struts FAQ. This has a working example of using indexed properties in a Struts 1 application.

I'd suggest you find the struts-blank-2.x.x.war file that comes with the download. Then just use the file->import->war file function to import this file into Ecliplse. You then have a ready-made Struts 2 project with all the necessary artifacts. You can deploy this project as-is to JBoss just to make sure everything is working, and then you can use it as a starting point for your new code.

endswel:

Please check your private messages for a message regarding an important administrative matter. You can do so by clicking My Private Messages in the upper right corner of the page.

I'd suggest you use the s:tree tag. Below is a link to the documentation:

http://struts.apache.org/2.1.6/docs/tree.html

In the Admin Console, under the heading "Environment", click virtual hosts. If there is not a virtual host set up for port 9080, add one.

The first time a JSP is accessed, it is compiled into a class file and stored in a cache. The second time it is accessed, the application server checks to see if the JSP file has changed since the class file was created. If it has not changed, the compile step is skipped and the same class file is used. If you change the JSP, the application server will detect that it was changed since the last compile and will perform the compile step again and replace the class file in the cache.

If this code is running inside the container, there's no need to specify parameters when creating the initial context. Try creating the initial context without parameters. Example:
Context ctx = new InitialContext();

I don't know if this is causing the problem you're currently experiencing or not, but one should never use the name action for the parameter used in DispatchAction. The reason for this is that in HTML, a FORM has an action parameter, which is the URL to be executed when the form is submitted. Therefore, having an input element named "action" can confuse things and cause strange errors. Use some other name such as "actionMethod".

Rajasekhar Pentakota wrote:I dont want do install the application in server3. I just need it in Server1 and Server2

How many servers you want the application to run on has nothing to do with whether it should be clustered. When you define a cluster, you define which servers will be part of the cluster to serve the application and which ones won't. To decide whether you should use clustering or not, the important question is: Am I using multiple servers so that my application has greater fail-over capabilities or to increase its capacity to serve a larger number of concurrent users? If the answer to this question is yes, you should use clustering. If it's no, you shouldn't.

The trouble with caching problems is that it's hard to tell what entity is caching your file. Is it the browser? the ISP? the web server? the app server? Sure, there are ways to check each of these areas and try to stop them from caching, but by adding a parameter to the URL as I suggested, each of the above knows to delete its cache and request a new copy from the server. What I'm suggesting is that the first time you change it, the url is test.js?version=1, the second time you change it, it's test.js?version=2, etc.