Re: [WEB-SERVICES ]
On 5/23/06, temp temp [EMAIL PROTECTED] wrote: Web services. How web services are written in java. Are there any tutorials to understand the concept of web services? What particular kind of a web service did you have in mind? You mentioned Enterprise Java Beans. Those are not a web service but might be part of some middleware used by a web service. If you can give us an example, perhaps we can help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Iterate over list in in list in form bean.
On 7/13/05, Jörg Eichhorn [EMAIL PROTECTED] wrote: thanks for the hint and example. I've choosen the nested way to do this, because i think this makes the jsp code more readable. I there a way to do the same using request scope? When i do this i get an exception because the collection is not re-filled anymore. This is the same question I have, but of course I'm a week late in asking it. However, I noticed that no one answered Jörg's version so I'll ask it again: Is there a way to do the same using request scope? I've been beating my head against this all weekend to no avail. I understand how to do this in session scope, but don't know if it's even possible in request scope. As I understand things (which may be wrong), when the form is submitted (in request scope) a new form bean is created and populated with the values in the collection from the HTML form. But, of course, a newly created form won't know how many elements are in the form so it can't pre-populate the collection with beans to be filled in. Right? So following this path leads to wailing, lamentation, gnashing of teeth, rending of clothes and utter frustration. Right? If there is simply no way to do this, I'd really appreciate someone letting me know so that I'm put out of my misery. And, if someone could suggest a workaround, I'd be most welcome. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Iterate over list in in list in form bean.
Well I could see for large forms with nested data it might not be a great idea to keep these around in the Session. I 'try' to stick to using the Request when I can but I don't bend over backwards like some do on this list to avoid the Session.. I'm in The Session is your friend camp:). Request will work fine however for Mike's situation. He just needs to wrap his collection in his ActionForm around a LazyList (or he can use a regular list and do the handcranking approach of incrementing the size when needed in the getList property in his form. LazyList is cleaner, though). Request is required for my situation -- the user can have multiple versions of the same page active in the same session. That's what drove me away from the 'working' session scope bean -- I had users who were messing up the session scoped bean by opening the same page multiple times and making modifications. I don't see LazyList as any cleaner. You have to add one method in either case. With LazyList you have to implement Factory then add the create() method. Extending ArrayList you have to implement a new get(). I'll stick with the latter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Iterate over list in in list in form bean.
On 7/18/05, Rick Reumann [EMAIL PROTECTED] wrote:
I'm still not totally clear where the problem is, since I'm not sure
what Session has to do with the initial setup of the form.
The difference is unobvious, I admit, but this is what I was thinking
of: If I use a session bean, I can do some sort of setup (from an
Action) on its initial creation, including creating the list of
contained objects. That can't happen if it's in request scope because
there is no chance to invoke the setup before the bean is populated
from the request.
1) A problem when you submit the form and getting 'index' problems
showing up in the logs?
More than showing up, the submit was trying to populate the bean with
indexed properties but the list containing the indexed properties was
of size zero. The
answer to the problem was given by the previous posters. Thanks guys.
What made the difference was the Wiki page section (BeanUtils Indexed
Properties Issue) pointing out that there is a bug in JDK 1.4 which
prevents the solution of writing your own getXXX( int ndx ) property.
I had done that (in desperation) and when that didn't work either, I
threw up my hands and wrote the list. I felt that it _should_ have
worked and when it didn't I just assumed my understanding of the
situation was inadequate and gave up. I'm delighted to find out that
the problem is in the implementation and not in my mental picture of
how this whole thing works.
I'm confused because you mention But, of course, a newly created form
won't know how many elements are in the form so it can't pre-populate
the collection with beans to be filled in. This statement confused me
because you seem to be implying it works when it's in Session which
doesn't make sense since even with a Session scoped form you still need
to some initial population somewhere.
But you can do that once, before all this other stuff takes place. I
realize that wasn't an obvious inference but that's what I meant.
Typically I feel you should always go to some sort of setUp action or
dispatch method BEFORE you ever forward to a form.
But doesn't that go away in request scope when the form is submitted
back to the Action? Doesn't a new form get created and populated from
the HTML? It sure looks like that's what's happening to me.
For the two problems listed above the link Naill posted is good
http://wiki.apache.org/struts/StrutsCatalogLazyList (and I just recently
added to that link the way I like to do it).
I came up with another solution which might be worthy of
consideration. Instead of using arrays, extend a list with the
desired get( int ) method and use that list instead:
public class SkillActionForm extends ActionForm {
protected List skills = new LazyArrayList();
public class LazyArrayList extends ArrayList {
public Object get( int index ) {
while (size() = index) add( new SkillBean() );
return super.get( index );
}
}
}
This is the solution I eventually adopted (successfully) but I have a
fondness for nested classes which others may not share.
Anyway, thanks to all, I've gotten past the problem with an increased
understanding of the intricacies of this here Struts stuff.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does struts really have to construct a new form bean every time?
On 4/27/05, Michael Jouravlev [EMAIL PROTECTED] wrote: scope=request === should be scope=session Thanks! I knew it had to be something simple like that! And I've wasted a day and a half finding it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Modifying an object within the form bean?
I have a situation where the form bean contains objects inside it which represent sets of things which will appear in an html:select tag. In particular, the objects have three properties: selected_ndx ndx_set label_set One of these objects is the 'moderator' property of the form bean. The overall design intent was to have an object which could provide the values and labels for an html:select statement and have selected_ndx be the value which is changed via the selection process in the web page. If I write the JSP like this, it works: html:select property=moderator.selected_ndx html:options property=moderator.ndx_set labelProperty=moderator.label_set/ /html:select This generates the following HTML: select name=moderator.selected_ndxoption value=0/option option value=1First Selection/option option value=2Second Selection/option option value=3Third Selection/option/select This successfully displays the selected entity and allows it to be changed via selection through the web page. However, additionally I need to be able to set the value of this select from a popup window. That generally means I need to specify the form element as the target of a javascript assignment. What has worked in similar circumstances in the past is something like opener.document.formBean.selectElementName = newValue where selectElementName is the value of the 'name' attribute from the select element. Here that name is moderator.selected_ndx. That causes a problem. When the javascript runs (from a popup window) the following javascript error occurs: Error: opener.document.formBean.moderator has no properties Which I interpret as the javascript interpreter being able to find the formBean property (which I assume is being furnished by the html:form tag) but that there is no attribute of that called moderator. If I didn't use the dotted notation in the html:select tag, the correct attribute gets created, or whatever, and the javascript works OK. So -- how can I solve this problem? Assuming that the naming is the problem, I've tried introducing a bean like this: bean:define id=mod name=formBean property=moderator/ html:select name=mod property=selected_ndx html:options name=mod property=ndx_set labelName=mod labelProperty=label_set/ /html:select Which generates HTML: select name=selected_ndxoption value=0/option etc. But that causes the select element to be unselectable; that is, while the getter method (getSelected_ndx()) gets invoked, the setter method (setSelected_ndx()) does not, so that changes to the field no longer get propagated back to the form bean. Even if I could get this to work, I'm dubious that I could have multiple select elements working properly in the same form since they would all have the same name attribute (selected_ndx). While I'm unconvinced that the failure to invoke the setter method isn't a bug, I still need to solve the problem through some combination of Struts/JavaScript. Any suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying an object within the form bean?
On Wed, 06 Oct 2004 14:38:36 -0500, Jason King [EMAIL PROTECTED] wrote: This is a javascript problem. The DOM-compliant way to change the selected option for a select element is: selectObjectName.selectedIndex = newIndex for your example that would be: opener.document.formBean.selectElementName.selectedIndex = newValue; No, I don't think so. For my example I think it would be something more like: opener.document.formBean.moderator.select_ndx = newValue The problem appears to be the dotted notation that Struts uses to name the select element. If Struts generated select name=moderator_selected_ndx instead of select name=moderator.selected_ndx I feel confident it would work like you said. But that dot in the name apparently makes JavaScript view the field as being the 'selected_ndx' attribute of the 'moderator' object which, of course, doesn't exist. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying an object within the form bean?
Try opener.document.formBean[moderator.selected_ndx] The arrays are also hashtables. Yes, that works. Thanks a bunch. Although I still think that the bean approach *should* have worked -- it doesn't. And I'll gladly settle for this workaround. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: bouncing address (if this is you at standardbank.co.az, PLEASE correct it)
On Wed, 6 Oct 2004 19:46:46 -0400, David G. Friedman [EMAIL PROTECTED] wrote: I'm starting to severly dislike this error message from some unknown subscribe at standarbank.co.az. Actually its standardbank.co.za (South Africa). I'm getting them too. I assume everyone is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Compilation of JSP at time of deployment?
I have a neglected Ultra 1, now running Solaris 9, which I've rescued to use as a web application server. It's running JBoss just fine and when my web application is loaded and run the response time, while slow (on the order of a second or two per page) is still reasonable. The problem comes about after redeploy, or reboot, or JBoss restart, or whatever, which causes JBoss to forget all the compiled servlets for the application. When the first user encounters such a page the page is, of course, compiled and made ready for use -- but this can take tens of seconds to accomplish, leaving a less than sparkling impression for the user. Is there a way to force all the JSPs and ActionForms, etc., to be compiled and ready to go at the time of deployment? Even if it takes several minutes to achieve this, it would be worth it rather than delaying until the first user/victim accesses the page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Storing User in Session
On Thu, 23 Sep 2004 15:31:47 -0400, Sean Schofield [EMAIL PROTECTED] wrote: Of course if you have millions of users that might be another story. Millions of users, each of whom have an active session. Otherwise, who cares how many rows are in the database? Certainly not struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to treat optional dates?
On Thu, 2004-09-16 at 19:28, [EMAIL PROTECTED] wrote: Since the posting I made a happy discovery though. If I save an optional date with the value '01-01-0001' (d-m-y), it appears as blank when displayed - just what I was after. Are you sure? Isn't it m-d-y? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making a file available?
On Thu, 2004-09-16 at 19:49, Joe Hertz wrote:
Absolutely. You have access to all of the response object methods you would
in a servlet to do this with.
Set the correct content type and content length headers and spit it to the
outputstream. Return a null findForward.
I've done this with pdf files, (and this week I asked on this list about img
tags. Was even easier: It worked the same way, but with none of the header
setting apparently. Least I hope so :-).
In fact, the file doesn't even need to be accessible via a browser
accessible URL. If the application can read it, that's all you need.
So, you mean something like this?
public class FileXferAction extends Action {
public ActionForward execute(
ActionMapping actionMapping, ActionForm actionForm,
ServletRequest servletRequest, ServletResponse servletResponse )
throws Exception {
System.out.println( Here we are! );
OutputStream os = servletResponse.getOutputStream();
os.write( Content-Type: application/pdf\n.getBytes() );
FileInputStream fis = new FileInputStream( /tmp/test.pdf );
int len;
byte[] bytes = new byte[1024];
while ((len = fis.read( bytes )) 0) {
os.write( bytes, 0, len );
}
fis.close();
return null;
}
}
Unfortunately that just gives me a blank screen. Importantly, Here we
are! does NOT show up in the log, so . . . apparently the action isn't
even getting invoked. Probably something to do with struts-config.xml:
action path=/xferFile
type=action.FileXferAction
validate=false/
I just guessed at this. Since it doesn't forward, doesn't use a JSP
page, etc, I'm leaving those attributes empty. If they shouldn't be
empty, what should they be?
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
HTML Filtering?
I have a situation where I need to populate a table with values. Sometimes those values are empty. Mozilla, for reasons outside of this discussion will not fully render a table datum that is empty; that is, it will render nothing (correctly) but also not render the border of the table datum either, if the content is empty. Normally the workaround for this is to put a non breakable space (nbsp;) in the table datum to get Mozilla (or Netscape, for that matter) to render the table datum with all surrounding borders. However, Struts makes that difficult. If I use a bean:write tag, I can specify filtering off to allow the nbsp; non breakable space to appear. That will, however, prevent the filtering of non-empty items as well -- which might not be such a good idea. Or, I can turn on filtering which will cause oddball elements to be rendered correctly, but will prevent the nbsp; from being a non-breakable space. So . . . what I need to do is perform the filtering beforehand, then set the bean to render the property with no filtering (filtering=false). That means I need to do my own filtering. Yes, I can write my own HTML filtering routine, but . . . there must be something already out there - probably part of the commons-beanutils jar file - that already does such filtering. I'd much rather use that than roll my own. Anyone know of such a routine? That is, a routine invokable from within an arbitrary class, that takes a chunk of text and renders ampersands as amp;, left angle brackets as lt; etc.? -- Mike Elliott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Read only iterate?
On Saturday 14 August 2004 17:52, Kishore Senji wrote: Refer: http://struts.apache.org/faqs/indexedprops.html logic:iterate id=entry name=problemBean property=items tr tdProblematic input/td td html:text name=entry property=integer_value indexed=true/ /td /tr /logic:iterate Try the one below: logic:iterate id=entry name=problemBean property=items indexId=ctr tr tdProblematic input/td td html:text name=problemBean property='%=items[+ctr+].integer_value%'/ /td /tr /logic:iterate Yes, that works. Thank you. However, I would put that in the general category of a workaround rather than the correct solution. I read the reference you mentioned before making my original attempt. In that reference, the authors themselves feel there is a better solution: The JSP expression syntax for the property attribute is somewhat messy and easy to get wrong so it's something we want to avoid. One way to make this a little cleaner is to use indexed tags' and then go on to talk about indexed tags as being superior. I took from that the notion that I should avoid the first solution; that indexed tags would do the same thing. If that's actually true then I'd be delighted to see how to make it work. Nowhere in the discussion do the authors drop the bomb that using indexed tags makes the whole situation read-only and I still think that there must be some way to make it work using indexed tags -- I just haven't yet found it. However, thanks for pointing me at the earlier solution -- it does work, awkward as it is, and that's really important when one has a product to deliver. -- Mike Elliott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Read only iterate?
On Friday 13 August 2004 09:40, Richard Yee wrote: Mike, What does the generated HTML look like? The generated HTML is not the problem; the failure to invoke the set method is the problem. However, maybe looking at it would provide some insight into the cause. Anyway, here it is: html head titleProblem page/title /head body div style=text-align: center form name=problemBean method=post action=/pr99/Problem.do?arg=update table width=800 border=0 cellspacing=0 cellpadding=0 tr td align=center colspan=2 input type=submit value=Submit /td /tr hr / tr tdProblematic input/td td input type=text name=entry[0].integer_value value=0 /td /tr tr tdProblematic input/td td input type=text name=entry[1].integer_value value=1 /td /tr tr tdbFunctioning input/b/td td input type=text name=working_perfectly value=x /td /tr /table /form hr / /div /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Read only iterate?
On Friday 13 August 2004 09:43, Brian Lee wrote:
Lists work, but you have to write your own set(int index) method to set the
correct object from the List.
BAL
I still believe that lists work -- it's not lack of belief that's the problem,
it's lack of results. There's some magic involved that, if documented
anywhere is somewhere I have yet to uncover.
Based on the general principal of orthogonality if the get method is properly
invoked (which it apparently is) then the equivalent set method should also
be invoked. That's simply not happening. However, orthogonality aside, if
writing a separate indexed set method would make the problem go away I'd
gladly use it.
Alas, however, that doesn't make the slightest difference. I added two
indexed set methods as you suggested with depressingly familiar results:
package problem;
import org.apache.log4j.Logger;
import org.apache.struts.action.ActionForm;
import java.util.ArrayList;
import java.util.List;
public class ProblemBean extends ActionForm {
final private static int ENTRY_ROW_COUNT = 2;
public ProblemBean() {
log.info( initializing entries );
entries = new ArrayList();
// Create some entries for the form
for (int ndx = 0 ; ndx ENTRY_ROW_COUNT; ndx ++) {
ProblemItem a = new ProblemItem();
a.setInteger_value( new Integer(ndx));
entries.add( a );
}
}
private String working_perfectly = A Value;
public String getWorking_perfectly() {
log.info( getWorking_perfectly );
return working_perfectly;
}
public void setWorking_perfectly( String working_perfectly ) {
log.info( setWorking_perfectly to ' + working_perfectly + ');
this.working_perfectly = working_perfectly;
}
private List entries;
public List getEntries() {
log.info( getEntries );
return entries;
}
public void setEntries( List entries ) {
log.info( setEntries );
this.entries = entries;
}
// Added an indexed setter just in case
public void setInteger_value( int ndx, Integer iValue ) {
log.info( OHMYGOD -- IT GOT INVOKED! );
ProblemItem pi = (ProblemItem)getEntries().get( ndx );
pi.setInteger_value( iValue );
}
public static class ProblemItem extends ActionForm {
// Used so that each item can have a unique value.
private static Integer incrementing = new Integer( 0 );
public ProblemItem() {
this.integer_value = incrementing;
incrementing = new Integer( incrementing.intValue() + 1 );
}
private Integer integer_value;
public Integer getInteger_value() {
log.info( getInteger_value );
return integer_value;
}
public void setInteger_value( Integer iValue ) {
log.info( setInteger_value to + iValue );
this.integer_value = iValue;
}
// Added an indexed setter just in case
public void setInteger_value( int ndx, Integer iValue ) {
log.info( OHMYGOD -- IT GOT INVOKED!);
this.integer_value = iValue;
}
private static Logger log = Logger.getLogger( ProblemItem.class );
}
private static Logger log = Logger.getLogger( ProblemBean.class );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Read only iterate?
On Friday 13 August 2004 09:40, Jim Barrows wrote:
-Original Message-
From: Mike Elliott [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 9:33 AM
To: [EMAIL PROTECTED]
Subject: Read only iterate?
I've been totally defeated in my attempt to alter an html:text
element inside a logic:iterate tag. There must be a way to
accomplish this, but I've been beating my head against the wall
for three days now without making progress.
I have simplified the problem substantially from the initial page.
What I have now looks like this:
from
http://struts.apache.org/userGuide/struts-html.html#text
I'm guessing that a List won't work and you need to have an array.
No -- changing it to a list makes no difference whatsoever:
package problem;
import org.apache.log4j.Logger;
import org.apache.struts.action.ActionForm;
import java.util.ArrayList;
import java.util.List;
public class ProblemBean extends ActionForm {
final private static int ENTRY_ROW_COUNT = 2;
public ProblemBean() {
log.info( initializing entries );
entries = new ArrayList();
// Create some entries for the form
for (int ndx = 0 ; ndx ENTRY_ROW_COUNT; ndx ++) {
ProblemItem a = new ProblemItem();
a.setInteger_value( new Integer(ndx));
entries.add( a );
}
}
private String working_perfectly = A Value;
public String getWorking_perfectly() {
log.info( getWorking_perfectly );
return working_perfectly;
}
public void setWorking_perfectly( String working_perfectly ) {
log.info( setWorking_perfectly to ' + working_perfectly + ');
this.working_perfectly = working_perfectly;
}
private List entries;
public ProblemItem[] getEntries() {
log.info( getEntries );
ProblemItem[] result = new ProblemItem[entries.size()];
for (int ndx = 0; ndx entries.size(); ndx++)
result[ndx] = (ProblemItem)entries.get( ndx );
return result;
}
public void setEntries( List entries ) {
log.info( setEntries );
this.entries = entries;
}
public static class ProblemItem extends ActionForm {
// Used so that each item can have a unique value.
private static Integer incrementing = new Integer( 0 );
public ProblemItem() {
this.integer_value = incrementing;
incrementing = new Integer( incrementing.intValue() + 1 );
}
private Integer integer_value;
public Integer getInteger_value() {
log.info( getInteger_value );
return integer_value;
}
public void setInteger_value( Integer iValue ) {
log.info( setInteger_value to + iValue );
this.integer_value = iValue;
}
private static Logger log = Logger.getLogger( ProblemItem.class );
}
private static Logger log = Logger.getLogger( ProblemBean.class );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Read only iterate?
I've been totally defeated in my attempt to alter an html:text element inside a logic:iterate tag. There must be a way to accomplish this, but I've been beating my head against the wall for three days now without making progress. I have simplified the problem substantially from the initial page. What I have now looks like this: - [ Submit ] Problematic Input [0 ] Problematic Input [1 ] Functioning Input [A Value ] - The lines containing Problematic Input were generated by a logic:iterate tag, which successfully fetched the list of objects from the form bean. The last line, containing Functioning Input, was generated outside of the logic:iterate tag. Actual contents of the jsp page, bean, etc., are attached. What happens at runtime is that when the JSP page is rendered, the text fields for all three rows are successfully and correctly fetched from the form bean, but only the last row can be changed. As the log shows: start INFO [org.apache.struts.util.PropertyMessageResources] Initializing, config='org.apache.struts.taglib.html.LocalStrings', returnNull=true INFO [problem.ProblemBean] initializing entries INFO [problem.ProblemBean$ProblemItem] setInteger_value to 0 INFO [problem.ProblemBean$ProblemItem] setInteger_value to 1 INFO [problem.ProblemAction] show INFO [org.apache.struts.util.PropertyMessageResources] Initializing, config='org.apache.struts.taglib.logic.LocalStrings', returnNull=true INFO [problem.ProblemBean] getEntries INFO [problem.ProblemBean$ProblemItem] getInteger_value INFO [problem.ProblemBean$ProblemItem] getInteger_value INFO [problem.ProblemBean] getWorking_perfectly submit INFO [problem.ProblemBean] setWorking_perfectly to 'mutated' INFO [problem.ProblemAction] update INFO [problem.ProblemBean] getEntries INFO [problem.ProblemBean$ProblemItem] getInteger_value INFO [problem.ProblemBean$ProblemItem] getInteger_value INFO [problem.ProblemBean] getWorking_perfectly The page is initialized properly. All three values are fetched from the form bean via the expected get methods. The html form is properly populated and displays the expected values (0, 1, and A Value). The three fields are then changed (to 5, 5, and mutated) and the submit button is selected at the point in the log file where I have inserted the submit annotation. This causes the form to be submitted to the Action, causing the set method for the field working_perfectly to be invoked (as it should be), but the set method for the two fields in the logic:iterate tag is not invoked. And I don't know why. And I can't seem to get them to be invoked, either. So . . . the magic isn't working. Something must be needed to tell the generated servlet not to treat these two properties (inside the logic:iterate tag) as read-only. What should it be? How can I get these properties to be updated in the form bean as the working_perfectly property is? Like I said -- I've been beating my head against this problem for three days now. There's just got to be a way! -- struts-config.xml -- ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.0//EN http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd; struts-config form-beans form-bean name=problemBean type=problem.ProblemBean/ /form-beans action-mappings action path=/problemPage type=problem.ProblemAction name=problemBean validate=false input=/pages/problem.jsp/ /action-mappings /struts-config -- problem.jsp: -- %@ taglib uri=/taglib/struts-logic prefix=logic % %@ taglib uri=/taglib/struts-html prefix=html % html head titleProblem page/title /head body div style=text-align: center html:form action=/classicResultPage.do?arg=update method=post table summary=x width=800 border=0 cellspacing=0 cellpadding=0 tr td align=center colspan=2 html:submit/ /td /tr hr / logic:iterate id=entry name=problemBean property=items tr tdProblematic input/td td html:text name=entry property=integer_value indexed=true/ /td /tr /logic:iterate tr tdbFunctioning input/b/td td html:text property=someValue/ /td
